- 04 6月, 2019 5 次提交
-
-
由 Kevin Wolf 提交于
This makes use of qdev_prop_drive_iothread for scsi-disk so that the disk can be attached to a node that is already in the target AioContext. We need to check that the HBA actually supports iothreads, otherwise scsi-disk must make sure that the node is already in the main AioContext. This changes the error message for conflicting iothread settings. Previously, virtio-scsi produced the error message, now it comes from blk_set_aio_context(). Update a test case accordingly. Signed-off-by: NKevin Wolf <kwolf@redhat.com>
-
由 Kevin Wolf 提交于
Some qdev block devices have support for iothreads and take care of the AioContext they are running in, but most devices don't know about any of this. For the latter category, the qdev drive property must make sure that their BlockBackend is in the main AioContext. Unfortunately, while the current code just does the same thing for devices that do support iothreads, this is not correct and it would show as soon as we actually try to keep a consistent AioContext assignment across all nodes and users of a block graph subtree: If a node is already in a non-default AioContext because of one of its users, attaching a new device should still be possible if that device can work in the same AioContext. Switching the node back to the main context first and only then into the device AioContext causes failure (because the existing user wouldn't allow the switch to the main context). So devices that support iothreads need a different kind of drive property that leaves the node in its current AioContext, but by using this type, the device promises to check later that it can work with this context. This patch adds the qdev infrastructure that allows devices to signal that they handle iothreads and qdev should leave the AioContext alone. Signed-off-by: NKevin Wolf <kwolf@redhat.com>
-
由 Kevin Wolf 提交于
This adds a new parameter to blk_new() which requires its callers to declare from which AioContext this BlockBackend is going to be used (or the locks of which AioContext need to be taken anyway). The given context is only stored and kept up to date when changing AioContexts. Actually applying the stored AioContext to the root node is saved for another commit. Signed-off-by: NKevin Wolf <kwolf@redhat.com>
-
由 Kevin Wolf 提交于
Add an Error parameter to blk_set_aio_context() and use bdrv_child_try_set_aio_context() internally to check whether all involved nodes can actually support the AioContext switch. Signed-off-by: NKevin Wolf <kwolf@redhat.com>
-
由 Kenneth Heitke 提交于
Signed-off-by: NKenneth Heitke <kenneth.heitke@intel.com> Reviewed-by: NKlaus Birkelund Jensen <klaus.jensen@cnexlabs.com> Signed-off-by: NKevin Wolf <kwolf@redhat.com>
-
- 03 6月, 2019 8 次提交
-
-
由 Alex Williamson 提交于
Commit b2fc91db ("q35: set split kernel irqchip as default") changed the default for the pc-q35-4.0 machine type to use split irqchip, which turned out to have disasterous effects on vfio-pci INTx support. KVM resampling irqfds are registered for handling these interrupts, but these are non-functional in split irqchip mode. We can't simply test for split irqchip in QEMU as userspace handling of this interrupt is a significant performance regression versus KVM handling (GeForce GPUs assigned to Windows VMs are non-functional without forcing MSI mode or re-enabling kernel irqchip). The resolution is to revert the change in default irqchip mode in the pc-q35-4.1 machine and create a pc-q35-4.0.1 machine for the 4.0-stable branch. The qemu-q35-4.0 machine type should not be used in vfio-pci configurations for devices requiring legacy INTx support without explicitly modifying the VM configuration to use kernel irqchip. Link: https://bugs.launchpad.net/qemu/+bug/1826422 Fixes: b2fc91db ("q35: set split kernel irqchip as default") Signed-off-by: NAlex Williamson <alex.williamson@redhat.com> Reviewed-by: NPeter Xu <peterx@redhat.com> Message-Id: <155786484688.13873.6037015630912983760.stgit@gimli.home> Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
-
由 Paolo Bonzini 提交于
There is no need to have a test device created by the board. Instead, create it in the qtest so that we will be able to run it on other boards too. Reviewed-by: NThomas Huth <thuth@redhat.com> Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
-
由 Li Qiang 提交于
The dma related variable dma.dst/src/cnt is dma_addr_t, it is uint64_t in x64 platform. Change these usage from uint32_to uint64_t to avoid trancation in edu_dma_timer. Signed-off-by: NLi Qiang <liq3ea@163.com> Message-Id: <20190510164349.81507-4-liq3ea@163.com> Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
-
由 Li Qiang 提交于
The edu spec says when address >= 0x80, the MMIO area can be accessed by 64-bit. Signed-off-by: NLi Qiang <liq3ea@163.com> Reviewed-by: NPhilippe Mathieu-Daude <philmd@redhat.com> Message-Id: <20190510164349.81507-3-liq3ea@163.com> Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
-
由 Li Qiang 提交于
The edu spec says the MMIO area can be accessed by 64-bit. However currently the 'max_access_size' is not so the MMIO access dispatch can only access 32-bit one time. This patch fixes this to respect the spec. Signed-off-by: NLi Qiang <liq3ea@163.com> Reviewed-by: NPhilippe Mathieu-Daude <philmd@redhat.com> Message-Id: <20190510164349.81507-2-liq3ea@163.com> Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
-
由 Liran Alon 提交于
In order to perform a valid migration of a vhost-scsi device, the following requirements must be met: (1) The virtio-scsi device state needs to be saved & loaded. (2) The vhost backend must be stopped before virtio-scsi device state is saved: (2.1) Sync vhost backend state to virtio-scsi device state. (2.2) No further I/O requests are made by vhost backend to target SCSI device. (2.3) No further guest memory access takes place after VM is stopped. (3) Requests in-flight to target SCSI device are completed before migration handover. (4) Target SCSI device state needs to be saved & loaded into the destination host target SCSI device. Previous commit ("vhost-scsi: Add VMState descriptor") add support to save & load the device state using VMState. This meets requirement (1). When VM is stopped by migration thread (On Pre-Copy complete), the following code path is executed: migration_completion() -> vm_stop_force_state() -> vm_stop() -> do_vm_stop(). do_vm_stop() calls first pause_all_vcpus() which pause all guest vCPUs and then call vm_state_notify(). In case of vhost-scsi device, this will lead to the following code path to be executed: vm_state_notify() -> virtio_vmstate_change() -> virtio_set_status() -> vhost_scsi_set_status() -> vhost_scsi_stop(). vhost_scsi_stop() then calls vhost_scsi_clear_endpoint() and vhost_scsi_common_stop(). vhost_scsi_clear_endpoint() sends VHOST_SCSI_CLEAR_ENDPOINT ioctl to vhost backend which will reach kernel's vhost_scsi_clear_endpoint() which process all pending I/O requests and wait for them to complete (vhost_scsi_flush()). This meets requirement (3). vhost_scsi_common_stop() will stop the vhost backend. As part of this stop, dirty-bitmap is synced and vhost backend state is synced with virtio-scsi device state. As at this point guest vCPUs are already paused, this meets requirement (2). At this point we are left with requirement (4) which is target SCSI device specific and therefore cannot be done by QEMU. Which is the main reason why vhost-scsi adds a migration blocker. However, as this can be handled either by an external orchestrator or by using shared-storage (i.e. iSCSI), there is no reason to limit the orchestrator from being able to explictly specify it wish to enable migration even when VM have a vhost-scsi device. Considering all the above, this commit allows orchestrator to explictly specify that it is responsbile for taking care of requirement (4) and therefore vhost-scsi should not add a migration blocker. Reviewed-by: NNir Weiner <nir.weiner@oracle.com> Reviewed-by: NBijan Mottahedeh <bijan.mottahedeh@oracle.com> Signed-off-by: NLiran Alon <liran.alon@oracle.com> Message-Id: <20190416125912.44001-4-liran.alon@oracle.com> Reviewed-by: NMichael S. Tsirkin <mst@redhat.com> Signed-off-by: NMichael S. Tsirkin <mst@redhat.com> Reviewed-by: NStefan Hajnoczi <stefanha@redhat.com>
-
由 Nir Weiner 提交于
As preparation of enabling migration of vhost-scsi device, define it’s VMState. Note, we keep the convention of verifying in the pre_save() method that the vhost backend must be stopped before attempting to save the device state. Similar to how it is done for vhost-vsock. Reviewed-by: NBijan Mottahedeh <bijan.mottahedeh@oracle.com> Reviewed-by: NLiran Alon <liran.alon@oracle.com> Signed-off-by: NNir Weiner <nir.weiner@oracle.com> Message-Id: <20190416125912.44001-3-liran.alon@oracle.com> Reviewed-by: NMichael S. Tsirkin <mst@redhat.com> Signed-off-by: NMichael S. Tsirkin <mst@redhat.com> Reviewed-by: NStefan Hajnoczi <stefanha@redhat.com>
-
由 Nir Weiner 提交于
vhost-scsi doesn’t takes into account whether the VM is running or not in order to decide if it should start/stop vhost backend. This would lead to vhost backend still being active when VM's RunState suddenly change to stopped. An example of when this issue is encountered is when Live-Migration Pre-Copy phase completes. As in this case, VM state will be changed to stopped (while vhost backend is still active), which will result in virtio_vmstate_change() -> virtio_set_status() -> vhost_scsi_set_status() executed but vhost_scsi_set_status() will just return without stopping vhost backend. To handle this, change code to consider that vhost processing should be stopped when VM is not running. Similar to how it is done in vhost-vsock device at vhost_vsock_set_status(). Fixes: 5e9be92d ("vhost-scsi: new device supporting the tcm_vhost Linux kernel module”) Reviewed-by: NBijan Mottahedeh <bijan.mottahedeh@oracle.com> Reviewed-by: NLiran Alon <liran.alon@oracle.com> Signed-off-by: NNir Weiner <nir.weiner@oracle.com> Message-Id: <20190416125912.44001-2-liran.alon@oracle.com> Reviewed-by: NMichael S. Tsirkin <mst@redhat.com> Signed-off-by: NMichael S. Tsirkin <mst@redhat.com> Reviewed-by: NStefan Hajnoczi <stefanha@redhat.com>
-
- 30 5月, 2019 8 次提交
-
-
由 Jie Wang 提交于
fix memory leak in vhost_user_scsi_realize Signed-off-by: NJie Wang <wangjie88@huawei.com> Message-Id: <1556608500-12183-1-git-send-email-wangjie88@huawei.com> Reviewed-by: NMichael S. Tsirkin <mst@redhat.com> Signed-off-by: NMichael S. Tsirkin <mst@redhat.com> Reviewed-by: NStefan Hajnoczi <stefanha@redhat.com>
-
由 Jie Wang 提交于
fix incorrect print type in vhost_virtqueue_stop Signed-off-by: NJie Wang <wangjie88@huawei.com> Message-Id: <1556605773-42019-1-git-send-email-wangjie88@huawei.com> Reviewed-by: NMichael S. Tsirkin <mst@redhat.com> Signed-off-by: NMichael S. Tsirkin <mst@redhat.com> Reviewed-by: NPhilippe Mathieu-Daudé <philmd@redhat.com>
-
由 Jie Wang 提交于
remove the dead code Signed-off-by: NJie Wang <wangjie88@huawei.com> Message-Id: <1556604614-32081-1-git-send-email-wangjie88@huawei.com> Reviewed-by: NMichael S. Tsirkin <mst@redhat.com> Signed-off-by: NMichael S. Tsirkin <mst@redhat.com> Reviewed-by: NStefan Hajnoczi <stefanha@redhat.com>
-
由 David Gibson 提交于
The only remaining caller of pci_get_bus_devfn() is pci_nic_init_nofail(), itself an old compatibility function. Fold the two together to avoid re-using the stale interface. While we're there replace the explicit fprintf()s with error_report(). Signed-off-by: NDavid Gibson <david@gibson.dropbear.id.au> Message-Id: <20190513061939.3464-6-david@gibson.dropbear.id.au> Reviewed-by: NMichael S. Tsirkin <mst@redhat.com> Signed-off-by: NMichael S. Tsirkin <mst@redhat.com> Reviewed-by: NGreg Kurz <groug@kaod.org>
-
由 David Gibson 提交于
The is_bridge field in PCIDevice acts as a bool, but is declared as an int. Declare it as a bool for clarity, and change everything that writes it to use true/false instead of 0/1 to match. Signed-off-by: NDavid Gibson <david@gibson.dropbear.id.au> Reviewed-by: NGreg Kurz <groug@kaod.org> Message-Id: <20190513061939.3464-5-david@gibson.dropbear.id.au> Reviewed-by: NMichael S. Tsirkin <mst@redhat.com> Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>
-
由 David Gibson 提交于
Since c2077e2c "pci: Adjust PCI config limit based on bus topology", pci_adjust_config_limit() has been used in the config space read and write paths to only permit access to extended config space on buses which permit it. Specifically it prevents access on devices below a vanilla-PCI bus via some combination of bridges, even if both the host bridge and the device itself are PCI-E. It accomplishes this with a somewhat complex call up the chain of bridges to see if any of them prohibit extended config space access. This is overly complex, since we can always know if the bus will support such access at the point it is constructed. This patch simplifies the test by using a flag in the PCIBus instance indicating whether extended configuration space is accessible. It is false for vanilla PCI buses. For PCI-E buses, it is true for root buses and equal to the parent bus's's capability otherwise. For the special case of sPAPR's paravirtualized PCI root bus, which acts mostly like vanilla PCI, but does allow extended config space access, we override the default value of the flag from the host bridge code. This should cause no behavioural change. Signed-off-by: NDavid Gibson <david@gibson.dropbear.id.au> Reviewed-by: NGreg Kurz <groug@kaod.org> Message-Id: <20190513061939.3464-4-david@gibson.dropbear.id.au> Reviewed-by: NMichael S. Tsirkin <mst@redhat.com> Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>
-
由 Wei Yang 提交于
build_append_foo() API doesn't need explicit endianness conversions which eliminates a source of errors and it makes build_mcfg() look like declarative definition of MCFG table in ACPI spec, which makes it easy to review. Signed-off-by: NWei Yang <richardw.yang@linux.intel.com> Suggested-by: NIgor Mammedov <imammedo@redhat.com> Reviewed-by: NIgor Mammedov <imammedo@redhat.com> v3: * add some comment on the Configuration Space base address allocation structure v2: * miss the reserved[8] of MCFG in last version, add it back * drop SOBs and make sure bios-tables-test all OK Message-Id: <20190521062836.6541-3-richardw.yang@linux.intel.com> Reviewed-by: NMichael S. Tsirkin <mst@redhat.com> Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>
-
由 Wei Yang 提交于
Now we have two identical build_mcfg functions. Consolidate them in acpi/pci.c. Signed-off-by: NWei Yang <richardw.yang@linux.intel.com> v4: * ACPI_PCI depends on both ACPI and PCI * rebase on latest master, adjust arm Kconfig v3: * adjust changelog based on Igor's suggestion Message-Id: <20190521062836.6541-2-richardw.yang@linux.intel.com> Reviewed-by: NIgor Mammedov <imammedo@redhat.com> Reviewed-by: NMichael S. Tsirkin <mst@redhat.com> Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>
-
- 29 5月, 2019 19 次提交
-
-
由 Gerd Hoffmann 提交于
s/kbd/tablet/, fixes cut+paste bug. Cc: qemu-stable@nongnu.org Reported-by: NDr. David Alan Gilbert <dgilbert@redhat.com> Signed-off-by: NGerd Hoffmann <kraxel@redhat.com> Reviewed-by: NDr. David Alan Gilbert <dgilbert@redhat.com> Reviewed-by: NLaurent Vivier <lvivier@redhat.com> Reviewed-by: NPhilippe Mathieu-Daudé <philmd@redhat.com> Message-id: 20190520081805.15019-1-kraxel@redhat.com
-
由 Gerd Hoffmann 提交于
Add support for per port power switching. Virtual power of course ;) Use port-power=on property to enable this. Signed-off-by: NGerd Hoffmann <kraxel@redhat.com> Message-id: 20190524070310.4952-6-kraxel@redhat.com
-
由 Gerd Hoffmann 提交于
Helper function to update port status bits which depends on the connected device. We need the same logic for device attach and port reset, so factor it out. Signed-off-by: NGerd Hoffmann <kraxel@redhat.com> Reviewed-by: NPhilippe Mathieu-Daudé <philmd@redhat.com> Tested-by: NPhilippe Mathieu-Daudé <philmd@redhat.com> Message-id: 20190524070310.4952-5-kraxel@redhat.com
-
由 Gerd Hoffmann 提交于
Add usb_hub_port_set() and usb_hub_port_clear() helpers which care about updating the change bits (port->wPortChange) properly, so we don't need to have that logic sprinkled all over the place ;) Signed-off-by: NGerd Hoffmann <kraxel@redhat.com> Message-id: 20190524070310.4952-4-kraxel@redhat.com
-
由 Gerd Hoffmann 提交于
Add num_ports property which allows configure the number of downstream ports. Valid range is 1-8, default is 8. Signed-off-by: NGerd Hoffmann <kraxel@redhat.com> Message-id: 20190524070310.4952-3-kraxel@redhat.com
-
由 Gerd Hoffmann 提交于
Add dashes, so they don't look like two separate things when printed. Signed-off-by: NGerd Hoffmann <kraxel@redhat.com> Reviewed-by: NPhilippe Mathieu-Daudé <philmd@redhat.com> Tested-by: NPhilippe Mathieu-Daudé <philmd@redhat.com> Message-id: 20190524070310.4952-2-kraxel@redhat.com
-
由 Gerd Hoffmann 提交于
Seems some devices become confused when we call libusb_set_configuration(). So before calling the function check whenever the device has multiple configurations in the first place, and in case it hasn't (which is the case for the majority of devices) simply skip the call as it will have no effect anyway. Signed-off-by: NGerd Hoffmann <kraxel@redhat.com> Message-id: 20190522094702.17619-4-kraxel@redhat.com
-
由 Gerd Hoffmann 提交于
If the guest didn't talk to the device yet, skip the reset. Without this usb-host devices get resetted a number of times at boot time for no good reason. Signed-off-by: NGerd Hoffmann <kraxel@redhat.com> Message-id: 20190522094702.17619-3-kraxel@redhat.com
-
由 Gerd Hoffmann 提交于
That way the device reset handler can see what the before-reset state of the device is. Signed-off-by: NGerd Hoffmann <kraxel@redhat.com> Message-id: 20190522094702.17619-2-kraxel@redhat.com
-
由 Marc-André Lureau 提交于
Add new virtio-gpu devices with a "vhost-user" property. The associated vhost-user backend is used to handle the virtio rings and provide rendering results thanks to the vhost-user-gpu protocol. Example usage: -object vhost-user-backend,id=vug,cmd="./vhost-user-gpu" -device vhost-user-vga,vhost-user=vug Signed-off-by: NMarc-André Lureau <marcandre.lureau@redhat.com> Message-id: 20190524130946.31736-10-marcandre.lureau@redhat.com Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>
-
由 Marc-André Lureau 提交于
Add base classes that are common to vhost-user-gpu-pci and vhost-user-vga. Signed-off-by: NMarc-André Lureau <marcandre.lureau@redhat.com> Message-id: 20190524130946.31736-9-marcandre.lureau@redhat.com Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>
-
由 Marc-André Lureau 提交于
Add a base class that is common to virtio-gpu and vhost-user-gpu devices. The VirtIOGPUBase base class provides common functionalities necessary for both virtio-gpu and vhost-user-gpu: - common configuration (max-outputs, initial resolution, flags) - virtio device initialization, including queue setup - device pre-conditions checks (iommu) - migration blocker - virtio device callbacks - hooking up to qemu display subsystem - a few common helper functions to reset the device, retrieve display informations - a class callback to unblock the rendering (for GL updates) What is left to the virtio-gpu subdevice to take care of, in short, are all the virtio queues handling, command processing and migration. Signed-off-by: NMarc-André Lureau <marcandre.lureau@redhat.com> Message-id: 20190524130946.31736-8-marcandre.lureau@redhat.com Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>
-
由 Marc-André Lureau 提交于
This will allow to share the format conversion function with vhost-user-gpu. Signed-off-by: NMarc-André Lureau <marcandre.lureau@redhat.com> Message-id: 20190524130946.31736-4-marcandre.lureau@redhat.com Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>
-
由 Marc-André Lureau 提交于
The helper functions are useful to build the vhost-user-gpu backend. Signed-off-by: NMarc-André Lureau <marcandre.lureau@redhat.com> Message-id: 20190524130946.31736-3-marcandre.lureau@redhat.com Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>
-
由 Marc-André Lureau 提交于
Add a new vhost-user message to give a unix socket to a vhost-user backend for GPU display updates. Back when I started that work, I added a new GPU channel because the vhost-user protocol wasn't bidirectional. Since then, there is a vhost-user-slave channel for the slave to send requests to the master. We could extend it with GPU messages. However, the GPU protocol is quite orthogonal to vhost-user, thus I chose to have a new dedicated channel. See vhost-user-gpu.rst for the protocol details. Signed-off-by: NMarc-André Lureau <marcandre.lureau@redhat.com> Message-id: 20190524130946.31736-2-marcandre.lureau@redhat.com Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>
-
由 Cédric Le Goater 提交于
PRD (Processor recovery diagnostics) is a service available on OpenPower systems. The opal-prd daemon initializes the PowerPC Processor through the XSCOM bus and then waits for hardware diagnostic events. Signed-off-by: NCédric Le Goater <clg@kaod.org> Message-Id: <20190527071722.31424-1-clg@kaod.org> Signed-off-by: NDavid Gibson <david@gibson.dropbear.id.au>
-
由 Cédric Le Goater 提交于
Newer skiboots (after 6.3) support QEMU platforms that have characteristics closer to real OpenPOWER systems. The CPU type is used to define the BMC drivers: Aspeed AST2400 for POWER8 processors and AST2500 for POWER9s. Advertise the new platform property names, "qemu,powernv8" and "qemu,powernv9", using the CPU type chosen for the QEMU PowerNV machine. Also, advertise the original platform name "qemu,powernv" in case of POWER8 processors for compatibility with older skiboots. Signed-off-by: NCédric Le Goater <clg@kaod.org> Message-Id: <20190527071749.31499-1-clg@kaod.org> Signed-off-by: NDavid Gibson <david@gibson.dropbear.id.au>
-
由 Greg Kurz 提交于
Commit 0b8c89be7f7b added the hpt_maxpagesize capability to the migration stream. This is okay for new machine types but it breaks backward migration to older QEMUs, which don't expect the extra subsection. Add a compatibility boolean flag to the sPAPR machine class and use it to skip migration of the capability for machine types 4.0 and older. This fixes migration to an older QEMU. Note that the destination will emit a warning: qemu-system-ppc64: warning: cap-hpt-max-page-size lower level (16) in incoming stream than on destination (24) This is expected and harmless though. It is okay to migrate from a lower HPT maximum page size (64k) to a greater one (16M). Fixes: 0b8c89be7f7b "spapr: Add forgotten capability to migration stream" Based-on: <20190522074016.10521-3-clg@kaod.org> Signed-off-by: NGreg Kurz <groug@kaod.org> Message-Id: <155853262675.1158324.17301777846476373459.stgit@bahia.lan> Signed-off-by: NDavid Gibson <david@gibson.dropbear.id.au>
-
由 Cédric Le Goater 提交于
Now that XIVE support is complete (QEMU emulated and KVM devices), change the pseries machine to advertise both interrupt modes: XICS (P7/P8) and XIVE (P9). The machine default interrupt modes depends on the version. Current settings are: pseries default interrupt mode 4.1 dual 4.0 xics 3.1 xics 3.0 legacy xics (different IRQ number space layout) Signed-off-by: NCédric Le Goater <clg@kaod.org> Message-Id: <20190522074016.10521-3-clg@kaod.org> Reviewed-by: NGreg Kurz <groug@kaod.org> Signed-off-by: NDavid Gibson <david@gibson.dropbear.id.au>
-