aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2017-12-22smbus: do not immediately complete commandsHervé Poussineau
PIIX4 errata says that "immediate polling of the Host Status Register BUSY bit may indicate that the SMBus is NOT busy." Due to this, some code does the following steps: (a) set parameters (b) start command (c) check for smbus busy bit set (to know that command started) (d) check for smbus busy bit not set (to know that command finished) Let (c) happen, by immediately setting the busy bit, and really executing the command when status register has been read once. This fixes a problem with AMIBIOS, which can now properly initialize the PIIX4. Signed-off-by: Hervé Poussineau <hpoussin@reactos.org> Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
2017-12-22dump-guest-memory.py: fix "You can't do that without a process to debug"Marc-André Lureau
If the script is run with a core (no running process), it produces an error: (gdb) dump-guest-memory /tmp/vmcore X86_64 guest RAM blocks: target_start target_end host_addr message count ---------------- ---------------- ---------------- ------- ----- 0000000000000000 00000000000a0000 00007f7935800000 added 1 00000000000a0000 00000000000b0000 00007f7934200000 added 2 00000000000c0000 00000000000ca000 00007f79358c0000 added 3 00000000000ca000 00000000000cd000 00007f79358ca000 joined 3 00000000000cd000 00000000000e8000 00007f79358cd000 joined 3 00000000000e8000 00000000000f0000 00007f79358e8000 joined 3 00000000000f0000 0000000000100000 00007f79358f0000 joined 3 0000000000100000 0000000080000000 00007f7935900000 joined 3 00000000fd000000 00000000fe000000 00007f7934200000 added 4 00000000fffc0000 0000000100000000 00007f7935600000 added 5 Python Exception <class 'gdb.error'> You can't do that without a process to debug.: Error occurred in Python command: You can't do that without a process to debug. Replace the object_resolve_path_type() function call call with a local volatile variable. Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2017-12-22virtio-pci: Don't force Subsystem Vendor ID = Vendor IDLadi Prosek
The statement being removed doesn't change anything as virtio PCI devices already have Subsystem Vendor ID set to pci_default_sub_vendor_id (0x1af4), same as Vendor ID. And the Virtio spec does not require the two to be equal, either: "The PCI Subsystem Vendor ID and the PCI Subsystem Device ID MAY reflect the PCI Vendor and Device ID of the environment (for informational purposes by the driver)." Background: Following the recent virtio-win licensing change, several vendors are planning to ship their own certified version of Windows guest Virtio drivers, potentially taking advantage of Windows Update as a distribution channel. It is therefore critical that each vendor uses their own PCI Subsystem Vendor ID for Virtio devices to prevent drivers from other vendors binding to it. This would be trivially done by adding: k->subsystem_vendor_id = ... to virtio_pci_class_init(). Except for the problematic statement deleted by this patch, which reverts the Subsystem Vendor ID back to 0x1af4 for legacy devices for no good reason. Signed-off-by: Ladi Prosek <lprosek@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Reviewed-by: Gerd Hoffmann <kraxel@redhat.com>
2017-12-22intel_iommu: fix error param in stringPeter Xu
It should be caching-mode. It may confuse people when it pops up. Signed-off-by: Peter Xu <peterx@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Reviewed-by: Liu, Yi L <yi.l.liu@intel.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2017-12-22intel_iommu: remove X86_IOMMU_PCI_DEVFN_MAXPeter Xu
We have PCI_DEVFN_MAX now. Signed-off-by: Peter Xu <peterx@redhat.com> Reviewed-by: Liu, Yi L <yi.l.liu@intel.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2017-12-22vhost-user: document memory accessesStefan Hajnoczi
The vhost-user protocol specification does not define "guest address" and "user address". It does not explain how to access memory given such addresses. This patch explains how memory access works, including the IOTLB. Cc: Michael S. Tsirkin <mst@redhat.com> Cc: Maxime Coquelin <maxime.coquelin@redhat.com> Cc: Wei Wang <wei.w.wang@intel.com> Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Acked-by: Maxime Coquelin <maxime.coquelin@redhat.com>
2017-12-22vhost-user: fix indentation in protocol specificationStefan Hajnoczi
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2017-12-21hw/pci-host/xilinx: QOM'ify the AXI-PCIe host bridgePhilippe Mathieu-Daudé
Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Reviewed-by: Marcel Apfelbaum <marcel@redhat.com>
2017-12-21hw/pci-host/piix: QOM'ify the IGD Passthrough host bridgePhilippe Mathieu-Daudé
Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Reviewed-by: Marcel Apfelbaum <marcel@redhat.com>
2017-12-21tests/pxe-test: Add some extra testsDavid Gibson
Previously virtio-net was only tested for ppc64 in "slow" mode. That doesn't make much sense since virtio-net is used much more often in practice than the spapr-vlan device which was tested always. So, move virtio-net to always be tested on ppc64. We had no tests at all for the q35 machine, which doesn't seem wise given its increasing prominence. Add a couple of tests for it, including testing the newer e1000e adapter. Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Reviewed-by: Thomas Huth <thuth@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2017-12-21tests/pxe-test: Test net booting over IPv6 in some casesDavid Gibson
This adds IPv6 net boot testing (in addition to IPv4) when in slow test mode on ppc64 or s390. IPv6 PXE doesn't seem to work on x86, I'm guessing our BIOS image doesn't support it. Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Reviewed-by: Thomas Huth <thuth@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2017-12-21tests/pxe-test: Use table of testcases rather than open-codingDavid Gibson
Currently pxe-tests open codes the list of tests for each architecture. This changes it to use tables of test parameters, somewhat similar to boot-serial-test. This adds the machine type into the table as well, giving us the ability to perform tests on multiple machine types for architectures where there's more than one machine type that matters. NOTE: This changes the names of the tests in the output, to include the machine type and IPv4 vs. IPv6. I'm not sure if this has the potential to break existing tooling. Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Reviewed-by: Thomas Huth <thuth@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2017-12-21tests/pxe-test: Remove unnecessary special case test functionsDavid Gibson
All of the x86 and some of the other test cases here use a common test function, test_pxe_ipv4(), but one ppc and one s390 test use different functions. In the s390 case, this is completely pointless, the right parameter to test_pxe_ipv4() will already do exactly the right thing. For the spapr-vlan case there's a slight difference - it will use IPv6 instead of IPv4. But testing just one case with IPv6 (and NOT IPv4) is rather haphazard. Change everything to use the common test function, until we have a better way of testing IPv6 across the board. Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Reviewed-by: Thomas Huth <thuth@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2017-12-19virtio_error: don't invoke status callbacksMichael S. Tsirkin
Backends don't need to know what frontend requested a reset, and notifying then from virtio_error is messy because virtio_error itself might be invoked from backend. Let's just set the status directly. Cc: qemu-stable@nongnu.org Reported-by: Ilya Maximets <i.maximets@samsung.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2017-12-05pci: Eliminate pci_find_primary_bus()David Gibson
pci_find_primary_bus() only has one user, in pc_xen_hvm_init(). That's inside the machine construction code, so it already has easy access to the machine's primary PCI bus. Get it directly, and thereby remove pci_find_primary_bus(). This removes one of only a handful of users of the ugly pci_host_bridges global. Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Reviewed-by: Marcel Apfelbaum <marcel@redhat.com> Reviewed-by: Peter Xu <peterx@redhat.com>
2017-12-05pci: Eliminate redundant PCIDevice::bus pointerDavid Gibson
The bus pointer in PCIDevice is basically redundant with QOM information. It's always initialized to the qdev_get_parent_bus(), the only difference is the type. Therefore this patch eliminates the field, instead creating a pci_get_bus() helper to do the type mangling to derive it conveniently from the QOM Device object underneath. Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Reviewed-by: Eduardo Habkost <ehabkost@redhat.com> Reviewed-by: Marcel Apfelbaum <marcel@redhat.com> Reviewed-by: Peter Xu <peterx@redhat.com>
2017-12-05pci: Add pci_dev_bus_num() helperDavid Gibson
A fair proportion of the users of pci_bus_num() want to get the bus number on a specific device, so first have to look up the bus from the device then call it. This adds a helper to do that (since we're going to make looking up the bus slightly more verbose). Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Reviewed-by: Marcel Apfelbaum <marcel@redhat.com> Reviewed-by: Peter Xu <peterx@redhat.com>
2017-12-05pci: Move bridge data structures from pci_bus.h to pci_bridge.hDavid Gibson
include/hw/pci/pci_bus.h contains several data structures related to PCI bridges that aren't needed by most users of pci_bus.h. We already have a pci_bridge.h, so move them there. Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Reviewed-by: Marcel Apfelbaum <marcel@redhat.com> Reviewed-by: Peter Xu <peterx@redhat.com>
2017-12-05pci: Rename root bus initialization functions for clarityDavid Gibson
pci_bus_init(), pci_bus_new_inplace(), pci_bus_new() and pci_register_bus() are misleadingly named. They're not used for initializing *any* PCI bus, but only for a root PCI bus. Non-root buses - i.e. ones under a logical PCI to PCI bridge - are instead created with a direct qbus_create_inplace() (see pci_bridge_initfn()). This patch renames the functions to make it clear they're only used for a root bus. Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Reviewed-by: Marcel Apfelbaum <marcel@redhat.com> Reviewed-by: Peter Xu <peterx@redhat.com>
2017-12-05tests: add test to check VirtQueue objectPrasad J Pandit
An uninitialised VirtQueue object or one with Vring.align field set to zero(0) could lead to arithmetic exceptions. Add a unit test to validate it. Signed-off-by: Prasad J Pandit <pjp@fedoraproject.org> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
2017-12-05vmgenid: use UUID property typeRoman Kagan
Switch vmgenid device to use the UUID property type introduced in the previous patch for its 'guid' property. One semantic change it introduces is that post-realize modification of 'guid' via HMP or QMP will now be rejected with an error; however, according to docs/specs/vmgenid.txt this is actually desirable. Signed-off-by: Roman Kagan <rkagan@virtuozzo.com> Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com> Reviewed-by: Ben Warren <ben@skyportsystems.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2017-12-05qdev-properties: add UUID property typeRoman Kagan
UUIDs (GUIDs) are widely used in VMBus-related stuff, so a dedicated property type becomes helpful. The property accepts a string-formatted UUID or a special keyword "auto" meaning a randomly generated UUID; the latter is also the default when the property is not given a value explicitly. Signed-off-by: Roman Kagan <rkagan@virtuozzo.com> Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2017-12-05smbios: support setting OEM strings tableDaniel P. Berrange
The cloud-init program currently allows fetching of its data by repurposing of the 'system' type 'serial' field. This is a clear abuse of the serial field that would clash with other valid usage a virt management app might have for that field. Fortunately the SMBIOS defines an "OEM Strings" table whose puporse is to allow exposing of arbitrary vendor specific strings to the operating system. This is perfect for use with cloud-init, or as a way to pass arguments to OS installers such as anaconda. This patch makes it easier to support this with QEMU. e.g. $QEMU -smbios type=11,value=Hello,value=World,value=Tricky,,value=test Which results in the guest seeing dmidecode data Handle 0x0E00, DMI type 11, 5 bytes OEM Strings String 1: Hello String 2: World String 3: Tricky,value=test It is suggested that any app wanting to make use of this OEM strings capability for accepting data from the host mgmt layer should use its name as a string prefix. e.g. to expose OEM strings targetting both cloud init and anaconda in parallel the mgmt app could set $QEMU -smbios type=11,value=cloud-init:ds=nocloud-net;s=http://10.10.0.1:8000/,\ value=anaconda:method=http://dl.fedoraproject.org/pub/fedora/linux/releases/25/x86_64/os which would appear as Handle 0x0E00, DMI type 11, 5 bytes OEM Strings String 1: cloud-init:ds=nocloud-net;s=http://10.10.0.1:8000/ String 2: anaconda:method=http://dl.fedoraproject.org/pub/fedora/linux/releases/25/x86_64/os Use of such string prefixes means the app won't have to care which string slot its data appears in. Signed-off-by: Daniel P. Berrange <berrange@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2017-12-05Update version for v2.11.0-rc4 releasev2.11.0-rc4Peter Maydell
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2017-12-05vhost-scsi: add missing virtqueue_size parameterEric Farman
Commit 5c0919d02066 ("virtio-scsi: Add virtqueue_size parameter allowing virtqueue size to be set.") introduced a new parameter to virtio-scsi. Later, commit 920036106044 ("vhost-user-scsi: add missing virtqueue_size param") added that parameter to the new vhost-user-scsi interface but neglected the existing vhost-scsi interface it was built on. Apply the same change to vhost-scsi, so that we can boot a guest with a device defined. This also avoids crashing a guest when hotplugging a vhost-scsi device. Signed-off-by: Eric Farman <farman@linux.vnet.ibm.com> Message-id: 20171201151538.6844-2-farman@linux.vnet.ibm.com Reviewed-by: Paolo Bonzini <pbonzini@redhat.com> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2017-12-05Merge remote-tracking branch 'remotes/dgibson/tags/ppc-for-2.11-20171205' ↵Peter Maydell
into staging ppc patch queue 2017-12-05 Alas, this is yet another fix for ppc that I think it's worth squeezing into 2.11. It's a really ugly fix for some pretty ugly code, but it does seem to address a real problem. It's also a problem that's appeared relatively recently, since it was either created by, or made much easier to trigger by, by the merge of MTTCG. # gpg: Signature made Tue 05 Dec 2017 05:24:04 GMT # gpg: using RSA key 0x6C38CACA20D9B392 # gpg: Good signature from "David Gibson <david@gibson.dropbear.id.au>" # gpg: aka "David Gibson (Red Hat) <dgibson@redhat.com>" # gpg: aka "David Gibson (ozlabs.org) <dgibson@ozlabs.org>" # gpg: aka "David Gibson (kernel.org) <dwg@kernel.org>" # Primary key fingerprint: 75F4 6586 AE61 A66C C44E 87DC 6C38 CACA 20D9 B392 * remotes/dgibson/tags/ppc-for-2.11-20171205: target/ppc: Fix system lockups caused by interrupt_request state corruption Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2017-12-05target/ppc: Fix system lockups caused by interrupt_request state corruptionRichard Purdie
Occasionally in Linux guests on x86_64 we're seeing logs like: ppc_set_irq: 0x55b4e0d562f0 n_IRQ 8 level 1 => pending 00000100req 00000004 when they should read: ppc_set_irq: 0x55b4e0d562f0 n_IRQ 8 level 1 => pending 00000100req 00000002 The "00000004" is CPU_INTERRUPT_EXITTB yet the code calls cpu_interrupt(cs, CPU_INTERRUPT_HARD) ("00000002") in this function just before the log message. Something is causing the HARD bit setting to get lost. The knock on effect of losing that bit is the decrementer timer interrupts don't get delivered which causes the guest to sit idle in its idle handler and 'hang'. The issue occurs due to races from code which sets CPU_INTERRUPT_EXITTB. Rather than poking directly into cs->interrupt_request, that code needs to: a) hold BQL b) use the cpu_interrupt() helper This patch fixes the call sites to do this, fixing the hang. The calls are made from a variety of contexts so a helper function is added to handle the necessary locking. This can likely be improved and optimised in the future but it ensures the code is correct and doesn't lockup as it stands today. Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2017-12-04Merge remote-tracking branch 'remotes/kevin/tags/for-upstream' into stagingPeter Maydell
Block layer patches for 2.11.0-rc4 # gpg: Signature made Mon 04 Dec 2017 16:46:07 GMT # gpg: using RSA key 0x7F09B272C88F2FD6 # gpg: Good signature from "Kevin Wolf <kwolf@redhat.com>" # Primary key fingerprint: DC3D EB15 9A9A F95D 3D74 56FE 7F09 B272 C88F 2FD6 * remotes/kevin/tags/for-upstream: blockjob: Make block_job_pause_all() keep a reference to the jobs Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2017-12-04blockjob: Make block_job_pause_all() keep a reference to the jobsAlberto Garcia
Starting from commit 40840e419be31e6a32e6ea24511c74b389d5e0e4 we are pausing all block jobs during bdrv_reopen_multiple() to prevent any of them from finishing and removing nodes from the graph while they are being reopened. It turns out that pausing a block job doesn't necessarily prevent it from finishing: a paused block job can still run its exit function from the main loop and call block_job_completed(). The mirror block job in particular always goes to the main loop while it is paused (by virtue of the bdrv_drained_begin() call in mirror_run()). Destroying a paused block job during bdrv_reopen_multiple() has two consequences: 1) The references to the nodes involved in the job are released, possibly destroying some of them. If those nodes were in the reopen queue this would trigger the problem originally described in commit 40840e419be, crashing QEMU. 2) At the end of bdrv_reopen_multiple(), bdrv_drain_all_end() would not be doing all necessary bdrv_parent_drained_end() calls. I can reproduce problem 1) easily with iotest 030 by increasing STREAM_BUFFER_SIZE from 512KB to 8MB in block/stream.c, or by tweaking the iotest like in this example: https://lists.gnu.org/archive/html/qemu-block/2017-11/msg00934.html This patch keeps an additional reference to all block jobs between block_job_pause_all() and block_job_resume_all(), guaranteeing that they are kept alive. Signed-off-by: Alberto Garcia <berto@igalia.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2017-12-04Merge remote-tracking branch 'remotes/mst/tags/for_upstream' into stagingPeter Maydell
pc, pci, virtio: fixes for rc3 A bunch of fixes all over the place. Signed-off-by: Michael S. Tsirkin <mst@redhat.com> # gpg: Signature made Fri 01 Dec 2017 17:06:33 GMT # gpg: using RSA key 0x281F0DB8D28D5469 # gpg: Good signature from "Michael S. Tsirkin <mst@kernel.org>" # gpg: aka "Michael S. Tsirkin <mst@redhat.com>" # 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: pc: fix crash on attempted cpu unplug virtio: check VirtQueue Vring object is set vhost: fix error check in vhost_verify_ring_mappings() dump-guest-memory.py: fix No symbol "vmcoreinfo_find" vhost: restore avail index from vring used index on disconnection virtio: Add queue interface to restore avail index from vring used index i386/msi: Correct mask of destination ID in MSI address Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2017-12-04Merge remote-tracking branch 'remotes/dgibson/tags/ppc-for-2.11-20171204' ↵Peter Maydell
into staging ppc patch queue 2017-12-04 We are, alas, not yet to the bottom of ppc bugs. This pull request fixes several more. I believe they're important enough to include in 2.11. despite the late date. # gpg: Signature made Mon 04 Dec 2017 03:40:56 GMT # gpg: using RSA key 0x6C38CACA20D9B392 # gpg: Good signature from "David Gibson <david@gibson.dropbear.id.au>" # gpg: aka "David Gibson (Red Hat) <dgibson@redhat.com>" # gpg: aka "David Gibson (ozlabs.org) <dgibson@ozlabs.org>" # gpg: aka "David Gibson (kernel.org) <dwg@kernel.org>" # Primary key fingerprint: 75F4 6586 AE61 A66C C44E 87DC 6C38 CACA 20D9 B392 * remotes/dgibson/tags/ppc-for-2.11-20171204: spapr: Include "pre-plugged" DIMMS in ram size calculation at reset target-ppc: Don't invalidate non-supported msr bits pseries: fix TCG migration Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2017-12-04spapr: Include "pre-plugged" DIMMS in ram size calculation at resetDavid Gibson
At guest reset time, we allocate a hash page table (HPT) for the guest based on the guest's RAM size. If dynamic HPT resizing is not available we use the maximum RAM size, if it is we use the current RAM size. But the "current RAM size" calculation is incorrect - we just use the "base" ram_size from the machine structure. This doesn't include any pluggable DIMMs that are already plugged at reset time. This means that if you try to start a 'pseries' machine with a DIMM specified on the command line that's much larger than the "base" RAM size, then the guest will get a woefully inadequate HPT. This can lead to a guest freeze during boot as it runs out of HPT space during initial MMU setup. Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Reviewed-by: Greg Kurz <groug@kaod.org> Tested-by: Greg Kurz <groug@kaod.org>
2017-12-01pc: fix crash on attempted cpu unplugIgor Mammedov
when qemu is started with '-no-acpi' CLI option, an attempt to unplug a CPU using device_del results in null pointer dereference at: #0 object_get_class #1 pc_machine_device_unplug_request_cb #2 qmp_marshal_device_del which is caused by pcms->acpi_dev == NULL due to ACPI support being disabled. Considering that ACPI support is necessary for unplug to work, check that it's enabled and fail unplug request gracefully if no acpi device were found. Signed-off-by: Igor Mammedov <imammedo@redhat.com> Reviewed-by: Eduardo Habkost <ehabkost@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2017-12-01virtio: check VirtQueue Vring object is setPrasad J Pandit
A guest could attempt to use an uninitialised VirtQueue object or unset Vring.align leading to a arithmetic exception. Add check to avoid it. Reported-by: Zhangboxian <zhangboxian@huawei.com> Signed-off-by: Prasad J Pandit <pjp@fedoraproject.org> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> Reviewed-by: Cornelia Huck <cohuck@redhat.com>
2017-12-01vhost: fix error check in vhost_verify_ring_mappings()Greg Kurz
Since commit f1f9e6c5 "vhost: adapt vhost_verify_ring_mappings() to virtio 1 ring layout", we check the mapping of each part (descriptor table, available ring and used ring) of each virtqueue separately. The checking of a part is done by the vhost_verify_ring_part_mapping() function: it returns either 0 on success or a negative errno if the part cannot be mapped at the same place. Unfortunately, the vhost_verify_ring_mappings() function checks its return value the other way round. It means that we either: - only verify the descriptor table of the first virtqueue, and if it is valid we ignore all the other mappings - or ignore all broken mappings until we reach a valid one ie, we only raise an error if all mappings are broken, and we consider all mappings are valid otherwise (false success), which is obviously wrong. This patch ensures that vhost_verify_ring_mappings() only returns success if ALL mappings are okay. Reported-by: Dr. David Alan Gilbert <dgilbert@redhat.com> Signed-off-by: Greg Kurz <groug@kaod.org> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2017-12-01dump-guest-memory.py: fix No symbol "vmcoreinfo_find"Marc-André Lureau
When qemu is compiled without debug, the dump gdb python script can fail with: Error occurred in Python command: No symbol "vmcoreinfo_find" in current context. Because vmcoreinfo_find() is inlined and not exported. Use the underlying object_resolve_path_type() to get the instance instead. Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2017-12-01vhost: restore avail index from vring used index on disconnectionMaxime Coquelin
vhost_virtqueue_stop() gets avail index value from the backend, except if the backend is not responding. It happens when the backend crashes, and in this case, internal state of the virtio queue is inconsistent, making packets to corrupt the vring state. With a Linux guest, it results in following error message on backend reconnection: [ 22.444905] virtio_net virtio0: output.0:id 0 is not a head! [ 22.446746] net enp0s3: Unexpected TXQ (0) queue failure: -5 [ 22.476360] net enp0s3: Unexpected TXQ (0) queue failure: -5 Fixes: 283e2c2adcb8 ("net: virtio-net discards TX data after link down") Cc: qemu-stable@nongnu.org Signed-off-by: Maxime Coquelin <maxime.coquelin@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2017-12-01virtio: Add queue interface to restore avail index from vring used indexMaxime Coquelin
In case of backend crash, it is not possible to restore internal avail index from the backend value as vhost_get_vring_base callback fails. This patch provides a new interface to restore internal avail index from the vring used index, as done by some vhost-user backend on reconnection. Signed-off-by: Maxime Coquelin <maxime.coquelin@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2017-12-01i386/msi: Correct mask of destination ID in MSI addressChao Gao
According to SDM 10.11.1, only [19:12] bits of MSI address are Destination ID, change the mask to avoid ambiguity for VT-d spec has used the bit 4 to indicate a remappable interrupt request. Signed-off-by: Chao Gao <chao.gao@intel.com> Signed-off-by: Lan Tianyu <tianyu.lan@intel.com> Reviewed-by: Anthony PERARD <anthony.perard@citrix.com> Reviewed-by: Peter Xu <peterx@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2017-11-30target-ppc: Don't invalidate non-supported msr bitsKurban Mallachiev
The msr invalidation code (commits 993eb and 2360b) inverts all bits except MSR_TGPR and MSR_HVB. On non PowerPC 601 processors this leads to incorrect change of excp_prefix in hreg_store_msr() function. The problem is that new msr value get multiplied by msr_mask and inverted msr does not, thus values of MSR_EP bit in new msr value and inverted msr are distinct, so that excp_prefix changes but should not. Signed-off-by: Kurban Mallachiev <mallachiev@ispras.ru> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2017-11-30pseries: fix TCG migrationLaurent Vivier
Migration of pseries is broken with TCG because QEMU tries to restore KVM MMU state unconditionally. The result is a SIGSEGV in kvm_vm_ioctl(): #0 kvm_vm_ioctl (s=0x0, type=-2146390353) at qemu/accel/kvm/kvm-all.c:2032 #1 0x00000001003e3e2c in kvmppc_configure_v3_mmu (cpu=<optimized out>, radix=<optimized out>, gtse=<optimized out>, proc_tbl=<optimized out>) at qemu/target/ppc/kvm.c:396 #2 0x00000001002f8b88 in spapr_post_load (opaque=0x1019103c0, version_id=<optimized out>) at qemu/hw/ppc/spapr.c:1578 #3 0x000000010059e4cc in vmstate_load_state (f=0x106230000, vmsd=0x1009479e0 <vmstate_spapr>, opaque=0x1019103c0, version_id=<optimized out>) at qemu/migration/vmstate.c:165 #4 0x00000001005987e0 in vmstate_load (f=<optimized out>, se=<optimized out>) at qemu/migration/savevm.c:748 This patch fixes the problem by not calling the KVM function with the TCG mode. Fixes: d39c90f5f3 ("spapr: Fix migration of Radix guests") Signed-off-by: Laurent Vivier <lvivier@redhat.com> Reviewed-by: Suraj Jitindar Singh <sjitindarsingh@gmail.com> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2017-11-29Update version for v2.11.0-rc3 releasev2.11.0-rc3Peter Maydell
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2017-11-29Merge remote-tracking branch 'remotes/kevin/tags/for-upstream' into stagingPeter Maydell
Block layer patches for 2.11.0-rc3 # gpg: Signature made Wed 29 Nov 2017 15:25:13 GMT # gpg: using RSA key 0x7F09B272C88F2FD6 # gpg: Good signature from "Kevin Wolf <kwolf@redhat.com>" # Primary key fingerprint: DC3D EB15 9A9A F95D 3D74 56FE 7F09 B272 C88F 2FD6 * remotes/kevin/tags/for-upstream: block/nfs: fix nfs_client_open for filesize greater than 1TB blockjob: reimplement block_job_sleep_ns to allow cancellation blockjob: introduce block_job_do_yield blockjob: remove clock argument from block_job_sleep_ns block: Expect graph changes in bdrv_parent_drained_begin/end blockjob: Remove the job from the list earlier in block_job_unref() QAPI & interop: Clarify events emitted by 'block-job-cancel' qemu-options: Mention locking option of file driver docs: Add image locking subsection iotests: fix 075 and 078 Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2017-11-29Merge remote-tracking branch 'mreitz/tags/pull-block-2017-11-29' into ↵Kevin Wolf
queue-block One block patch for 2.11.0-rc3 # gpg: Signature made Wed Nov 29 15:28:38 2017 CET # gpg: using RSA key F407DB0061D5CF40 # gpg: Good signature from "Max Reitz <mreitz@redhat.com>" # Primary key fingerprint: 91BE B60A 30DB 3E88 57D1 1829 F407 DB00 61D5 CF40 * mreitz/tags/pull-block-2017-11-29: block/nfs: fix nfs_client_open for filesize greater than 1TB Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2017-11-29block/nfs: fix nfs_client_open for filesize greater than 1TBPeter Lieven
DIV_ROUND_UP(st.st_size, BDRV_SECTOR_SIZE) was overflowing ret (int) if st.st_size is greater than 1TB. Cc: qemu-stable@nongnu.org Signed-off-by: Peter Lieven <pl@kamp.de> Message-id: 1511798407-31129-1-git-send-email-pl@kamp.de Signed-off-by: Max Reitz <mreitz@redhat.com>
2017-11-29blockjob: reimplement block_job_sleep_ns to allow cancellationPaolo Bonzini
This reverts the effects of commit 4afeffc857 ("blockjob: do not allow coroutine double entry or entry-after-completion", 2017-11-21) This fixed the symptom of a bug rather than the root cause. Canceling the wait on a sleeping blockjob coroutine is generally fine, we just need to make it work correctly across AioContexts. To do so, use a QEMUTimer that calls block_job_enter. Use a mutex to ensure that block_job_enter synchronizes correctly with block_job_sleep_ns. Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Tested-By: Jeff Cody <jcody@redhat.com> Reviewed-by: Fam Zheng <famz@redhat.com> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> Reviewed-by: Jeff Cody <jcody@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2017-11-29blockjob: introduce block_job_do_yieldPaolo Bonzini
Hide the clearing of job->busy in a single function, and set it in block_job_enter. This lets block_job_do_yield verify that qemu_coroutine_enter is not used while job->busy = false. Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Tested-By: Jeff Cody <jcody@redhat.com> Reviewed-by: Fam Zheng <famz@redhat.com> Reviewed-by: Jeff Cody <jcody@redhat.com> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2017-11-29blockjob: remove clock argument from block_job_sleep_nsPaolo Bonzini
All callers are using QEMU_CLOCK_REALTIME, and it will not be possible to support more than one clock when block_job_sleep_ns switches to a single timer stored in the BlockJob struct. Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Reviewed-by: Alberto Garcia <berto@igalia.com> Tested-By: Jeff Cody <jcody@redhat.com> Reviewed-by: Fam Zheng <famz@redhat.com> Reviewed-by: Jeff Cody <jcody@redhat.com> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2017-11-29block: Expect graph changes in bdrv_parent_drained_begin/endKevin Wolf
The .drained_begin/end callbacks can (directly or indirectly via aio_poll()) cause block nodes to be removed or the current BdrvChild to point to a different child node. Use QLIST_FOREACH_SAFE() to make sure we don't access invalid BlockDriverStates or accidentally continue iterating the parents of the new child node instead of the node we actually came from. Signed-off-by: Kevin Wolf <kwolf@redhat.com> Tested-by: Jeff Cody <jcody@redhat.com> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> Reviewed-by: Jeff Cody <jcody@redhat.com> Reviewed-by: Alberto Garcia <berto@igalia.com> Reviewed-by: Fam Zheng <famz@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2017-11-28blockjob: Remove the job from the list earlier in block_job_unref()Alberto Garcia
When destroying a block job in block_job_unref() we should remove it from the job list before calling block_job_remove_all_bdrv(). This is because removing the BDSs can trigger an aio_poll() and wake up other jobs that might attempt to use the block job list. If that happens the job we're currently destroying should not be in that list anymore. Signed-off-by: Alberto Garcia <berto@igalia.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>