summary refs log tree commit diff stats
path: root/hw/core/machine.c (follow)
Commit message (Collapse)AuthorAgeFilesLines
...
* vl: extract validation of -smp to machine.cPaolo Bonzini2020-12-101-0/+23
| | | | | | | | | Once smp_parse is done, the validation operates on the MachineState. There is no reason for that code to be in vl.c. Reviewed-by: Igor Mammedov <imammedo@redhat.com> Tested-by: Igor Mammedov <imammedo@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
* hw: add compat machines for 6.0Cornelia Huck2020-12-081-0/+3
| | | | | | | | | | | Add 6.0 machine types for arm/i440fx/q35/s390x/spapr. Signed-off-by: Cornelia Huck <cohuck@redhat.com> Message-Id: <20201109173928.1001764-1-cohuck@redhat.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>
* pvpanic: Advertise the PVPANIC_CRASHLOADED event supportPaolo Bonzini2020-11-111-0/+1
| | | | | | | | | | | Advertise both types of events as supported when the guest OS queries the pvpanic device. Currently only PVPANIC_PANICKED is exposed; PVPANIC_CRASHLOADED must also be advertised, but only on new machine types. Fixes: 7dc58deea79a ("pvpanic: implement crashloaded event handling") Reported-by: Alejandro Jimenez <alejandro.j.jimenez@oracle.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
* hw/block/nvme: change controller pci idKlaus Jensen2020-10-271-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | There are two reasons for changing this: 1. The nvme device currently uses an internal Intel device id. 2. Since commits "nvme: fix write zeroes offset and count" and "nvme: support multiple namespaces" the controller device no longer has the quirks that the Linux kernel think it has. As the quirks are applied based on pci vendor and device id, change them to get rid of the quirks. To keep backward compatibility, add a new 'use-intel-id' parameter to the nvme device to force use of the Intel vendor and device id. This is off by default but add a compat property to set this for 5.1 machines and older. If a 5.1 machine is booted (or the use-intel-id parameter is explicitly set to true), the Linux kernel will just apply these unnecessary quirks: 1. NVME_QUIRK_IDENTIFY_CNS which says that the device does not support anything else than values 0x0 and 0x1 for CNS (Identify Namespace and Identify Namespace). With multiple namespace support, this just means that the kernel will "scan" namespaces instead of using "Active Namespace ID list" (CNS 0x2). 2. NVME_QUIRK_DISABLE_WRITE_ZEROES. The nvme device started out with a broken Write Zeroes implementation which has since been fixed in commit 9d6459d21a6e ("nvme: fix write zeroes offset and count"). Signed-off-by: Klaus Jensen <k.jensen@samsung.com> Reviewed-by: Keith Busch <kbusch@kernel.org> Reviewed-by: Maxim Levitsky <mlevitsk@redhat.com>
* machine: move SMP initialization from vl.cPaolo Bonzini2020-10-261-0/+7
| | | | | | | | Initialize the object's values from the class when the object is created, no need to have vl.c do it for us. Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
* machine: move UP defaults to class_base_initPaolo Bonzini2020-10-261-1/+5
| | | | | | | | Clean up vl.c, default min/max/default_cpus to uniprocessor directly in the QOM class initialization code. Reviewed-by: Thomas Huth <thuth@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
* machine: remove deprecated -machine enforce-config-section optionPaolo Bonzini2020-10-261-23/+0
| | | | | | | Deprecated since 3.1 and complicates the initialization sequence, remove it. Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
* cpu: Introduce CPU model deprecation APIRobert Hoo2020-10-141-2/+10
| | | | | | | | | | | | | | | | | | | Implement the ability of marking some versions deprecated. When that CPU model is chosen, print a warning. The warning message can be customized, e.g. suggesting an alternative CPU model to be used instead. The deprecation message will be printed by x86_cpu_list_entry(), e.g. '-cpu help'. QMP command 'query-cpu-definitions' will return a bool value indicating the deprecation status. Signed-off-by: Robert Hoo <robert.hu@linux.intel.com> Message-Id: <1600758855-80046-1-git-send-email-robert.hu@linux.intel.com> [ehabkost: reword commit message] [ehabkost: Handle NULL cpu_type] Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
* numa: drop support for '-numa node' (without memory specified)Igor Mammedov2020-09-301-1/+0
| | | | | | | | | | | | | | | | it was deprecated since 4.1 commit 4bb4a2732e (numa: deprecate implict memory distribution between nodes) Users of existing VMs, wishing to preserve the same RAM distribution, should configure it explicitly using ``-numa node,memdev`` options. Current RAM distribution can be retrieved using HMP command `info numa` and if separate memory devices (pc|nv-dimm) are present use `info memory-device` and subtract device memory from output of `info numa`. Signed-off-by: Igor Mammedov <imammedo@redhat.com> Message-Id: <20200911084410.788171-2-imammedo@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
* virtio: skip legacy support check on machine types less than 5.1Stefano Garzarella2020-09-291-0/+1
| | | | | | | | | | | | | | | | | | | | | | | Commit 9b3a35ec82 ("virtio: verify that legacy support is not accidentally on") added a check that returns an error if legacy support is on, but the device does not support legacy. Unfortunately some devices were wrongly declared legacy capable even if they were not (e.g vhost-vsock). To avoid migration issues, we add a virtio-device property (x-disable-legacy-check) to skip the legacy error, printing a warning instead, for machine types < 5.1. Cc: qemu-stable@nongnu.org Fixes: 9b3a35ec82 ("virtio: verify that legacy support is not accidentally on") Suggested-by: Dr. David Alan Gilbert <dgilbert@redhat.com> Suggested-by: Cornelia Huck <cohuck@redhat.com> Reviewed-by: Cornelia Huck <cohuck@redhat.com> Signed-off-by: Stefano Garzarella <sgarzare@redhat.com> Message-Id: <20200921122506.82515-2-sgarzare@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
* machine: Register "memory-backend" as class propertyEduardo Habkost2020-09-221-6/+6
| | | | | | | | | | Class properties make QOM introspection simpler and easier, as they don't require an object to be instantiated. Signed-off-by: Eduardo Habkost <ehabkost@redhat.com> Reviewed-by: Igor Mammedov <imammedo@redhat.com> Message-Id: <20200921221045.699690-21-ehabkost@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
* smp: drop support for deprecated (invalid topologies)Igor Mammedov2020-09-221-12/+4
| | | | | | | | | | | | | it's was deprecated since 3.1 Support for invalid topologies is removed, the user must ensure that topologies described with -smp include all possible cpus, i.e. (sockets * cores * threads) == maxcpus or QEMU will exit with error. Signed-off-by: Igor Mammedov <imammedo@redhat.com> Message-Id: <20200911133202.938754-1-imammedo@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
* vhost-user-blk-pci: default num_queues to -smp NStefan Hajnoczi2020-08-271-0/+1
| | | | | | | | | | | | | | | Automatically size the number of request virtqueues to match the number of vCPUs. This ensures that completion interrupts are handled on the same vCPU that submitted the request. No IPI is necessary to complete an I/O request and performance is improved. The maximum number of MSI-X vectors and virtqueues limit are respected. Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com> Reviewed-by: Cornelia Huck <cohuck@redhat.com> Reviewed-by: Raphael Norwitz <raphael.norwitz@nutanix.com> Message-Id: <20200818143348.310613-8-stefanha@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
* virtio-blk-pci: default num_queues to -smp NStefan Hajnoczi2020-08-271-0/+1
| | | | | | | | | | | | | | | | | | | | | | Automatically size the number of virtio-blk-pci request virtqueues to match the number of vCPUs. Other transports continue to default to 1 request virtqueue. A 1:1 virtqueue:vCPU mapping ensures that completion interrupts are handled on the same vCPU that submitted the request. No IPI is necessary to complete an I/O request and performance is improved. The maximum number of MSI-X vectors and virtqueues limit are respected. Performance improves from 78k to 104k IOPS on a 32 vCPU guest with 101 virtio-blk-pci devices (ioengine=libaio, iodepth=1, bs=4k, rw=randread with NVMe storage). Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com> Reviewed-by: Cornelia Huck <cohuck@redhat.com> Reviewed-by: Pankaj Gupta <pankaj.gupta.linux@gmail.com> Message-Id: <20200818143348.310613-7-stefanha@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
* virtio-scsi-pci: default num_queues to -smp NStefan Hajnoczi2020-08-271-1/+5
| | | | | | | | | | | | | | | | | | Automatically size the number of virtio-scsi-pci, vhost-scsi-pci, and vhost-user-scsi-pci request virtqueues to match the number of vCPUs. Other transports continue to default to 1 request virtqueue. A 1:1 virtqueue:vCPU mapping ensures that completion interrupts are handled on the same vCPU that submitted the request. No IPI is necessary to complete an I/O request and performance is improved. The maximum number of MSI-X vectors and virtqueues limit are respected. Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com> Message-Id: <20200818143348.310613-6-stefanha@redhat.com> Reviewed-by: Cornelia Huck <cohuck@redhat.com> Reviewed-by: Raphael Norwitz <raphael.norwitz@nutanix.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
* hw: add compat machines for 5.2Cornelia Huck2020-08-191-0/+3
| | | | | | | | | | | | | | Add 5.2 machine types for arm/i440fx/q35/s390x/spapr. Reviewed-by: Andrew Jones <drjones@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Reviewed-by: Greg Kurz <groug@kaod.org> Acked-by: Christian Borntraeger <borntraeger@de.ibm.com> Acked-by: David Gibson <david@gibson.dropbear.id.au> Acked-by: Thomas Huth <thuth@redhat.com> Signed-off-by: Cornelia Huck <cohuck@redhat.com> Message-Id: <20200819144016.281156-1-cohuck@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
* hw/pci-host: save/restore pci host config registerHogan Wang2020-07-271-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The pci host config register is used to save PCI address for read/write config data. If guest writes a value to config register, and then QEMU pauses the vcpu to migrate, after the migration, the guest will continue to write pci config data, and the write data will be ignored because of new qemu process losing the config register state. To trigger the bug: 1. guest is booting in seabios. 2. guest enables the SMRAM in seabios:piix4_apmc_smm_setup, and then expects to disable the SMRAM by pci_config_writeb. 3. after guest writes the pci host config register, QEMU pauses vcpu to finish migration. 4. guest write of config data(0x0A) fails to disable the SMRAM because the config register state is lost. 5. guest continues to boot and crashes in ipxe option ROM due to SMRAM in enabled state. Example Reproducer: step 1. Make modifications to seabios and qemu for increase reproduction efficiency, write 0xf0 to 0x402 port notify qemu to stop vcpu after 0x0cf8 port wrote i440 configure register. qemu stop vcpu when catch 0x402 port wrote 0xf0. seabios:/src/hw/pci.c @@ -52,6 +52,11 @@ void pci_config_writeb(u16 bdf, u32 addr, u8 val) writeb(mmconfig_addr(bdf, addr), val); } else { outl(ioconfig_cmd(bdf, addr), PORT_PCI_CMD); + if (bdf == 0 && addr == 0x72 && val == 0xa) { + dprintf(1, "stop vcpu\n"); + outb(0xf0, 0x402); // notify qemu to stop vcpu + dprintf(1, "resume vcpu\n"); + } outb(val, PORT_PCI_DATA + (addr & 3)); } } qemu:hw/char/debugcon.c @@ -60,6 +61,9 @@ static void debugcon_ioport_write(void *opaque, hwaddr addr, uint64_t val, printf(" [debugcon: write addr=0x%04" HWADDR_PRIx " val=0x%02" PRIx64 "]\n", addr, val); #endif + if (ch == 0xf0) { + vm_stop(RUN_STATE_PAUSED); + } /* XXX this blocks entire thread. Rewrite to use * qemu_chr_fe_write and background I/O callbacks */ qemu_chr_fe_write_all(&s->chr, &ch, 1); step 2. start vm1 by the following command line, and then vm stopped. $ qemu-system-x86_64 -machine pc-i440fx-5.0,accel=kvm\ -netdev tap,ifname=tap-test,id=hostnet0,vhost=on,downscript=no,script=no\ -device virtio-net-pci,netdev=hostnet0,id=net0,bus=pci.0,addr=0x13,bootindex=3\ -device cirrus-vga,id=video0,vgamem_mb=16,bus=pci.0,addr=0x2\ -chardev file,id=seabios,path=/var/log/test.seabios,append=on\ -device isa-debugcon,iobase=0x402,chardev=seabios\ -monitor stdio step 3. start vm2 to accept vm1 state. $ qemu-system-x86_64 -machine pc-i440fx-5.0,accel=kvm\ -netdev tap,ifname=tap-test1,id=hostnet0,vhost=on,downscript=no,script=no\ -device virtio-net-pci,netdev=hostnet0,id=net0,bus=pci.0,addr=0x13,bootindex=3\ -device cirrus-vga,id=video0,vgamem_mb=16,bus=pci.0,addr=0x2\ -chardev file,id=seabios,path=/var/log/test.seabios,append=on\ -device isa-debugcon,iobase=0x402,chardev=seabios\ -monitor stdio \ -incoming tcp:127.0.0.1:8000 step 4. execute the following qmp command in vm1 to migrate. (qemu) migrate tcp:127.0.0.1:8000 step 5. execute the following qmp command in vm2 to resume vcpu. (qemu) cont Before this patch, we get KVM "emulation failure" error on vm2. This patch fixes it. Cc: qemu-stable@nongnu.org Signed-off-by: Hogan Wang <hogan.wang@huawei.com> Message-Id: <20200727084621.3279-1-hogan.wang@huawei.com> Reported-by: "Dr. David Alan Gilbert" <dgilbert@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
* qom: Change object_get_canonical_path_component() not to mallocMarkus Armbruster2020-07-211-3/+2
| | | | | | | | | | | | | | | | | | | object_get_canonical_path_component() returns a malloced copy of a property name on success, null on failure. 19 of its 25 callers immediately free the returned copy. Change object_get_canonical_path_component() to return the property name directly. Since modifying the name would be wrong, adjust the return type to const char *. Drop the free from the 19 callers become simpler, add the g_strdup() to the other six. Signed-off-by: Markus Armbruster <armbru@redhat.com> Message-Id: <20200714160202.3121879-4-armbru@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Li Qiang <liq3ea@gmail.com>
* error: Eliminate error_propagate() with Coccinelle, part 1Markus Armbruster2020-07-101-3/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When all we do with an Error we receive into a local variable is propagating to somewhere else, we can just as well receive it there right away. Convert if (!foo(..., &err)) { ... error_propagate(errp, err); ... return ... } to if (!foo(..., errp)) { ... ... return ... } where nothing else needs @err. Coccinelle script: @rule1 forall@ identifier fun, err, errp, lbl; expression list args, args2; binary operator op; constant c1, c2; symbol false; @@ if ( ( - fun(args, &err, args2) + fun(args, errp, args2) | - !fun(args, &err, args2) + !fun(args, errp, args2) | - fun(args, &err, args2) op c1 + fun(args, errp, args2) op c1 ) ) { ... when != err when != lbl: when strict - error_propagate(errp, err); ... when != err ( return; | return c2; | return false; ) } @rule2 forall@ identifier fun, err, errp, lbl; expression list args, args2; expression var; binary operator op; constant c1, c2; symbol false; @@ - var = fun(args, &err, args2); + var = fun(args, errp, args2); ... when != err if ( ( var | !var | var op c1 ) ) { ... when != err when != lbl: when strict - error_propagate(errp, err); ... when != err ( return; | return c2; | return false; | return var; ) } @depends on rule1 || rule2@ identifier err; @@ - Error *err = NULL; ... when != err Not exactly elegant, I'm afraid. The "when != lbl:" is necessary to avoid transforming if (fun(args, &err)) { goto out } ... out: error_propagate(errp, err); even though other paths to label out still need the error_propagate(). For an actual example, see sclp_realize(). Without the "when strict", Coccinelle transforms vfio_msix_setup(), incorrectly. I don't know what exactly "when strict" does, only that it helps here. The match of return is narrower than what I want, but I can't figure out how to express "return where the operand doesn't use @err". For an example where it's too narrow, see vfio_intx_enable(). Silently fails to convert hw/arm/armsse.c, because Coccinelle gets confused by ARMSSE being used both as typedef and function-like macro there. Converted manually. Line breaks tidied up manually. One nested declaration of @local_err deleted manually. Preexisting unwanted blank line dropped in hw/riscv/sifive_e.c. Signed-off-by: Markus Armbruster <armbru@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Message-Id: <20200707160613.848843-35-armbru@redhat.com>
* qapi: Use returned bool to check for failure, Coccinelle partMarkus Armbruster2020-07-101-2/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The previous commit enables conversion of visit_foo(..., &err); if (err) { ... } to if (!visit_foo(..., errp)) { ... } for visitor functions that now return true / false on success / error. Coccinelle script: @@ identifier fun =~ "check_list|input_type_enum|lv_start_struct|lv_type_bool|lv_type_int64|lv_type_str|lv_type_uint64|output_type_enum|parse_type_bool|parse_type_int64|parse_type_null|parse_type_number|parse_type_size|parse_type_str|parse_type_uint64|print_type_bool|print_type_int64|print_type_null|print_type_number|print_type_size|print_type_str|print_type_uint64|qapi_clone_start_alternate|qapi_clone_start_list|qapi_clone_start_struct|qapi_clone_type_bool|qapi_clone_type_int64|qapi_clone_type_null|qapi_clone_type_number|qapi_clone_type_str|qapi_clone_type_uint64|qapi_dealloc_start_list|qapi_dealloc_start_struct|qapi_dealloc_type_anything|qapi_dealloc_type_bool|qapi_dealloc_type_int64|qapi_dealloc_type_null|qapi_dealloc_type_number|qapi_dealloc_type_str|qapi_dealloc_type_uint64|qobject_input_check_list|qobject_input_check_struct|qobject_input_start_alternate|qobject_input_start_list|qobject_input_start_struct|qobject_input_type_any|qobject_input_type_bool|qobject_input_type_bool_keyval|qobject_input_type_int64|qobject_input_type_int64_keyval|qobject_input_type_null|qobject_input_type_number|qobject_input_type_number_keyval|qobject_input_type_size_keyval|qobject_input_type_str|qobject_input_type_str_keyval|qobject_input_type_uint64|qobject_input_type_uint64_keyval|qobject_output_start_list|qobject_output_start_struct|qobject_output_type_any|qobject_output_type_bool|qobject_output_type_int64|qobject_output_type_null|qobject_output_type_number|qobject_output_type_str|qobject_output_type_uint64|start_list|visit_check_list|visit_check_struct|visit_start_alternate|visit_start_list|visit_start_struct|visit_type_.*"; expression list args; typedef Error; Error *err; @@ - fun(args, &err); - if (err) + if (!fun(args, &err)) { ... } A few line breaks tidied up manually. Signed-off-by: Markus Armbruster <armbru@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Reviewed-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com> Message-Id: <20200707160613.848843-19-armbru@redhat.com>
* vmport: move compat properties to hw_compat_5_0Paolo Bonzini2020-06-261-4/+4
| | | | | | | | | | | | | | | | The patches that introduced the properties were submitted when QEMU 5.0 had not been released yet, so they got merged under the wrong heading. Move them to hw_compat_5_0 so that 5.0 machine types get the pre-patch behavior. Fixes: b889212973da ("hw/i386/vmport: Propagate IOPort read to vCPU EAX register") Fixes: 0342ee761ef2 ("hw/i386/vmport: Set EAX to -1 on failed and unsupported commands") Fixes: f8bdc550370f ("hw/i386/vmport: Report vmware-vmx-type in CMD_GETVERSION") Fixes: aaacf1c15a22 ("hw/i386/vmport: Add support for CMD_GETBIOSUUID") Reported-by: Laurent Vivier <lvivier@redhat.com> Cc: Liran Alon <liran.alon@oracle.com> Reviewed-by: Laurent Vivier <lvivier@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
* Merge remote-tracking branch 'remotes/bonzini/tags/for-upstream' into stagingPeter Maydell2020-06-121-0/+4
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | * Miscellaneous fixes and feature enablement (many) * SEV refactoring (David) * Hyper-V initial support (Jon) * i386 TCG fixes (x87 and SSE, Joseph) * vmport cleanup and improvements (Philippe, Liran) * Use-after-free with vCPU hot-unplug (Nengyuan) * run-coverity-scan improvements (myself) * Record/replay fixes (Pavel) * -machine kernel_irqchip=split improvements for INTx (Peter) * Code cleanups (Philippe) * Crash and security fixes (PJP) * HVF cleanups (Roman) # gpg: Signature made Fri 12 Jun 2020 16:57:04 BST # gpg: using RSA key F13338574B662389866C7682BFFBD25F78C7AE83 # gpg: issuer "pbonzini@redhat.com" # gpg: Good signature from "Paolo Bonzini <bonzini@gnu.org>" [full] # gpg: aka "Paolo Bonzini <pbonzini@redhat.com>" [full] # Primary key fingerprint: 46F5 9FBD 57D6 12E7 BFD4 E2F7 7E15 100C CD36 69B1 # Subkey fingerprint: F133 3857 4B66 2389 866C 7682 BFFB D25F 78C7 AE83 * remotes/bonzini/tags/for-upstream: (116 commits) target/i386: Remove obsolete TODO file stubs: move Xen stubs to accel/ replay: fix replay shutdown for console mode exec/cpu-common: Move MUSB specific typedefs to 'hw/usb/hcd-musb.h' hw/usb: Move device-specific declarations to new 'hcd-musb.h' header exec/memory: Remove unused MemoryRegionMmio type checkpatch: reversed logic with acpi test checks target/i386: sev: Unify SEVState and SevGuestState target/i386: sev: Remove redundant handle field target/i386: sev: Remove redundant policy field target/i386: sev: Remove redundant cbitpos and reduced_phys_bits fields target/i386: sev: Partial cleanup to sev_state global target/i386: sev: Embed SEVState in SevGuestState target/i386: sev: Rename QSevGuestInfo target/i386: sev: Move local structure definitions into .c file target/i386: sev: Remove unused QSevGuestInfoClass xen: fix build without pci passthrough i386: hvf: Drop HVFX86EmulatorState i386: hvf: Move mmio_buf into CPUX86State i386: hvf: Move lazy_flags into CPUX86State ... Signed-off-by: Peter Maydell <peter.maydell@linaro.org> # Conflicts: # hw/i386/acpi-build.c
| * hw/i386/vmport: Add support for CMD_GETBIOSUUIDLiran Alon2020-06-101-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is VMware documented functionallity that some guests rely on. Returns the BIOS UUID of the current virtual machine. Note that we also introduce a new compatability flag "x-cmds-v2" to make sure to expose new VMPort commands only to new machine-types. This flag will also be used by the following patches that will introduce additional VMPort commands. Reviewed-by: Nikita Leshenko <nikita.leshchenko@oracle.com> Signed-off-by: Liran Alon <liran.alon@oracle.com> Message-Id: <20200312165431.82118-10-liran.alon@oracle.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
| * hw/i386/vmport: Report vmware-vmx-type in CMD_GETVERSIONLiran Alon2020-06-101-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | As can be seen from VmCheck_GetVersion() in open-vm-tools code, CMD_GETVERSION should return vmware-vmx-type in ECX register. Default is to fake host as VMware ESX server. But user can control this value by "-global vmport.vmware-vmx-type=X". Reviewed-by: Nikita Leshenko <nikita.leshchenko@oracle.com> Signed-off-by: Liran Alon <liran.alon@oracle.com> Message-Id: <20200312165431.82118-7-liran.alon@oracle.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
| * hw/i386/vmport: Set EAX to -1 on failed and unsupported commandsLiran Alon2020-06-101-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is used as a signal for VMware Tools to know if a command it attempted to invoke, failed or is unsupported. As a result, VMware Tools will either report failure to user or fallback to another backdoor command in attempt to perform some operation. A few examples: * open-vm-tools TimeSyncReadHost() function fallbacks to CMD_GETTIMEFULL command when CMD_GETTIMEFULL_WITH_LAG fails/unsupported. * open-vm-tools Hostinfo_NestingSupported() function verifies EAX != -1 to check for success. * open-vm-tools Hostinfo_VCPUInfoBackdoor() functions checks if reserved-bit is set to indicate command is unimplemented. Reviewed-by: Nikita Leshenko <nikita.leshchenko@oracle.com> Signed-off-by: Liran Alon <liran.alon@oracle.com> Message-Id: <20200312165431.82118-5-liran.alon@oracle.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
| * hw/i386/vmport: Propagate IOPort read to vCPU EAX registerLiran Alon2020-06-101-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | vmport_ioport_read() returns the value that should propagate to vCPU EAX register when guest reads VMPort IOPort (i.e. By x86 IN instruction). However, because vmport_ioport_read() calls cpu_synchronize_state(), the returned value gets overridden by the value in QEMU vCPU EAX register. i.e. cpu->env.regs[R_EAX]. To fix this issue, change vmport_ioport_read() to explicitly override cpu->env.regs[R_EAX] with the value it wish to propagate to vCPU EAX register. Reviewed-by: Nikita Leshenko <nikita.leshchenko@oracle.com> Signed-off-by: Liran Alon <liran.alon@oracle.com> Message-Id: <20200312165431.82118-4-liran.alon@oracle.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
* | virtio-balloon: Implement support for page poison reporting featureAlexander Duyck2020-06-091-1/+3
|/ | | | | | | | | | | | | | | | | | | | | | We need to make certain to advertise support for page poison reporting if we want to actually get data on if the guest will be poisoning pages. Add a value for reporting the poison value being used if page poisoning is enabled in the guest. With this we can determine if we will need to skip free page reporting when it is enabled in the future. The value currently has no impact on existing balloon interfaces. In the case of existing balloon interfaces the onus is on the guest driver to reapply whatever poison is in place. When we add free page reporting the poison value is used to determine if we can perform in-place page reporting. The expectation is that a reported page will already contain the value specified by the poison, and the reporting of the page should not change that value. Acked-by: David Hildenbrand <david@redhat.com> Signed-off-by: Alexander Duyck <alexander.h.duyck@linux.intel.com> Message-Id: <20200527041400.12700.33251.stgit@localhost.localdomain>
* qom: Drop parameter @errp of object_property_add() & friendsMarkus Armbruster2020-05-151-27/+19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The only way object_property_add() can fail is when a property with the same name already exists. Since our property names are all hardcoded, failure is a programming error, and the appropriate way to handle it is passing &error_abort. Same for its variants, except for object_property_add_child(), which additionally fails when the child already has a parent. Parentage is also under program control, so this is a programming error, too. We have a bit over 500 callers. Almost half of them pass &error_abort, slightly fewer ignore errors, one test case handles errors, and the remaining few callers pass them to their own callers. The previous few commits demonstrated once again that ignoring programming errors is a bad idea. Of the few ones that pass on errors, several violate the Error API. The Error ** argument must be NULL, &error_abort, &error_fatal, or a pointer to a variable containing NULL. Passing an argument of the latter kind twice without clearing it in between is wrong: if the first call sets an error, it no longer points to NULL for the second call. ich9_pm_add_properties(), sparc32_ledma_realize(), sparc32_dma_realize(), xilinx_axidma_realize(), xilinx_enet_realize() are wrong that way. When the one appropriate choice of argument is &error_abort, letting users pick the argument is a bad idea. Drop parameter @errp and assert the preconditions instead. There's one exception to "duplicate property name is a programming error": the way object_property_add() implements the magic (and undocumented) "automatic arrayification". Don't drop @errp there. Instead, rename object_property_add() to object_property_try_add(), and add the obvious wrapper object_property_add(). Signed-off-by: Markus Armbruster <armbru@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Reviewed-by: Paolo Bonzini <pbonzini@redhat.com> Message-Id: <20200505152926.18877-15-armbru@redhat.com> [Two semantic rebase conflicts resolved]
* qom: Drop object_property_set_description() parameter @errpMarkus Armbruster2020-05-151-22/+19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | object_property_set_description() and object_class_property_set_description() fail only when property @name is not found. There are 85 calls of object_property_set_description() and object_class_property_set_description(). None of them can fail: * 84 immediately follow the creation of the property. * The one in spapr_rng_instance_init() refers to a property created in spapr_rng_class_init(), from spapr_rng_properties[]. Every one of them still gets to decide what to pass for @errp. 51 calls pass &error_abort, 32 calls pass NULL, one receives the error and propagates it to &error_abort, and one propagates it to &error_fatal. I'm actually surprised none of them violates the Error API. What are we gaining by letting callers handle the "property not found" error? Use when the property is not known to exist is simpler: you don't have to guard the call with a check. We haven't found such a use in 5+ years. Until we do, let's make life a bit simpler and drop the @errp parameter. Signed-off-by: Markus Armbruster <armbru@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Reviewed-by: Paolo Bonzini <pbonzini@redhat.com> Message-Id: <20200505152926.18877-8-armbru@redhat.com> [One semantic rebase conflict resolved]
* hw: add compat machines for 5.1Cornelia Huck2020-05-061-0/+3
| | | | | | | | | Add 5.1 machine types for arm/i440fx/q35/s390x/spapr. Acked-by: David Gibson <david@gibson.dropbear.id.au> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Cornelia Huck <cohuck@redhat.com> Message-id: 20200429144605.7262-1-cohuck@redhat.com
* fw_cfg: Migrate ACPI table mr sizes separatelyShameer Kolothum2020-04-131-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | Any sub-page size update to ACPI MRs will be lost during migration, as we use aligned size in ram_load_precopy() -> qemu_ram_resize() path. This will result in inconsistency in FWCfgEntry sizes between source and destination. In order to avoid this, save and restore them separately during migration. Up until now, this problem may not be that relevant for x86 as both ACPI table and Linker MRs gets padded and aligned. Also at present, qemu_ram_resize() doesn't invoke callback to update FWCfgEntry for unaligned size changes. But since we are going to fix the qemu_ram_resize() in the subsequent patch, the issue may become more serious especially for RSDP MR case. Moreover, the issue will soon become prominent in arm/virt as well where the MRs are not padded or aligned at all and eventually have acpi table changes as part of future additions like NVDIMM hot-add feature. Suggested-by: David Hildenbrand <david@redhat.com> Signed-off-by: Shameer Kolothum <shameerali.kolothum.thodi@huawei.com> Acked-by: David Hildenbrand <david@redhat.com> Message-Id: <20200403101827.30664-3-shameerali.kolothum.thodi@huawei.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
* compat: disable edid on correct virtio-gpu deviceCornelia Huck2020-03-201-1/+1
| | | | | | | | | | | | | | | | | Commit bb15791166c1 ("compat: disable edid on virtio-gpu base device") tried to disable 'edid' on the virtio-gpu base device. However, that device is not 'virtio-gpu', but 'virtio-gpu-device'. Fix it. Fixes: bb15791166c1 ("compat: disable edid on virtio-gpu base device") Reported-by: Lukáš Doktor <ldoktor@redhat.com> Tested-by: Lukáš Doktor <ldoktor@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Signed-off-by: Cornelia Huck <cohuck@redhat.com> Message-id: 20200318093919.24942-1-cohuck@redhat.com Cc: qemu-stable@nongnu.org Signed-off-by: Cornelia Huck <cohuck@redhat.com> Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
* machine: Add SMP Sockets in CpuTopologyBabu Moger2020-03-171-0/+1
| | | | | | | | | | | | Store the smp sockets in CpuTopology. The socket information required to build the apic id in EPYC mode. Right now socket information is not passed to down when decoding the apic id. Add the socket information here. Signed-off-by: Babu Moger <babu.moger@amd.com> Reviewed-by: Eduardo Habkost <ehabkost@redhat.com> Reviewed-by: Igor Mammedov <imammedo@redhat.com> Acked-by: Michael S. Tsirkin <mst@redhat.com> Message-Id: <158396718647.58170.2278448323151215741.stgit@naples-babu.amd.com>
* machine/memory encryption: Disable mem mergeDr. David Alan Gilbert2020-03-171-0/+8
| | | | | | | | | | | | | | | When a host is running with memory encryption, the memory isn't visible to the host kernel; attempts to merge that memory are futile because what it's really comparing is encrypted memory, usually encrypted with different keys. Automatically turn mem-merge off when memory encryption is specified. https://bugzilla.redhat.com/show_bug.cgi?id=1796356 Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com> Message-Id: <20200130175046.85850-1-dgilbert@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
* Merge tag 'patchew/20200219160953.13771-1-imammedo@redhat.com' of ↵Paolo Bonzini2020-02-251-0/+48
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | https://github.com/patchew-project/qemu into HEAD This series removes ad hoc RAM allocation API (memory_region_allocate_system_memory) and consolidates it around hostmem backend. It allows to * resolve conflicts between global -mem-prealloc and hostmem's "policy" option, fixing premature allocation before binding policy is applied * simplify complicated memory allocation routines which had to deal with 2 ways to allocate RAM. * reuse hostmem backends of a choice for main RAM without adding extra CLI options to duplicate hostmem features. A recent case was -mem-shared, to enable vhost-user on targets that don't support hostmem backends [1] (ex: s390) * move RAM allocation from individual boards into generic machine code and provide them with prepared MemoryRegion. * clean up deprecated NUMA features which were tied to the old API (see patches) - "numa: remove deprecated -mem-path fallback to anonymous RAM" - (POSTPONED, waiting on libvirt side) "forbid '-numa node,mem' for 5.0 and newer machine types" - (POSTPONED) "numa: remove deprecated implicit RAM distribution between nodes" Introduce a new machine.memory-backend property and wrapper code that aliases global -mem-path and -mem-alloc into automatically created hostmem backend properties (provided memory-backend was not set explicitly given by user). A bulk of trivial patches then follow to incrementally convert individual boards to using machine.memory-backend provided MemoryRegion. Board conversion typically involves: * providing MachineClass::default_ram_size and MachineClass::default_ram_id so generic code could create default backend if user didn't explicitly provide memory-backend or -m options * dropping memory_region_allocate_system_memory() call * using convenience MachineState::ram MemoryRegion, which points to MemoryRegion allocated by ram-memdev On top of that for some boards: * missing ram_size checks are added (typically it were boards with fixed ram size) * ram_size fixups are replaced by checks and hard errors, forcing user to provide correct "-m" values instead of ignoring it and continuing running. After all boards are converted, the old API is removed and memory allocation routines are cleaned up.
| * machine: introduce convenience MachineState::ramIgor Mammedov2020-02-191-0/+24
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | the new field will be used by boards to get access to main RAM memory region and will help to save boiler plate in boards which often introduce a field or variable just for this purpose. Memory region will be equivalent to what currently used memory_region_allocate_system_memory() is returning apart from that it will come from hostmem backend. Followup patches will incrementally switch boards to using RAM from MachineState::ram. Patch takes care of non-NUMA case and follow up patch will initialize MachineState::ram for NUMA case. Signed-off-by: Igor Mammedov <imammedo@redhat.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-Id: <20200219160953.13771-5-imammedo@redhat.com>
| * machine: introduce memory-backend propertyIgor Mammedov2020-02-191-0/+24
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Property will contain link to memory backend that will be used for backing initial RAM. Follow up commit will alias -mem-path and -mem-prealloc CLI options into memory backend options to make memory handling consistent (using only hostmem backend family for guest RAM allocation). Signed-off-by: Igor Mammedov <imammedo@redhat.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Message-Id: <20200219160953.13771-3-imammedo@redhat.com>
* | virtio: increase virtqueue size for virtio-scsi and virtio-blkDenis Plotnikov2020-02-221-0/+2
|/ | | | | | | | | | | | | | | | | | | | | | The goal is to reduce the amount of requests issued by a guest on 1M reads/writes. This rises the performance up to 4% on that kind of disk access pattern. The maximum chunk size to be used for the guest disk accessing is limited with seg_max parameter, which represents the max amount of pices in the scatter-geather list in one guest disk request. Since seg_max is virqueue_size dependent, increasing the virtqueue size increases seg_max, which, in turn, increases the maximum size of data to be read/write from a guest disk. More details in the original problem statment: https://lists.gnu.org/archive/html/qemu-devel/2017-12/msg03721.html Suggested-by: Denis V. Lunev <den@openvz.org> Signed-off-by: Denis Plotnikov <dplotnikov@virtuozzo.com> Message-id: 20200214074648.958-1-dplotnikov@virtuozzo.com Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
* qxl: introduce hardware revision 5Gerd Hoffmann2020-02-131-0/+2
| | | | | | | | | | | | | | The only difference to hardware revision 4 is that the device doesn't switch to VGA mode in case someone happens to touch a VGA register, which should make things more robust in configurations with multiple vga devices. Swtiching back to VGA mode happens on reset, either full machine reset or qxl device reset (QXL_IO_RESET ioport command). Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Maxim Levitsky <mlevitsk@redhat.com> Message-id: 20200206074358.4274-1-kraxel@redhat.com
* hw/core: Allow setting 'virtio-blk-device.scsi' property on OSX hostPhilippe Mathieu-Daudé2020-02-071-1/+2
| | | | | | | | | | | | | | | | | | | | | | Commit ed65fd1a2750 ("virtio-blk: switch off scsi-passthrough by default") changed the default value of the 'scsi' property of virtio-blk, which is only available on Linux hosts. It also added an unconditional compat entry for 2.4 or earlier machines. Trying to set this property on a pre-2.5 machine on OSX, we get: Unexpected error in object_property_find() at qom/object.c:1201: qemu-system-x86_64: -device virtio-blk-pci,id=scsi0,drive=drive0: can't apply global virtio-blk-device.scsi=true: Property '.scsi' not found Fix this error by marking the property optional. Fixes: ed65fd1a27 ("virtio-blk: switch off scsi-passthrough by default") Suggested-by: Cornelia Huck <cohuck@redhat.com> Reviewed-by: Cornelia Huck <cohuck@redhat.com> Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Message-id: 20200207001404.1739-1-philmd@redhat.com Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
* usb-redir: remove 'remote wakeup' flag from configuration descriptorYuri Benditovich2020-01-131-0/+1
| | | | | | | | | | | | | | | | If the redirected device has this capability, Windows guest may place the device into D2 and expect it to wake when the device becomes active, but this will never happen. For example, when internal Bluetooth adapter is redirected, keyboards and mice connected to it do not work. Current commit removes this capability (starting from machine 5.0) Set 'usb-redir.suppress-remote-wake' property to 'off' to keep 'remote wake' as is or to 'on' to remove 'remote wake' on 4.2 or earlier. Signed-off-by: Yuri Benditovich <yuri.benditovich@daynix.com> Message-id: 20200108091044.18055-3-yuri.benditovich@daynix.com Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
* usb-host: remove 'remote wakeup' flag from configuration descriptorYuri Benditovich2020-01-131-0/+1
| | | | | | | | | | | | | | | | If the redirected device has this capability, Windows guest may place the device into D2 and expect it to wake when the device becomes active, but this will never happen. For example, when internal Bluetooth adapter is redirected, keyboards and mice connected to it do not work. Current commit removes this capability (starting from machine 5.0) Set 'usb-host.suppress-remote-wake' property to 'off' to keep 'remote wake' as is or to 'on' to remove 'remote wake' on 4.2 or earlier. Signed-off-by: Yuri Benditovich <yuri.benditovich@daynix.com> Message-id: 20200108091044.18055-2-yuri.benditovich@daynix.com Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
* Merge remote-tracking branch 'remotes/mst/tags/for_upstream' into stagingPeter Maydell2020-01-071-0/+68
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | virtio, pci, pc: fixes, features Bugfixes all over the place. HMAT support. New flags for vhost-user-blk utility. Auto-tuning of seg max for virtio storage. Signed-off-by: Michael S. Tsirkin <mst@redhat.com> # gpg: Signature made Mon 06 Jan 2020 17:05:05 GMT # gpg: using RSA key 5D09FD0871C8F85B94CA8A0D281F0DB8D28D5469 # gpg: issuer "mst@redhat.com" # gpg: Good signature from "Michael S. Tsirkin <mst@kernel.org>" [full] # gpg: aka "Michael S. Tsirkin <mst@redhat.com>" [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: (32 commits) intel_iommu: add present bit check for pasid table entries intel_iommu: a fix to vtd_find_as_from_bus_num() virtio-net: delete also control queue when TX/RX deleted virtio: reset region cache when on queue deletion virtio-mmio: update queue size on guest write tests: add virtio-scsi and virtio-blk seg_max_adjust test virtio: make seg_max virtqueue size dependent hw: fix using 4.2 compat in 5.0 machine types for i440fx/q35 vhost-user-scsi: reset the device if supported vhost-user: add VHOST_USER_RESET_DEVICE to reset devices hw/pci/pci_host: Let pci_data_[read/write] use unsigned 'size' argument hw/pci/pci_host: Remove redundant PCI_DPRINTF() virtio-mmio: Clear v2 transport state on soft reset ACPI: add expected files for HMAT tests (acpihmat) tests/bios-tables-test: add test cases for ACPI HMAT tests/numa: Add case for QMP build HMAT hmat acpi: Build Memory Side Cache Information Structure(s) hmat acpi: Build System Locality Latency and Bandwidth Information Structure(s) hmat acpi: Build Memory Proximity Domain Attributes Structure(s) numa: Extend CLI to provide memory side cache information ... Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
| * virtio: make seg_max virtqueue size dependentDenis Plotnikov2020-01-061-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Before the patch, seg_max parameter was immutable and hardcoded to 126 (128 - 2) without respect to queue size. This has two negative effects: 1. when queue size is < 128, we have Virtio 1.1 specfication violation: (2.6.5.3.1 Driver Requirements) seq_max must be <= queue_size. This violation affects the old Linux guests (ver < 4.14). These guests crash on these queue_size setups. 2. when queue_size > 128, as was pointed out by Denis Lunev <den@virtuozzo.com>, seg_max restrics guest's block request length which affects guests' performance making them issues more block request than needed. https://lists.gnu.org/archive/html/qemu-devel/2017-12/msg03721.html To mitigate this two effects, the patch adds the property adjusting seg_max to queue size automaticaly. Since seg_max is a guest visible parameter, the property is machine type managable and allows to choose between old (seg_max = 126 always) and new (seg_max = queue_size - 2) behaviors. Not to change the behavior of the older VMs, prevent setting the default seg_max_adjust value for older machine types. Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> Signed-off-by: Denis Plotnikov <dplotnikov@virtuozzo.com> Message-Id: <20191220140905.1718-2-dplotnikov@virtuozzo.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
| * numa: Extend CLI to provide initiator information for numa nodesTao Xu2020-01-051-0/+64
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In ACPI 6.3 chapter 5.2.27 Heterogeneous Memory Attribute Table (HMAT), The initiator represents processor which access to memory. And in 5.2.27.3 Memory Proximity Domain Attributes Structure, the attached initiator is defined as where the memory controller responsible for a memory proximity domain. With attached initiator information, the topology of heterogeneous memory can be described. Add new machine property 'hmat' to enable all HMAT specific options. Extend CLI of "-numa node" option to indicate the initiator numa node-id. In the linux kernel, the codes in drivers/acpi/hmat/hmat.c parse and report the platform's HMAT tables. Before using initiator option, enable HMAT with -machine hmat=on. Acked-by: Markus Armbruster <armbru@redhat.com> Reviewed-by: Igor Mammedov <imammedo@redhat.com> Reviewed-by: Jingqi Liu <jingqi.liu@intel.com> Suggested-by: Dan Williams <dan.j.williams@intel.com> Signed-off-by: Tao Xu <tao3.xu@intel.com> Message-Id: <20191213011929.2520-2-tao3.xu@intel.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
| * virtio-pci: disable vring processing when bus-mastering is disabledMichael Roth2020-01-051-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Currently the SLOF firmware for pseries guests will disable/re-enable a PCI device multiple times via IO/MEM/MASTER bits of PCI_COMMAND register after the initial probe/feature negotiation, as it tends to work with a single device at a time at various stages like probing and running block/network bootloaders without doing a full reset in-between. In QEMU, when PCI_COMMAND_MASTER is disabled we disable the corresponding IOMMU memory region, so DMA accesses (including to vring fields like idx/flags) will no longer undergo the necessary translation. Normally we wouldn't expect this to happen since it would be misbehavior on the driver side to continue driving DMA requests. However, in the case of pseries, with iommu_platform=on, we trigger the following sequence when tearing down the virtio-blk dataplane ioeventfd in response to the guest unsetting PCI_COMMAND_MASTER: #2 0x0000555555922651 in virtqueue_map_desc (vdev=vdev@entry=0x555556dbcfb0, p_num_sg=p_num_sg@entry=0x7fffe657e1a8, addr=addr@entry=0x7fffe657e240, iov=iov@entry=0x7fffe6580240, max_num_sg=max_num_sg@entry=1024, is_write=is_write@entry=false, pa=0, sz=0) at /home/mdroth/w/qemu.git/hw/virtio/virtio.c:757 #3 0x0000555555922a89 in virtqueue_pop (vq=vq@entry=0x555556dc8660, sz=sz@entry=184) at /home/mdroth/w/qemu.git/hw/virtio/virtio.c:950 #4 0x00005555558d3eca in virtio_blk_get_request (vq=0x555556dc8660, s=0x555556dbcfb0) at /home/mdroth/w/qemu.git/hw/block/virtio-blk.c:255 #5 0x00005555558d3eca in virtio_blk_handle_vq (s=0x555556dbcfb0, vq=0x555556dc8660) at /home/mdroth/w/qemu.git/hw/block/virtio-blk.c:776 #6 0x000055555591dd66 in virtio_queue_notify_aio_vq (vq=vq@entry=0x555556dc8660) at /home/mdroth/w/qemu.git/hw/virtio/virtio.c:1550 #7 0x000055555591ecef in virtio_queue_notify_aio_vq (vq=0x555556dc8660) at /home/mdroth/w/qemu.git/hw/virtio/virtio.c:1546 #8 0x000055555591ecef in virtio_queue_host_notifier_aio_poll (opaque=0x555556dc86c8) at /home/mdroth/w/qemu.git/hw/virtio/virtio.c:2527 #9 0x0000555555d02164 in run_poll_handlers_once (ctx=ctx@entry=0x55555688bfc0, timeout=timeout@entry=0x7fffe65844a8) at /home/mdroth/w/qemu.git/util/aio-posix.c:520 #10 0x0000555555d02d1b in try_poll_mode (timeout=0x7fffe65844a8, ctx=0x55555688bfc0) at /home/mdroth/w/qemu.git/util/aio-posix.c:607 #11 0x0000555555d02d1b in aio_poll (ctx=ctx@entry=0x55555688bfc0, blocking=blocking@entry=true) at /home/mdroth/w/qemu.git/util/aio-posix.c:639 #12 0x0000555555d0004d in aio_wait_bh_oneshot (ctx=0x55555688bfc0, cb=cb@entry=0x5555558d5130 <virtio_blk_data_plane_stop_bh>, opaque=opaque@entry=0x555556de86f0) at /home/mdroth/w/qemu.git/util/aio-wait.c:71 #13 0x00005555558d59bf in virtio_blk_data_plane_stop (vdev=<optimized out>) at /home/mdroth/w/qemu.git/hw/block/dataplane/virtio-blk.c:288 #14 0x0000555555b906a1 in virtio_bus_stop_ioeventfd (bus=bus@entry=0x555556dbcf38) at /home/mdroth/w/qemu.git/hw/virtio/virtio-bus.c:245 #15 0x0000555555b90dbb in virtio_bus_stop_ioeventfd (bus=bus@entry=0x555556dbcf38) at /home/mdroth/w/qemu.git/hw/virtio/virtio-bus.c:237 #16 0x0000555555b92a8e in virtio_pci_stop_ioeventfd (proxy=0x555556db4e40) at /home/mdroth/w/qemu.git/hw/virtio/virtio-pci.c:292 #17 0x0000555555b92a8e in virtio_write_config (pci_dev=0x555556db4e40, address=<optimized out>, val=1048832, len=<optimized out>) at /home/mdroth/w/qemu.git/hw/virtio/virtio-pci.c:613 I.e. the calling code is only scheduling a one-shot BH for virtio_blk_data_plane_stop_bh, but somehow we end up trying to process an additional virtqueue entry before we get there. This is likely due to the following check in virtio_queue_host_notifier_aio_poll: static bool virtio_queue_host_notifier_aio_poll(void *opaque) { EventNotifier *n = opaque; VirtQueue *vq = container_of(n, VirtQueue, host_notifier); bool progress; if (!vq->vring.desc || virtio_queue_empty(vq)) { return false; } progress = virtio_queue_notify_aio_vq(vq); namely the call to virtio_queue_empty(). In this case, since no new requests have actually been issued, shadow_avail_idx == last_avail_idx, so we actually try to access the vring via vring_avail_idx() to get the latest non-shadowed idx: int virtio_queue_empty(VirtQueue *vq) { bool empty; ... if (vq->shadow_avail_idx != vq->last_avail_idx) { return 0; } rcu_read_lock(); empty = vring_avail_idx(vq) == vq->last_avail_idx; rcu_read_unlock(); return empty; but since the IOMMU region has been disabled we get a bogus value (0 usually), which causes virtio_queue_empty() to falsely report that there are entries to be processed, which causes errors such as: "virtio: zero sized buffers are not allowed" or "virtio-blk missing headers" and puts the device in an error state. This patch works around the issue by introducing virtio_set_disabled(), which sets a 'disabled' flag to bypass checks like virtio_queue_empty() when bus-mastering is disabled. Since we'd check this flag at all the same sites as vdev->broken, we replace those checks with an inline function which checks for either vdev->broken or vdev->disabled. The 'disabled' flag is only migrated when set, which should be fairly rare, but to maintain migration compatibility we disable it's use for older machine types. Users requiring the use of the flag in conjunction with older machine types can set it explicitly as a virtio-device option. NOTES: - This leaves some other oddities in play, like the fact that DRIVER_OK also gets unset in response to bus-mastering being disabled, but not restored (however the device seems to continue working) - Similarly, we disable the host notifier via virtio_bus_stop_ioeventfd(), which seems to move the handling out of virtio-blk dataplane and back into the main IO thread, and it ends up staying there till a reset (but otherwise continues working normally) Cc: David Gibson <david@gibson.dropbear.id.au>, Cc: Alexey Kardashevskiy <aik@ozlabs.ru> Cc: "Michael S. Tsirkin" <mst@redhat.com> Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com> Message-Id: <20191120005003.27035-1-mdroth@linux.vnet.ibm.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
* | Merge remote-tracking branch ↵Peter Maydell2020-01-061-2/+2
|\ \ | |/ |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 'remotes/ehabkost/tags/x86-and-machine-pull-request' into staging x86 and machine queue, 2019-12-20 Bug fix: * Resolve CPU models to v1 by default (Eduardo Habkost) Cleanup: * Remove incorrect numa_mem_supported checks (Igor Mammedov) # gpg: Signature made Fri 20 Dec 2019 19:19:02 GMT # gpg: using RSA key 5A322FD5ABC4D3DBACCFD1AA2807936F984DC5A6 # gpg: issuer "ehabkost@redhat.com" # gpg: Good signature from "Eduardo Habkost <ehabkost@redhat.com>" [full] # Primary key fingerprint: 5A32 2FD5 ABC4 D3DB ACCF D1AA 2807 936F 984D C5A6 * remotes/ehabkost/tags/x86-and-machine-pull-request: numa: properly check if numa is supported numa: remove not needed check i386: Resolve CPU models to v1 by default Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
| * numa: properly check if numa is supportedIgor Mammedov2019-12-191-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Commit aa57020774b, by mistake used MachineClass::numa_mem_supported to check if NUMA is supported by machine and also as unrelated change set it to true for sbsa-ref board. Luckily change didn't break machines that support NUMA, as the field is set to true for them. But the field is not intended for checking if NUMA is supported and will be flipped to false within this release for new machine types. Fix it: - by using previously used condition !mc->cpu_index_to_instance_props || !mc->get_default_cpu_node_id the first time and then use MachineState::numa_state down the road to check if NUMA is supported - dropping stray sbsa-ref chunk Fixes: aa57020774b690a22be72453b8e91c9b5a68c516 Signed-off-by: Igor Mammedov <imammedo@redhat.com> Message-Id: <1576154936-178362-3-git-send-email-imammedo@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
* | kvm: convert "-machine kernel_irqchip" to an accelerator propertyPaolo Bonzini2019-12-171-61/+0
| | | | | | | | Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
* | kvm: convert "-machine kvm_shadow_mem" to an accelerator propertyPaolo Bonzini2019-12-171-39/+0
| | | | | | | | Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>