Skip to content

Q
qemu

openeuler / qemu

通知 10
Star 0
Fork 0
Q
qemu

体验新版 GitCode，发现更多精彩内容 >>

切换分支/标签
  1. 13 3月, 2019 1 次提交
  3. 11 3月, 2019 3 次提交
  5. 08 3月, 2019 2 次提交
    • P
      minikconfig: implement allnoconfig and defconfig modes · f3494749
      由 Paolo Bonzini 提交于 
      Apart from defconfig (which is a no-op),
allyesconfig/allnoconfig/randcondfig can be implemented simply by ignoring
the RHS of assignments and "default" statements.  The RHS is replaced
respectively by "true", "false" or a random value.

However, allyesconfig and randconfig do not quite work, because all the
files for hw/ARCH/Kconfig are sourced and therefore you could end up
enabling some ARM boards in x86 or things like that.  This is left for
future work, but I am leaving it in to help debugging minikconf itself.

allnoconfig mode is tied to a new configure option, --without-default-devices.
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
      f3494749
    • P
      build: switch to Kconfig · e0e312f3
      由 Paolo Bonzini 提交于 
      The make_device_config.sh script is replaced by minikconf, which
is modified to support the same command line as its predecessor.

The roots of the parsing are default-configs/*.mak, Kconfig.host and
hw/Kconfig.  One difference with make_device_config.sh is that all symbols
have to be defined in a Kconfig file, including those coming from the
configure script.  This is the reason for the Kconfig.host file introduced
in the previous patch. Whenever a file in default-configs/*.mak used
$(...) to refer to a config-host.mak symbol, this is replaced by a
Kconfig dependency; this part must be done already in this patch
for bisectability.
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
Signed-off-by: NYang Zhong <yang.zhong@intel.com>
Acked-by: NThomas Huth <thuth@redhat.com>
Message-Id: <20190123065618.3520-28-yang.zhong@intel.com>
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
      e0e312f3
  7. 07 3月, 2019 4 次提交
  9. 26 2月, 2019 1 次提交
  11. 22 2月, 2019 1 次提交
  13. 18 2月, 2019 2 次提交
  15. 05 2月, 2019 2 次提交
  17. 30 1月, 2019 1 次提交
  19. 24 1月, 2019 1 次提交
    • D
      trace: add ability to do simple printf logging via systemtap · 62dd1048
      由 Daniel P. Berrangé 提交于 
      The dtrace systemtap trace backend for QEMU is very powerful but it is
also somewhat unfriendly to users who aren't familiar with systemtap,
or who don't need its power right now.

  stap -e "....some strange script...."

The 'log' backend for QEMU by comparison is very crude but incredibly
easy to use:

 $ qemu -d trace:qio* ...some args...
 23266@1547735759.137292:qio_channel_socket_new Socket new ioc=0x563a8a39d400
 23266@1547735759.137305:qio_task_new Task new task=0x563a891d0570 source=0x563a8a39d400 func=0x563a86f1e6c0 opaque=0x563a89078000
 23266@1547735759.137326:qio_task_thread_start Task thread start task=0x563a891d0570 worker=0x563a86f1ce50 opaque=0x563a891d9d90
 23273@1547735759.137491:qio_task_thread_run Task thread run task=0x563a891d0570
 23273@1547735759.137503:qio_channel_socket_connect_sync Socket connect sync ioc=0x563a8a39d400 addr=0x563a891d9d90
 23273@1547735759.138108:qio_channel_socket_connect_fail Socket connect fail ioc=0x563a8a39d400

This commit introduces a way to do simple printf style logging of probe
points using systemtap. In particular it creates another set of tapsets,
one per emulator:

  /usr/share/systemtap/tapset/qemu-*-log.stp

These pre-define probe functions which simply call printf() on their
arguments. The printf() format string is taken from the normal
trace-events files, with a little munging to the format specifiers
to cope with systemtap's more restrictive syntax.

With this you can now do

 $ stap -e 'probe qemu.system.x86_64.log.qio*{}'
 22806@1547735341399856820 qio_channel_socket_new Socket new ioc=0x56135d1d7c00
 22806@1547735341399862570 qio_task_new Task new task=0x56135cd66eb0 source=0x56135d1d7c00 func=0x56135af746c0 opaque=0x56135bf06400
 22806@1547735341399865943 qio_task_thread_start Task thread start task=0x56135cd66eb0 worker=0x56135af72e50 opaque=0x56135c071d70
 22806@1547735341399976816 qio_task_thread_run Task thread run task=0x56135cd66eb0

We go one step further though and introduce a 'qemu-trace-stap' tool to
make this even easier

 $ qemu-trace-stap run qemu-system-x86_64 'qio*'
 22806@1547735341399856820 qio_channel_socket_new Socket new ioc=0x56135d1d7c00
 22806@1547735341399862570 qio_task_new Task new task=0x56135cd66eb0 source=0x56135d1d7c00 func=0x56135af746c0 opaque=0x56135bf06400
 22806@1547735341399865943 qio_task_thread_start Task thread start task=0x56135cd66eb0 worker=0x56135af72e50 opaque=0x56135c071d70
 22806@1547735341399976816 qio_task_thread_run Task thread run task=0x56135cd66eb0

This tool is clever in that it will automatically change the
SYSTEMTAP_TAPSET env variable to point to the directory containing the
right set of probes for the QEMU binary path you give it. This is useful
if you have QEMU installed in /usr but are trying to test and trace a
binary in /home/berrange/usr/qemu-git. In that case you'd do

 $ qemu-trace-stap run /home/berrange/usr/qemu-git/bin/qemu-system-x86_64 'qio*'

And it'll make sure /home/berrange/usr/qemu-git/share/systemtap/tapset
is used for the trace session

The 'qemu-trace-stap' script takes a verbose arg so you can understand
what it is running

 $ qemu-trace-stap run /home/berrange/usr/qemu-git/bin/qemu-system-x86_64 'qio*'
 Using tapset dir '/home/berrange/usr/qemu-git/share/systemtap/tapset' for binary '/home/berrange/usr/qemu-git/bin/qemu-system-x86_64'
 Compiling script 'probe qemu.system.x86_64.log.qio* {}'
 Running script, <Ctrl>-c to quit
 ...trace output...

It can enable multiple probes at once

 $ qemu-trace-stap run qemu-system-x86_64 'qio*' 'qcrypto*' 'buffer*'

By default it monitors all existing running processes and all future
launched proceses. This can be restricted to a specific PID using the
--pid arg

 $ qemu-trace-stap run --pid 2532 qemu-system-x86_64 'qio*'

Finally if you can't remember what probes are valid it can tell you

 $ qemu-trace-stap list qemu-system-x86_64
 ahci_check_irq
 ahci_cmd_done
 ahci_dma_prepare_buf
 ahci_dma_prepare_buf_fail
 ahci_dma_rw_buf
 ahci_irq_lower
 ...snip...

Or list just those matching a prefix pattern

 $ qemu-trace-stap list -v qemu-system-x86_64 'qio*'
 Using tapset dir '/home/berrange/usr/qemu-git/share/systemtap/tapset' for binary '/home/berrange/usr/qemu-git/bin/qemu-system-x86_64'
 Listing probes with name 'qemu.system.x86_64.log.qio*'
 qio_channel_command_abort
 qio_channel_command_new_pid
 qio_channel_command_new_spawn
 qio_channel_command_wait
 qio_channel_file_new_fd
 ...snip...
Reviewed-by: NEric Blake <eblake@redhat.com>
Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>
Message-id: 20190123120016.4538-5-berrange@redhat.com
Signed-off-by: NStefan Hajnoczi <stefanha@redhat.com>
      62dd1048
  21. 22 1月, 2019 1 次提交
  23. 21 1月, 2019 2 次提交
    • D
      ui: fix icon display for GTK frontend under GNOME Shell with Wayland · 67ea9546
      由 Daniel P. Berrangé 提交于 
      The icon associated with a GtkWindow is just a hint to window managers
and not all of them will honour it. Some will instead want to show the
icon listed by the .desktop file. The desktop file is located based on
the application ID, which is set using g_set_prgname. QEMU has not
historically provided a desktop file or set its app ID, so it got a
broken icon in GNOME shell, which is now fixed.
Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>
Message-id: 20190110120047.25369-3-berrange@redhat.com
Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>
      67ea9546
    • D
      ui: install logo icons to $prefix/share/icons · a8260d38
      由 Daniel P. Berrangé 提交于 
      QEMU currently installs logos to $prefix/share/qemu/ which means no GUI
toolkit or applications can find them by default.

The accepted standards for desktop applications declare that application
logos / icons should be installed under $prefix/share/icons, so use this
directory location.

Pre-rendered icons are provided at the standard sizes expected for GUI
applications, along with the scalable SVG, to ensure maximum portability.

The PNGs are rendered from the SVG using inkscape, however, this is not
wired up into the default make rules to avoid requiring inkscape as a
mandatory tool in build systems / developer workstations.
Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>
Message-id: 20190110120047.25369-2-berrange@redhat.com
Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>
      a8260d38
  25. 19 1月, 2019 1 次提交
  27. 15 1月, 2019 1 次提交
  29. 10 1月, 2019 3 次提交
  31. 22 12月, 2018 1 次提交
    • Y
      contrib/rdmacm-mux: Add implementation of RDMA User MAD multiplexer · a5d2f6f8
      由 Yuval Shaia 提交于 
      RDMA MAD kernel module (ibcm) disallow more than one MAD-agent for a
given MAD class.
This does not go hand-by-hand with qemu pvrdma device's requirements
where each VM is MAD agent.
Fix it by adding implementation of RDMA MAD multiplexer service which on
one hand register as a sole MAD agent with the kernel module and on the
other hand gives service to more than one VM.

Design Overview:
Reviewed-by: NShamir Rabinovitch <shamir.rabinovitch@oracle.com>
----------------
A server process is registered to UMAD framework (for this to work the
rdma_cm kernel module needs to be unloaded) and creates a unix socket to
listen to incoming request from clients.
A client process (such as QEMU) connects to this unix socket and
registers with its own GID.

TX:
----
When client needs to send rdma_cm MAD message it construct it the same
way as without this multiplexer, i.e. creates a umad packet but this
time it writes its content to the socket instead of calling umad_send().
The server, upon receiving such a message fetch local_comm_id from it so
a context for this session can be maintain and relay the message to UMAD
layer by calling umad_send().

RX:
----
The server creates a worker thread to process incoming rdma_cm MAD
messages. When an incoming message arrived (umad_recv()) the server,
depending on the message type (attr_id) looks for target client by
either searching in gid->fd table or in local_comm_id->fd table. With
the extracted fd the server relays to incoming message to the client.
Signed-off-by: NYuval Shaia <yuval.shaia@oracle.com>
Reviewed-by: NShamir Rabinovitch <shamir.rabinovitch@oracle.com>
Signed-off-by: NMarcel Apfelbaum <marcel.apfelbaum@gmail.com>
      a5d2f6f8
  33. 20 12月, 2018 1 次提交
  35. 12 12月, 2018 1 次提交
  37. 15 10月, 2018 1 次提交
  39. 03 10月, 2018 1 次提交
    • V
      contrib: add elf2dmp tool · 3fa2d384
      由 Viktor Prutyanov 提交于 
      elf2dmp is a converter from ELF dump (produced by 'dump-guest-memory') to
Windows MEMORY.DMP format (also know as 'Complete Memory Dump') which can be
opened in WinDbg.

This tool can help if VMCoreInfo device/driver is absent in Windows VM and
'dump-guest-memory -w' is not available but dump can be created in ELF format.

The tool works as follows:
1. Determine the system paging root looking at GS_BASE or KERNEL_GS_BASE
to locate the PRCB structure and finds the kernel CR3 nearby if QEMU CPU
state CR3 is not suitable.
2. Find an address within the kernel image by dereferencing the first
IDT entry and scans virtual memory upwards until the start of the
kernel.
3. Download a PDB matching the kernel from the Microsoft symbol store,
and figure out the layout of certain relevant structures necessary for
the dump.
4. Populate the corresponding structures in the memory image and create
the appropriate dump header.
Signed-off-by: NViktor Prutyanov <viktor.prutyanov@virtuozzo.com>
Message-Id: <1535546488-30208-3-git-send-email-viktor.prutyanov@virtuozzo.com>
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
      3fa2d384
  41. 27 9月, 2018 1 次提交
    • G
      display/edid: add edid generator to qemu. · 72d277a7
      由 Gerd Hoffmann 提交于 
      EDID is a metadata format to describe monitors.  On physical hardware
the monitor has an eeprom with that data block which can be read over
i2c bus.

On a linux system you can usually find the EDID data block in
/sys/class/drm/$card/$connector/edid.  xorg ships a edid-decode utility
which you can use to turn the blob into readable form.

I think it would be a good idea to use EDID for virtual displays too.
Needs changes in both qemu and guest kms drivers.  This patch is the
first step, it adds an generator for EDID blobs to qemu.  Comes with a
qemu-edid test tool included.

With EDID we can pass more information to the guest.  Names and serial
numbers, so the guests display configuration has no boring "Unknown
Monitor".  List of video modes.  Display resolution, pretty important
in case we want add HiDPI support some day.
Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>
Message-id: 20180925075646.25114-2-kraxel@redhat.com
      72d277a7
  43. 25 9月, 2018 1 次提交
  45. 27 8月, 2018 1 次提交
  47. 17 8月, 2018 1 次提交
    • D
      docs: add guidance on configuring CPU models for x86 · 2544e9e4
      由 Daniel P. Berrangé 提交于 
      With the recent set of CPU hardware vulnerabilities on x86, it is
increasingly difficult to understand which CPU configurations are
good to use and what flaws they might be vulnerable to.

This doc attempts to help management applications and administrators in
picking sensible CPU configuration on x86 hosts. It outlines which of
the named CPU models are good choices, and describes which extra CPU
flags should be enabled to allow the guest to mitigate hardware flaws.
Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>
Message-Id: <20180627160103.13634-1-berrange@redhat.com>
Signed-off-by: NEduardo Habkost <ehabkost@redhat.com>
      2544e9e4
  49. 05 7月, 2018 3 次提交
  51. 22 6月, 2018 1 次提交
  53. 14 6月, 2018 1 次提交