[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Qemu-commits] [qemu/qemu] 861dc7: pcie: don't skip multi-mask events
|
From: |
Peter Maydell |
|
Subject: |
[Qemu-commits] [qemu/qemu] 861dc7: pcie: don't skip multi-mask events |
|
Date: |
Fri, 05 Jul 2019 02:46:55 -0700 |
Branch: refs/heads/master
Home: https://github.com/qemu/qemu
Commit: 861dc73518a049887b709f031359713e5f6b284e
https://github.com/qemu/qemu/commit/861dc73518a049887b709f031359713e5f6b284e
Author: Michael S. Tsirkin <address@hidden>
Date: 2019-07-01 (Mon, 01 Jul 2019)
Changed paths:
M hw/pci/pcie.c
Log Message:
-----------
pcie: don't skip multi-mask events
If we are trying to set multiple bits at once, testing that just one of
them is already set gives a false positive. As a result we won't
interrupt guest if e.g. presence detection change and attention button
press are both set. This happens with multi-function device removal.
Signed-off-by: Michael S. Tsirkin <address@hidden>
Reviewed-by: Igor Mammedov <address@hidden>
Reviewed-by: Marcel Apfelbaum <address@hidden>
Reviewed-by: Philippe Mathieu-Daudé <address@hidden>
Commit: 2841ab435bca9f102311e01bf157d5fa878935dc
https://github.com/qemu/qemu/commit/2841ab435bca9f102311e01bf157d5fa878935dc
Author: Michael S. Tsirkin <address@hidden>
Date: 2019-07-01 (Mon, 01 Jul 2019)
Changed paths:
M hw/pci-bridge/pcie_root_port.c
M hw/pci-bridge/xio3130_downstream.c
M hw/pci/pcie.c
M include/hw/pci/pcie.h
Log Message:
-----------
pcie: check that slt ctrl changed before deleting
During boot, linux would sometimes overwrites control of a powered off
slot before powering it on. Unfortunately QEMU interprets that as a
power off request and ejects the device.
For example:
/x86_64-softmmu/qemu-system-x86_64 -enable-kvm -S -machine q35 \
-device
pcie-root-port,id=pcie_root_port_0,slot=2,chassis=2,addr=0x2,bus=pcie.0 \
-monitor stdio disk.qcow2
(qemu)device_add virtio-balloon-pci,id=balloon,bus=pcie_root_port_0
(qemu)cont
Balloon is deleted during guest boot.
To fix, save control beforehand and check that power
or led state actually change before ejecting.
Note: this is more a hack than a solution, ideally we'd
find a better way to detect ejects, or move away
from ejects completely and instead monitor whether
it's safe to delete device due to e.g. its power state.
Signed-off-by: Michael S. Tsirkin <address@hidden>
Reviewed-by: Marcel Apfelbaum <address@hidden>
Reviewed-by: Igor Mammedov <address@hidden>
Tested-by: Igor Mammedov <address@hidden>
Commit: 110c477c2ede4d06d3a95a2bfda5c4c58d2af516
https://github.com/qemu/qemu/commit/110c477c2ede4d06d3a95a2bfda5c4c58d2af516
Author: Michael S. Tsirkin <address@hidden>
Date: 2019-07-01 (Mon, 01 Jul 2019)
Changed paths:
M hw/pci/pcie.c
Log Message:
-----------
pcie: work around for racy guest init
During boot, linux guests tend to clear all bits in pcie slot status
register which is used for hotplug.
If they clear bits that weren't set this is racy and will lose events:
not a big problem for manual hotplug on bare-metal, but a problem for us.
For example, the following is broken ATM:
/x86_64-softmmu/qemu-system-x86_64 -enable-kvm -S -machine q35 \
-device
pcie-root-port,id=pcie_root_port_0,slot=2,chassis=2,addr=0x2,bus=pcie.0 \
-device virtio-balloon-pci,id=balloon,bus=pcie_root_port_0 \
-monitor stdio disk.qcow2
(qemu)device_del balloon
(qemu)cont
Balloon isn't deleted as it should.
As a work-around, detect this attempt to clear slot status and revert
status to what it was before the write.
Note: in theory this can be detected as a duplicate button press
which cancels the previous press. Does not seem to happen in
practice as guests seem to only have this bug during init.
Note2: the right thing to do is probably to fix Linux to
read status before clearing it, and act on the bits that are set.
Signed-off-by: Michael S. Tsirkin <address@hidden>
Reviewed-by: Marcel Apfelbaum <address@hidden>
Reviewed-by: Igor Mammedov <address@hidden>
Tested-by: Igor Mammedov <address@hidden>
Commit: d85d65cc297fa85b7b2db3b9025c6341d6986d7e
https://github.com/qemu/qemu/commit/d85d65cc297fa85b7b2db3b9025c6341d6986d7e
Author: Michael S. Tsirkin <address@hidden>
Date: 2019-07-01 (Mon, 01 Jul 2019)
Changed paths:
M hw/pci/pcie.c
M include/hw/pci/pcie.h
Log Message:
-----------
pcie: minor cleanups for slot control/status
Rename function arguments to make intent clearer.
Better documentation for slot control logic.
Suggested-by: Igor Mammedov <address@hidden>
Signed-off-by: Michael S. Tsirkin <address@hidden>
Reviewed-by: Philippe Mathieu-Daudé <address@hidden>
Reviewed-by: Igor Mammedov <address@hidden>
Commit: 5f503cd9f38856285a83afe5b928c94f40e43fb7
https://github.com/qemu/qemu/commit/5f503cd9f38856285a83afe5b928c94f40e43fb7
Author: Pankaj Gupta <address@hidden>
Date: 2019-07-02 (Tue, 02 Jul 2019)
Changed paths:
M hw/virtio/Kconfig
M hw/virtio/Makefile.objs
A hw/virtio/virtio-pmem.c
A include/hw/virtio/virtio-pmem.h
M qapi/misc.json
Log Message:
-----------
virtio-pmem: add virtio device
This is the implementation of virtio-pmem device. Support will require
machine changes for the architectures that will support it, so it will
not yet be compiled. It can be unlocked with VIRTIO_PMEM_SUPPORTED per
machine and disabled globally via VIRTIO_PMEM.
We cannot use the "addr" property as that is already used e.g. for
virtio-pci/pci devices. And we will have e.g. virtio-pmem-pci as a proxy.
So we have to choose a different one (unfortunately). "memaddr" it is.
That name should ideally be used by all other virtio-* based memory
devices in the future.
-device virtio-pmem-pci,id=p0,bus=bux0,addr=0x01,memaddr=0x1000000...
Acked-by: Markus Armbruster <address@hidden>
[ QAPI bits ]
Signed-off-by: Pankaj Gupta <address@hidden>
[ MemoryDevice/MemoryRegion changes, cleanups, addr property "memaddr",
split up patches, unplug handler ]
Signed-off-by: David Hildenbrand <address@hidden>
Message-Id: <address@hidden>
Reviewed-by: Michael S. Tsirkin <address@hidden>
Signed-off-by: Michael S. Tsirkin <address@hidden>
Reviewed-by: Cornelia Huck <address@hidden>
Commit: 1e33b513f261a24b4340eca5a6f8f5726b92e097
https://github.com/qemu/qemu/commit/1e33b513f261a24b4340eca5a6f8f5726b92e097
Author: David Hildenbrand <address@hidden>
Date: 2019-07-02 (Tue, 02 Jul 2019)
Changed paths:
M hw/virtio/virtio-pci.c
M hw/virtio/virtio-pci.h
Log Message:
-----------
virtio-pci: Allow to specify additional interfaces for the base type
Let's allow to specify additional interfaces for the base type (e.g.
later TYPE_MEMORY_DEVICE), something that was possible before the
rework of virtio PCI device instantiation.
Reviewed-by: Cornelia Huck <address@hidden>
Signed-off-by: David Hildenbrand <address@hidden>
Message-Id: <address@hidden>
Reviewed-by: Michael S. Tsirkin <address@hidden>
Signed-off-by: Michael S. Tsirkin <address@hidden>
Commit: 9f583bdd47189416c7ba331f1baf3a890f2671a6
https://github.com/qemu/qemu/commit/9f583bdd47189416c7ba331f1baf3a890f2671a6
Author: Pankaj Gupta <address@hidden>
Date: 2019-07-04 (Thu, 04 Jul 2019)
Changed paths:
M include/standard-headers/linux/virtio_ids.h
A include/standard-headers/linux/virtio_pmem.h
Log Message:
-----------
virtio-pmem: sync linux headers
Add linux headers for virtio pmem. These are not yet upstream - include
them temporarily as merge window in which this is supposed to be is
coming up shortly. If virtio-pmem ends up not being merged
then this will be reverted and accordingly virtio-pmem dropped.
Signed-off-by: Pankaj Gupta <address@hidden>
Message-Id: <address@hidden>
Reviewed-by: Michael S. Tsirkin <address@hidden>
Signed-off-by: Michael S. Tsirkin <address@hidden>
Commit: adf0748a494151fd7c10050820f2a3988768828a
https://github.com/qemu/qemu/commit/adf0748a494151fd7c10050820f2a3988768828a
Author: Pankaj Gupta <address@hidden>
Date: 2019-07-04 (Thu, 04 Jul 2019)
Changed paths:
M hw/virtio/Makefile.objs
A hw/virtio/virtio-pmem-pci.c
A hw/virtio/virtio-pmem-pci.h
M include/hw/pci/pci.h
Log Message:
-----------
virtio-pci: Proxy for virtio-pmem
We need a proxy device for virtio-pmem, and this device has to be the
actual memory device so we can cleanly hotplug it.
Forward memory device class functions either to the actual device or use
properties of the virtio-pmem device to implement these in the proxy.
virtio-pmem will only be compiled for selected, supported architectures
(that can deal with virtio/pci devices being memory devices). An
architecture that is prepared for that can simply enable
CONFIG_VIRTIO_PMEM to make it work.
As not all architectures support memory devices (and CONFIG_VIRTIO_PMEM
will be enabled per supported architecture), we have to move the PCI proxy
to a separate file.
Signed-off-by: Pankaj Gupta <address@hidden>
[ split up patches, memory-device changes, move pci proxy]
Signed-off-by: David Hildenbrand <address@hidden>
Message-Id: <address@hidden>
Reviewed-by: Michael S. Tsirkin <address@hidden>
Signed-off-by: Michael S. Tsirkin <address@hidden>
Commit: d766b22bbd18c7766e2e0a28ea0d07c18db13f7e
https://github.com/qemu/qemu/commit/d766b22bbd18c7766e2e0a28ea0d07c18db13f7e
Author: David Hildenbrand <address@hidden>
Date: 2019-07-04 (Thu, 04 Jul 2019)
Changed paths:
M monitor/hmp-cmds.c
Log Message:
-----------
hmp: Handle virtio-pmem when printing memory device infos
Print the memory device info just like for PCDIMM/NVDIMM.
Reviewed-by: Dr. David Alan Gilbert <address@hidden>
Signed-off-by: David Hildenbrand <address@hidden>
Message-Id: <address@hidden>
Reviewed-by: Michael S. Tsirkin <address@hidden>
Signed-off-by: Michael S. Tsirkin <address@hidden>
Commit: cae02c3480b806ce1fb30a3a5c54ae1b43a412e7
https://github.com/qemu/qemu/commit/cae02c3480b806ce1fb30a3a5c54ae1b43a412e7
Author: David Hildenbrand <address@hidden>
Date: 2019-07-04 (Thu, 04 Jul 2019)
Changed paths:
M numa.c
Log Message:
-----------
numa: Handle virtio-pmem in NUMA stats
Account the memory to node 0 for now. Once (if ever) virtio-pmem
supports NUMA, we can account it to the right node.
Signed-off-by: David Hildenbrand <address@hidden>
Message-Id: <address@hidden>
Reviewed-by: Michael S. Tsirkin <address@hidden>
Signed-off-by: Michael S. Tsirkin <address@hidden>
Commit: a0a49813f7f2fc23bfe8a4fc6760e2a60c9a3e59
https://github.com/qemu/qemu/commit/a0a49813f7f2fc23bfe8a4fc6760e2a60c9a3e59
Author: David Hildenbrand <address@hidden>
Date: 2019-07-04 (Thu, 04 Jul 2019)
Changed paths:
M hw/i386/Kconfig
M hw/i386/pc.c
Log Message:
-----------
pc: Support for virtio-pmem-pci
Override the device hotplug handler to properly handle the memory device
part via virtio-pmem-pci callbacks from the machine hotplug handler and
forward to the actual PCI bus hotplug handler.
As PCI hotplug has not been properly factored out into hotplug handlers,
most magic is performed in the (un)realize functions. Also some PCI host
buses don't have a PCI hotplug handler at all yet, just to be sure that
we alway have a hotplug handler on x86, add a simple error check.
Unlocking virtio-pmem will unlock virtio-pmem-pci.
Signed-off-by: David Hildenbrand <address@hidden>
[ Disable virtio-pmem hotunplug ]
Signed-off-by: Pankaj Gupta <address@hidden>
Message-Id: <address@hidden>
Reviewed-by: Michael S. Tsirkin <address@hidden>
Signed-off-by: Michael S. Tsirkin <address@hidden>
Commit: 683c1d89efd1eeb111c129a9a91f629b94d90d45
https://github.com/qemu/qemu/commit/683c1d89efd1eeb111c129a9a91f629b94d90d45
Author: Marc-André Lureau <address@hidden>
Date: 2019-07-04 (Thu, 04 Jul 2019)
Changed paths:
M hw/virtio/virtio-pci.c
Log Message:
-----------
virtio-pci: fix missing device properties
Since commit a4ee4c8baa37154 ("virtio: Helper for registering virtio
device types"), virtio-gpu-pci, virtio-vga, and virtio-crypto-pci lost
some properties: "ioeventfd" and "vectors". This may cause various
issues, such as failing migration or invalid properties.
Since those VirtioPCI devices do not have a base name, their class are
initialized with virtio_pci_generic_base_class_init(). However, if the
VirtioPCIDeviceTypeInfo provided a class_init which sets dc->props,
the properties were overwritten by virtio_pci_generic_class_init().
Instead, introduce an intermediary base-type to register the generic
properties.
Fixes: a4ee4c8baa37154f42b4dc6a13fee79268d15238
Cc: address@hidden
Signed-off-by: Marc-André Lureau <address@hidden>
Message-Id: <address@hidden>
Commit: e57f2c31b6529d990eeafacdb19b9eb1904c23c6
https://github.com/qemu/qemu/commit/e57f2c31b6529d990eeafacdb19b9eb1904c23c6
Author: Xie Yongji <address@hidden>
Date: 2019-07-04 (Thu, 04 Jul 2019)
Changed paths:
M hw/block/vhost-user-blk.c
M hw/core/machine.c
M hw/virtio/virtio.c
M include/hw/virtio/virtio.h
Log Message:
-----------
virtio: add "use-started" property
In order to avoid migration issues, we introduce a "use-started"
property to the base virtio device to indicate whether use
"started" flag or not. This property will be true by default and
set to false when machine type <= 4.0.
Suggested-by: Greg Kurz <address@hidden>
Signed-off-by: Xie Yongji <address@hidden>
Message-Id: <address@hidden>
Reviewed-by: Greg Kurz <address@hidden>
Tested-by: Greg Kurz <address@hidden>
Reviewed-by: Michael S. Tsirkin <address@hidden>
Signed-off-by: Michael S. Tsirkin <address@hidden>
Commit: 7abccd088c9ef4c66dc891ff634a1f381ed4b2a8
https://github.com/qemu/qemu/commit/7abccd088c9ef4c66dc891ff634a1f381ed4b2a8
Author: Xie Yongji <address@hidden>
Date: 2019-07-04 (Thu, 04 Jul 2019)
Changed paths:
M hw/virtio/virtio.c
M include/hw/virtio/virtio.h
Log Message:
-----------
virtio: Set "start_on_kick" for legacy devices
Besides virtio 1.0 transitional devices, we should also
set "start_on_kick" flag for legacy devices (virtio 0.9).
Signed-off-by: Xie Yongji <address@hidden>
Reviewed-by: Greg Kurz <address@hidden>
Message-Id: <address@hidden>
Reviewed-by: Michael S. Tsirkin <address@hidden>
Signed-off-by: Michael S. Tsirkin <address@hidden>
Commit: 868a8f44f57f15670b30631a95e3e31e5cf268d0
https://github.com/qemu/qemu/commit/868a8f44f57f15670b30631a95e3e31e5cf268d0
Author: Xie Yongji <address@hidden>
Date: 2019-07-04 (Thu, 04 Jul 2019)
Changed paths:
M hw/virtio/virtio.c
Log Message:
-----------
virtio: Set "start_on_kick" on virtio_set_features()
The guest feature is not set correctly on virtio_reset() and
virtio_init(). So we should not use it to set "start_on_kick" at that
point. This patch set "start_on_kick" on virtio_set_features() instead.
Fixes: badaf79cfdbd3 ("virtio: Introduce started flag to VirtioDevice")
Signed-off-by: Xie Yongji <address@hidden>
Reviewed-by: Greg Kurz <address@hidden>
Message-Id: <address@hidden>
Reviewed-by: Michael S. Tsirkin <address@hidden>
Signed-off-by: Michael S. Tsirkin <address@hidden>
Commit: 8b04e2c797b01a4baf379ec4f40b3f0e9cdf7a25
https://github.com/qemu/qemu/commit/8b04e2c797b01a4baf379ec4f40b3f0e9cdf7a25
Author: Xie Yongji <address@hidden>
Date: 2019-07-04 (Thu, 04 Jul 2019)
Changed paths:
M hw/virtio/virtio.c
Log Message:
-----------
virtio: Make sure we get correct state of device on handle_aio_output()
We should set the flags: "start_on_kick" and "started" after we call
the kick functions (handle_aio_output() and handle_output()).
Signed-off-by: Xie Yongji <address@hidden>
Message-Id: <address@hidden>
Reviewed-by: Michael S. Tsirkin <address@hidden>
Signed-off-by: Michael S. Tsirkin <address@hidden>
Commit: 4c5cf37b504b1444b031d5c9af6b6ad2f171d006
https://github.com/qemu/qemu/commit/4c5cf37b504b1444b031d5c9af6b6ad2f171d006
Author: Xie Yongji <address@hidden>
Date: 2019-07-04 (Thu, 04 Jul 2019)
Changed paths:
M hw/virtio/virtio.c
Log Message:
-----------
virtio: Don't change "started" flag on virtio_vmstate_change()
We will call virtio_set_status() on virtio_vmstate_change().
The "started" flag should not be changed in this case. Otherwise,
we may get an incorrect value when we set "started" flag but
not set DRIVER_OK in source VM.
Signed-off-by: Xie Yongji <address@hidden>
Message-Id: <address@hidden>
Reviewed-by: Michael S. Tsirkin <address@hidden>
Signed-off-by: Michael S. Tsirkin <address@hidden>
Commit: 457cfcccdd107a968d106934df63b836b5dd743e
https://github.com/qemu/qemu/commit/457cfcccdd107a968d106934df63b836b5dd743e
Author: Eduardo Habkost <address@hidden>
Date: 2019-07-04 (Thu, 04 Jul 2019)
Changed paths:
M hw/i386/pc.c
M hw/i386/pc_piix.c
M include/hw/i386/pc.h
Log Message:
-----------
pc: Move compat_apic_id_mode variable to PCMachineClass
Replace the static variable with a PCMachineClass field. This
will help us eventually get rid of the pc_compat_*() init
functions.
Signed-off-by: Eduardo Habkost <address@hidden>
Message-Id: <address@hidden>
Reviewed-by: Philippe Mathieu-Daude <address@hidden>
Reviewed-by: Michael S. Tsirkin <address@hidden>
Signed-off-by: Michael S. Tsirkin <address@hidden>
Commit: db68f4ff06cbe0517ed0d9b5634f6cddaed2547c
https://github.com/qemu/qemu/commit/db68f4ff06cbe0517ed0d9b5634f6cddaed2547c
Author: Stefan Hajnoczi <address@hidden>
Date: 2019-07-04 (Thu, 04 Jul 2019)
Changed paths:
M contrib/libvhost-user/libvhost-user.c
Log Message:
-----------
libvhost-user: add vmsg_set_reply_u64() helper
The VhostUserMsg request is reused as the reply by message processing
functions. This is risky since request fields may corrupt the reply if
the vhost-user message handler function forgets to re-initialize them.
Changing this practice would be very invasive but we can introduce a
helper function to make u64 payload replies safe. This also eliminates
code duplication in message processing functions.
Signed-off-by: Stefan Hajnoczi <address@hidden>
Reviewed-by: Marc-André Lureau <address@hidden>
Message-Id: <address@hidden>
Reviewed-by: Michael S. Tsirkin <address@hidden>
Signed-off-by: Michael S. Tsirkin <address@hidden>
Commit: 6f5fd837889814e57a4bb473bf80ce08e355a12d
https://github.com/qemu/qemu/commit/6f5fd837889814e57a4bb473bf80ce08e355a12d
Author: Stefan Hajnoczi <address@hidden>
Date: 2019-07-04 (Thu, 04 Jul 2019)
Changed paths:
M contrib/libvhost-user/libvhost-user-glib.c
M contrib/libvhost-user/libvhost-user-glib.h
M contrib/libvhost-user/libvhost-user.c
M contrib/libvhost-user/libvhost-user.h
M contrib/vhost-user-blk/vhost-user-blk.c
M contrib/vhost-user-gpu/main.c
M contrib/vhost-user-input/main.c
M contrib/vhost-user-scsi/vhost-user-scsi.c
M tests/vhost-user-bridge.c
Log Message:
-----------
libvhost-user: support many virtqueues
Currently libvhost-user is hardcoded to at most 8 virtqueues. The
device backend should decide the number of virtqueues, not
libvhost-user. This is important for multiqueue device backends where
the guest driver needs an accurate number of virtqueues.
This change breaks libvhost-user and libvhost-user-glib API stability.
There is no stability guarantee yet, so make this change now and update
all in-tree library users.
This patch touches up vhost-user-blk, vhost-user-gpu, vhost-user-input,
vhost-user-scsi, and vhost-user-bridge. If the device has a fixed
number of queues that exact number is used. Otherwise the previous
default of 8 virtqueues is used.
vu_init() and vug_init() can now fail if malloc() returns NULL. I
considered aborting with an error in libvhost-user but it should be safe
to instantiate new vhost-user instances at runtime without risk of
terminating the process. Therefore callers need to handle the vu_init()
failure now.
vhost-user-blk and vhost-user-scsi duplicate virtqueue index checks that
are already performed by libvhost-user. This code would need to be
modified to use max_queues but remove it completely instead since it's
redundant.
Signed-off-by: Stefan Hajnoczi <address@hidden>
Reviewed-by: Marc-André Lureau <address@hidden>
Message-Id: <address@hidden>
Reviewed-by: Michael S. Tsirkin <address@hidden>
Signed-off-by: Michael S. Tsirkin <address@hidden>
Commit: ea1b802ca27e5b38798b1e346352ad724aa841cd
https://github.com/qemu/qemu/commit/ea1b802ca27e5b38798b1e346352ad724aa841cd
Author: Stefan Hajnoczi <address@hidden>
Date: 2019-07-04 (Thu, 04 Jul 2019)
Changed paths:
M contrib/libvhost-user/libvhost-user.c
Log Message:
-----------
libvhost-user: implement VHOST_USER_PROTOCOL_F_MQ
Existing vhost-user device backends, including vhost-user-scsi and
vhost-user-blk, support multiqueue but libvhost-user currently does not
advertise this.
VHOST_USER_PROTOCOL_F_MQ enables the VHOST_USER_GET_QUEUE_NUM request
needed for a vhost-user master to query the number of queues. For
example, QEMU's vhost-user-net master depends on
VHOST_USER_PROTOCOL_F_MQ for multiqueue.
If you're wondering how any device backend with more than one virtqueue
functions today, it's because device types with a fixed number of
virtqueues do not require querying the number of queues. Therefore the
vhost-user master for vhost-user-input with 2 virtqueues, for example,
doesn't actually depend on VHOST_USER_PROTOCOL_F_MQ. It just enables
virtqueues 0 and 1 without asking.
Let there be multiqueue!
Suggested-by: Sebastien Boeuf <address@hidden>
Signed-off-by: Stefan Hajnoczi <address@hidden>
Reviewed-by: Marc-André Lureau <address@hidden>
Message-Id: <address@hidden>
Reviewed-by: Michael S. Tsirkin <address@hidden>
Signed-off-by: Michael S. Tsirkin <address@hidden>
Commit: 3ef4dff2b397c8932fd3b4d955cd6ba620245475
https://github.com/qemu/qemu/commit/3ef4dff2b397c8932fd3b4d955cd6ba620245475
Author: Stefan Hajnoczi <address@hidden>
Date: 2019-07-04 (Thu, 04 Jul 2019)
Changed paths:
M docs/interop/vhost-user.rst
Log Message:
-----------
docs: avoid vhost-user-net specifics in multiqueue section
The "Multiple queue support" section makes references to vhost-user-net
"queue pairs". This is confusing for two reasons:
1. This actually applies to all device types, not just vhost-user-net.
2. VHOST_USER_GET_QUEUE_NUM returns the number of virtqueues, not the
number of queue pairs.
Reword the section so that the vhost-user-net specific part is relegated
to the very end: we acknowledge that vhost-user-net historically
automatically enabled the first queue pair.
Signed-off-by: Stefan Hajnoczi <address@hidden>
Reviewed-by: Marc-André Lureau <address@hidden>
Message-Id: <address@hidden>
Reviewed-by: Michael S. Tsirkin <address@hidden>
Signed-off-by: Michael S. Tsirkin <address@hidden>
Commit: c35d17cabc1e2c72ac0adfd47a0dc9ea40875069
https://github.com/qemu/qemu/commit/c35d17cabc1e2c72ac0adfd47a0dc9ea40875069
Author: Peter Maydell <address@hidden>
Date: 2019-07-05 (Fri, 05 Jul 2019)
Changed paths:
M contrib/libvhost-user/libvhost-user-glib.c
M contrib/libvhost-user/libvhost-user-glib.h
M contrib/libvhost-user/libvhost-user.c
M contrib/libvhost-user/libvhost-user.h
M contrib/vhost-user-blk/vhost-user-blk.c
M contrib/vhost-user-gpu/main.c
M contrib/vhost-user-input/main.c
M contrib/vhost-user-scsi/vhost-user-scsi.c
M docs/interop/vhost-user.rst
M hw/block/vhost-user-blk.c
M hw/core/machine.c
M hw/core/numa.c
M hw/i386/Kconfig
M hw/i386/pc.c
M hw/i386/pc_piix.c
M hw/pci-bridge/pcie_root_port.c
M hw/pci-bridge/xio3130_downstream.c
M hw/pci/pcie.c
M hw/virtio/Kconfig
M hw/virtio/Makefile.objs
M hw/virtio/virtio-pci.c
M hw/virtio/virtio-pci.h
A hw/virtio/virtio-pmem-pci.c
A hw/virtio/virtio-pmem-pci.h
A hw/virtio/virtio-pmem.c
M hw/virtio/virtio.c
M include/hw/i386/pc.h
M include/hw/pci/pci.h
M include/hw/pci/pcie.h
A include/hw/virtio/virtio-pmem.h
M include/hw/virtio/virtio.h
M include/standard-headers/linux/virtio_ids.h
A include/standard-headers/linux/virtio_pmem.h
M monitor/hmp-cmds.c
M qapi/misc.json
M tests/vhost-user-bridge.c
Log Message:
-----------
Merge remote-tracking branch 'remotes/mst/tags/for_upstream' into staging
virtio, pc, pci: features, fixes, cleanups
virtio-pmem support.
libvhost user mq support.
A bunch of fixes all over the place.
Signed-off-by: Michael S. Tsirkin <address@hidden>
# gpg: Signature made Thu 04 Jul 2019 22:00:49 BST
# gpg: using RSA key 281F0DB8D28D5469
# gpg: Good signature from "Michael S. Tsirkin <address@hidden>" [full]
# gpg: aka "Michael S. Tsirkin <address@hidden>" [full]
# Primary key fingerprint: 0270 606B 6F3C DF3D 0B17 0970 C350 3912 AFBE 8E67
# Subkey fingerprint: 5D09 FD08 71C8 F85B 94CA 8A0D 281F 0DB8 D28D 5469
* remotes/mst/tags/for_upstream: (22 commits)
docs: avoid vhost-user-net specifics in multiqueue section
libvhost-user: implement VHOST_USER_PROTOCOL_F_MQ
libvhost-user: support many virtqueues
libvhost-user: add vmsg_set_reply_u64() helper
pc: Move compat_apic_id_mode variable to PCMachineClass
virtio: Don't change "started" flag on virtio_vmstate_change()
virtio: Make sure we get correct state of device on handle_aio_output()
virtio: Set "start_on_kick" on virtio_set_features()
virtio: Set "start_on_kick" for legacy devices
virtio: add "use-started" property
virtio-pci: fix missing device properties
pc: Support for virtio-pmem-pci
numa: Handle virtio-pmem in NUMA stats
hmp: Handle virtio-pmem when printing memory device infos
virtio-pci: Proxy for virtio-pmem
virtio-pmem: sync linux headers
virtio-pci: Allow to specify additional interfaces for the base type
virtio-pmem: add virtio device
pcie: minor cleanups for slot control/status
pcie: work around for racy guest init
...
Signed-off-by: Peter Maydell <address@hidden>
Compare: https://github.com/qemu/qemu/compare/57dfc2c4d51e...c35d17cabc1e
| [Prev in Thread] |
Current Thread |
[Next in Thread] |
- [Qemu-commits] [qemu/qemu] 861dc7: pcie: don't skip multi-mask events,
Peter Maydell <=