aboutsummaryrefslogtreecommitdiff
path: root/hw
AgeCommit message (Collapse)Author
2017-05-17ioapic: Remove user_creatable flagEduardo Habkost
An ioapic device is already created by the q35 initialization code, and using "-device ioapic" or "-device kvm-ioapic" will always fail with "Only 1 ioapics allowed". Remove the user_creatable flag from the ioapic device classes. Cc: Igor Mammedov <imammedo@redhat.com> Cc: Marcel Apfelbaum <marcel@redhat.com> Cc: "Michael S. Tsirkin" <mst@redhat.com> Cc: Paolo Bonzini <pbonzini@redhat.com> Cc: Richard Henderson <rth@twiddle.net> Cc: Eduardo Habkost <ehabkost@redhat.com> Acked-by: Marcel Apfelbaum <marcel@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com> Message-Id: <20170503203604.31462-9-ehabkost@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2017-05-17kvmclock: Remove user_creatable flagEduardo Habkost
kvmclock should be used by guests only when the appropriate CPUID feature flags are set on the VCPU, and it is automatically created by kvmclock_create() when those feature flags are set. This means creating a kvmclock device using -device is useless. Remove user_creatable from its device class. Cc: Marcel Apfelbaum <marcel@redhat.com> Cc: "Michael S. Tsirkin" <mst@redhat.com> Cc: Paolo Bonzini <pbonzini@redhat.com> Cc: Richard Henderson <rth@twiddle.net> Cc: Thomas Huth <thuth@redhat.com> Acked-by: Marcel Apfelbaum <marcel@redhat.com> Reviewed-by: Thomas Huth <thuth@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com> Message-Id: <20170503203604.31462-8-ehabkost@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2017-05-17pflash_cfi01: Remove user_creatable flagEduardo Habkost
TYPE_CFI_PFLASH01 devices need to be mapped by pflash_cfi01_register() (or equivalent) and can't be used with -device. Remove user_creatable from the device class. Cc: Kevin Wolf <kwolf@redhat.com> Cc: Max Reitz <mreitz@redhat.com> Cc: qemu-block@nongnu.org Cc: Laszlo Ersek <lersek@redhat.com> Cc: Philippe Mathieu-Daudé <f4bug@amsat.org> Cc: Marcel Apfelbaum <marcel@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Acked-by: Marcel Apfelbaum <marcel@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com> Message-Id: <20170503203604.31462-7-ehabkost@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2017-05-17fdc: Remove user_creatable flag from sysbus-fdc & SUNW,fdtwoEduardo Habkost
sysbus-fdc and SUNW,fdtwo devices need IRQs to be wired and mmio to be mapped, and can't be used with -device. Unset user_creatable on their device classes. Cc: John Snow <jsnow@redhat.com> Cc: Kevin Wolf <kwolf@redhat.com> Cc: Marcel Apfelbaum <marcel@redhat.com> Cc: Max Reitz <mreitz@redhat.com> Cc: qemu-block@nongnu.org Cc: Thomas Huth <thuth@redhat.com> Acked-by: John Snow <jsnow@redhat.com> Reviewed-by: Thomas Huth <thuth@redhat.com> Acked-by: Marcel Apfelbaum <marcel@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com> Message-Id: <20170503203604.31462-6-ehabkost@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2017-05-17iommu: Remove FIXME comment about user_creatable=trueEduardo Habkost
amd-iommu and intel-iommu are really meant to be used with -device, so they need user_creatable=true. Remove the FIXME comment. Cc: Marcel Apfelbaum <marcel@redhat.com> Cc: "Michael S. Tsirkin" <mst@redhat.com> Reviewed-by: Marcel Apfelbaum <marcel@redhat.com> Acked-by: Marcel Apfelbaum <marcel@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com> Message-Id: <20170503203604.31462-5-ehabkost@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2017-05-17xen-backend: Remove FIXME comment about user_creatable flagEduardo Habkost
xen-backend can be plugged/unplugged dynamically when using the Xen accelerator, so keep the user_creatable flag on the device class and remove the FIXME comment. Cc: Juergen Gross <jgross@suse.com>, Cc: Peter Maydell <peter.maydell@linaro.org>, Cc: Thomas Huth <thuth@redhat.com> Cc: sstabellini@kernel.org Cc: Markus Armbruster <armbru@redhat.com>, Cc: Marcel Apfelbaum <marcel@redhat.com>, Cc: Laszlo Ersek <lersek@redhat.com> Acked-by: Juergen Gross <jgross@suse.com> Acked-by: Marcel Apfelbaum <marcel@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com> Message-Id: <20170503203604.31462-4-ehabkost@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2017-05-17sysbus: Set user_creatable=false by default on TYPE_SYS_BUS_DEVICEEduardo Habkost
commit 33cd52b5d7b9adfd009e95f07e6c64dd88ae2a31 unset cannot_instantiate_with_device_add_yet in TYPE_SYSBUS, making all sysbus devices appear on "-device help" and lack the "no-user" flag in "info qdm". To fix this, we can set user_creatable=false by default on TYPE_SYS_BUS_DEVICE, but this requires setting user_creatable=true explicitly on the sysbus devices that actually work with -device. Fortunately today we have just a few has_dynamic_sysbus=1 machines: virt, pc-q35-*, ppce500, and spapr. virt, ppce500, and spapr have extra checks to ensure just a few device types can be instantiated: * virt supports only TYPE_VFIO_CALXEDA_XGMAC, TYPE_VFIO_AMD_XGBE. * ppce500 supports only TYPE_ETSEC_COMMON. * spapr supports only TYPE_SPAPR_PCI_HOST_BRIDGE. This patch sets user_creatable=true explicitly on those 4 device classes. Now, the more complex cases: pc-q35-*: q35 has no sysbus device whitelist yet (which is a separate bug). We are in the process of fixing it and building a sysbus whitelist on q35, but in the meantime we can fix the "-device help" and "info qdm" bugs mentioned above. Also, despite not being strictly necessary for fixing the q35 bug, reducing the list of user_creatable=true devices will help us be more confident when building the q35 whitelist. xen: We also have a hack at xen_set_dynamic_sysbus(), that sets has_dynamic_sysbus=true at runtime when using the Xen accelerator. This hack is only used to allow xen-backend devices to be dynamically plugged/unplugged. This means today we can use -device with the following 22 device types, that are the ones compiled into the qemu-system-x86_64 and qemu-system-i386 binaries: * allwinner-ahci * amd-iommu * cfi.pflash01 * esp * fw_cfg_io * fw_cfg_mem * generic-sdhci * hpet * intel-iommu * ioapic * isabus-bridge * kvmclock * kvm-ioapic * kvmvapic * SUNW,fdtwo * sysbus-ahci * sysbus-fdc * sysbus-ohci * unimplemented-device * virtio-mmio * xen-backend * xen-sysdev This patch adds user_creatable=true explicitly to those devices, temporarily, just to keep 100% compatibility with existing behavior of q35. Subsequent patches will remove user_creatable=true from the devices that are really not meant to user-creatable on any machine, and remove the FIXME comment from the ones that are really supposed to be user-creatable. This is being done in separate patches because we still don't have an obvious list of devices that will be whitelisted by q35, and I would like to get each device reviewed individually. Cc: Alexander Graf <agraf@suse.de> Cc: Alex Williamson <alex.williamson@redhat.com> Cc: Alistair Francis <alistair.francis@xilinx.com> Cc: Beniamino Galvani <b.galvani@gmail.com> Cc: Christian Borntraeger <borntraeger@de.ibm.com> Cc: Cornelia Huck <cornelia.huck@de.ibm.com> Cc: David Gibson <david@gibson.dropbear.id.au> Cc: "Edgar E. Iglesias" <edgar.iglesias@gmail.com> Cc: Eduardo Habkost <ehabkost@redhat.com> Cc: Frank Blaschka <frank.blaschka@de.ibm.com> Cc: Gabriel L. Somlo <somlo@cmu.edu> Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: Igor Mammedov <imammedo@redhat.com> Cc: Jason Wang <jasowang@redhat.com> Cc: John Snow <jsnow@redhat.com> Cc: Juergen Gross <jgross@suse.com> Cc: Kevin Wolf <kwolf@redhat.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Marcel Apfelbaum <marcel@redhat.com> Cc: Markus Armbruster <armbru@redhat.com> Cc: Max Reitz <mreitz@redhat.com> Cc: "Michael S. Tsirkin" <mst@redhat.com> Cc: Paolo Bonzini <pbonzini@redhat.com> Cc: Peter Maydell <peter.maydell@linaro.org> Cc: Pierre Morel <pmorel@linux.vnet.ibm.com> Cc: Prasad J Pandit <pjp@fedoraproject.org> Cc: qemu-arm@nongnu.org Cc: qemu-block@nongnu.org Cc: qemu-ppc@nongnu.org Cc: Richard Henderson <rth@twiddle.net> Cc: Rob Herring <robh@kernel.org> Cc: Shannon Zhao <zhaoshenglong@huawei.com> Cc: sstabellini@kernel.org Cc: Thomas Huth <thuth@redhat.com> Cc: Yi Min Zhao <zyimin@linux.vnet.ibm.com> Acked-by: John Snow <jsnow@redhat.com> Acked-by: Juergen Gross <jgross@suse.com> Acked-by: Marcel Apfelbaum <marcel@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com> Message-Id: <20170503203604.31462-3-ehabkost@redhat.com> Reviewed-by: Markus Armbruster <armbru@redhat.com> [ehabkost: Small changes at sysbus_device_class_init() comments] Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2017-05-17qdev: Replace cannot_instantiate_with_device_add_yet with !user_creatableEduardo Habkost
cannot_instantiate_with_device_add_yet was introduced by commit efec3dd631d94160288392721a5f9c39e50fb2bc to replace no_user. It was supposed to be a temporary measure. When it was introduced, we had 54 cannot_instantiate_with_device_add_yet=true lines in the code. Today (3 years later) this number has not shrunk: we now have 57 cannot_instantiate_with_device_add_yet=true lines. I think it is safe to say it is not a temporary measure, and we won't see the flag go away soon. Instead of a long field name that misleads people to believe it is temporary, replace it a shorter and less misleading field: user_creatable. Except for code comments, changes were generated using the following Coccinelle patch: @@ expression DC; @@ ( -DC->cannot_instantiate_with_device_add_yet = false; +DC->user_creatable = true; | -DC->cannot_instantiate_with_device_add_yet = true; +DC->user_creatable = false; ) @@ typedef ObjectClass; expression dc; identifier class, data; @@ static void device_class_init(ObjectClass *class, void *data) { ... dc->hotpluggable = true; +dc->user_creatable = true; ... } @@ @@ struct DeviceClass { ... -bool cannot_instantiate_with_device_add_yet; +bool user_creatable; ... } @@ expression DC; @@ ( -!DC->cannot_instantiate_with_device_add_yet +DC->user_creatable | -DC->cannot_instantiate_with_device_add_yet +!DC->user_creatable ) Cc: Alistair Francis <alistair.francis@xilinx.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Marcel Apfelbaum <marcel@redhat.com> Cc: Markus Armbruster <armbru@redhat.com> Cc: Peter Maydell <peter.maydell@linaro.org> Cc: Thomas Huth <thuth@redhat.com> Acked-by: Alistair Francis <alistair.francis@xilinx.com> Reviewed-by: Thomas Huth <thuth@redhat.com> Reviewed-by: Marcel Apfelbaum <marcel@redhat.com> Acked-by: Marcel Apfelbaum <marcel@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com> Message-Id: <20170503203604.31462-2-ehabkost@redhat.com> [ehabkost: kept "TODO remove once we're there" comment] Reviewed-by: Markus Armbruster <armbru@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2017-05-17migration: Move check_migratable() into qdev.cJuan Quintela
The function is only used once, and nothing else in migration knows about objects. Create the function vmstate_device_is_migratable() in savem.c that really do the bit that is related with migration. Signed-off-by: Juan Quintela <quintela@redhat.com> Reviewed-by: Peter Xu <peterx@redhat.com>
2017-05-17migration: Create migration/blocker.hJuan Quintela
This allows us to remove lots of includes of migration/migration.h Signed-off-by: Juan Quintela <quintela@redhat.com> Reviewed-by: Peter Xu <peterx@redhat.com> Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
2017-05-16xen: call qemu_set_cloexec instead of fcntlStefano Stabellini
Use the common utility function, which contains checks on return values and first calls F_GETFD as recommended by POSIX.1-2001, instead of manually calling fcntl. CID: 1374831 Signed-off-by: Stefano Stabellini <sstabellini@kernel.org> Reviewed-by: Eric Blake <eblake@redhat.com> Reviewed-by: Greg Kurz <groug@kaod.org> CC: anthony.perard@citrix.com CC: groug@kaod.org CC: aneesh.kumar@linux.vnet.ibm.com CC: Eric Blake <eblake@redhat.com>
2017-05-16xen/9pfs: fix two resource leaks on error paths, discovered by CoverityStefano Stabellini
CID: 1374836 Signed-off-by: Stefano Stabellini <sstabellini@kernel.org> Reviewed-by: Eric Blake <eblake@redhat.com> Reviewed-by: Greg Kurz <groug@kaod.org> CC: anthony.perard@citrix.com CC: groug@kaod.org CC: aneesh.kumar@linux.vnet.ibm.com
2017-05-16xen/mapcache: store dma information in revmapcache entries for debuggingStefano Stabellini
The Xen mapcache is able to create long term mappings, they are called "locked" mappings. The third parameter of the xen_map_cache call specifies if a mapping is a "locked" mapping. >From the QEMU point of view there are two kinds of long term mappings: [a] device memory mappings, such as option roms and video memory [b] dma mappings, created by dma_memory_map & friends After certain operations, ballooning a VM in particular, Xen asks QEMU kindly to destroy all mappings. However, certainly [a] mappings are present and cannot be removed. That's not a problem as they are not affected by balloonning. The *real* problem is that if there are any mappings of type [b], any outstanding dma operations could fail. This is a known shortcoming. In other words, when Xen asks QEMU to destroy all mappings, it is an error if any [b] mappings exist. However today we have no way of distinguishing [a] from [b]. Because of that, we cannot even print a decent warning. This patch introduces a new "dma" bool field to MapCacheRev entires, to remember if a given mapping is for dma or is a long term device memory mapping. When xen_invalidate_map_cache is called, we print a warning if any [b] mappings exist. We ignore [a] mappings. Mappings created by qemu_map_ram_ptr are assumed to be [a], while mappings created by address_space_map->qemu_ram_ptr_length are assumed to be [b]. The goal of the patch is to make debugging and system understanding easier. Signed-off-by: Stefano Stabellini <sstabellini@kernel.org> Acked-by: Paolo Bonzini <pbonzini@redhat.com> Acked-by: Anthony PERARD <anthony.perard@citrix.com>
2017-05-16Merge remote-tracking branch 'gkurz/tags/security-fix-for-2.10' into stagingStefan Hajnoczi
Fix for CVE-2017-7493. # gpg: Signature made Mon 15 May 2017 07:48:20 PM BST # gpg: using DSA key 0x02FC3AEB0101DBC2 # gpg: Good signature from "Greg Kurz <groug@kaod.org>" # gpg: aka "Greg Kurz <groug@free.fr>" # gpg: aka "Greg Kurz <gkurz@fr.ibm.com>" # gpg: aka "Greg Kurz <gkurz@linux.vnet.ibm.com>" # gpg: aka "Gregory Kurz (Groug) <groug@free.fr>" # gpg: aka "Gregory Kurz (Cimai Technology) <gkurz@cimai.com>" # gpg: aka "Gregory Kurz (Meiosys Technology) <gkurz@meiosys.com>" # gpg: WARNING: This key is not certified with a trusted signature! # gpg: There is no indication that the signature belongs to the owner. # Primary key fingerprint: 2BD4 3B44 535E C0A7 9894 DBA2 02FC 3AEB 0101 DBC2 * gkurz/tags/security-fix-for-2.10: 9pfs: local: forbid client access to metadata (CVE-2017-7493) Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
2017-05-15Merge remote-tracking branch 'kraxel/tags/pull-usb-20170512-1' into stagingStefan Hajnoczi
usb: bugfixes, doc update # gpg: Signature made Fri 12 May 2017 01:20:29 PM BST # gpg: using RSA key 0x4CB6D8EED3E87138 # gpg: Good signature from "Gerd Hoffmann (work) <kraxel@redhat.com>" # gpg: aka "Gerd Hoffmann <gerd@kraxel.org>" # gpg: aka "Gerd Hoffmann (private) <kraxel@gmail.com>" # Primary key fingerprint: A032 8CFF B93A 17A7 9901 FE7D 4CB6 D8EE D3E8 7138 * kraxel/tags/pull-usb-20170512-1: hw/usb/dev-serial: Do not try to set vendorid or productid properties xhci: relax link check usb-hub: clear PORT_STAT_SUSPEND on wakeup xhci: fix logging usb-redir: fix stack overflow in usbredir_log_data qemu-doc: Update to use the new way of attaching USB devices Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
2017-05-15Merge remote-tracking branch 'kraxel/tags/pull-ui-20170512-1' into stagingStefan Hajnoczi
ui: add egl-headless ui: some vnc cleanups ui: absolute events for input-linux # gpg: Signature made Fri 12 May 2017 12:50:07 PM BST # gpg: using RSA key 0x4CB6D8EED3E87138 # gpg: Good signature from "Gerd Hoffmann (work) <kraxel@redhat.com>" # gpg: aka "Gerd Hoffmann <gerd@kraxel.org>" # gpg: aka "Gerd Hoffmann (private) <kraxel@gmail.com>" # Primary key fingerprint: A032 8CFF B93A 17A7 9901 FE7D 4CB6 D8EE D3E8 7138 * kraxel/tags/pull-ui-20170512-1: vnc: replace hweight_long() with ctpopl() vnc: simple clean up opengl: add egl-headless display egl: explicitly ask for core context egl-helpers: add missing error check egl-helpers: fix display init for x11 egl-helpers: drop support for gles and debug logging virtio-gpu: move virtio_gpu_gl_block ui: input-linux: Add absolute event support ui: Support non-zero minimum values for absolute input axes Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
2017-05-159pfs: local: forbid client access to metadata (CVE-2017-7493)Greg Kurz
When using the mapped-file security mode, we shouldn't let the client mess with the metadata. The current code already tries to hide the metadata dir from the client by skipping it in local_readdir(). But the client can still access or modify it through several other operations. This can be used to escalate privileges in the guest. Affected backend operations are: - local_mknod() - local_mkdir() - local_open2() - local_symlink() - local_link() - local_unlinkat() - local_renameat() - local_rename() - local_name_to_path() Other operations are safe because they are only passed a fid path, which is computed internally in local_name_to_path(). This patch converts all the functions listed above to fail and return EINVAL when being passed the name of the metadata dir. This may look like a poor choice for errno, but there's no such thing as an illegal path name on Linux and I could not think of anything better. This fixes CVE-2017-7493. Reported-by: Leo Gaspard <leo@gaspard.io> Signed-off-by: Greg Kurz <groug@kaod.org> Reviewed-by: Eric Blake <eblake@redhat.com>
2017-05-15Merge remote-tracking branch 'ehabkost/tags/x86-and-machine-pull-request' ↵Stefan Hajnoczi
into staging x86 and machine queue, 2017-05-11 Highlights: * New "-numa cpu" option * NUMA distance configuration * migration/i386 vmstatification # gpg: Signature made Thu 11 May 2017 08:16:07 PM BST # gpg: using RSA key 0x2807936F984DC5A6 # gpg: Good signature from "Eduardo Habkost <ehabkost@redhat.com>" # gpg: Note: This key has expired! # Primary key fingerprint: 5A32 2FD5 ABC4 D3DB ACCF D1AA 2807 936F 984D C5A6 * ehabkost/tags/x86-and-machine-pull-request: (29 commits) migration/i386: Remove support for pre-0.12 formats vmstatification: i386 FPReg migration/i386: Remove old non-softfloat 64bit FP support tests: check -numa node,cpu=props_list usecase numa: add '-numa cpu,...' option for property based node mapping numa: remove node_cpu bitmaps as they are no longer used numa: use possible_cpus for not mapped CPUs check machine: call machine init from wrapper numa: remove no longer need numa_post_machine_init() tests: numa: add case for QMP command query-cpus QMP: include CpuInstanceProperties into query_cpus output output virt-arm: get numa node mapping from possible_cpus instead of numa_get_node_for_cpu() spapr: get numa node mapping from possible_cpus instead of numa_get_node_for_cpu() pc: get numa node mapping from possible_cpus instead of numa_get_node_for_cpu() numa: do default mapping based on possible_cpus instead of node_cpu bitmaps numa: mirror cpu to node mapping in MachineState::possible_cpus numa: add check that board supports cpu_index to node mapping virt-arm: add node-id property to CPU pc: add node-id property to CPU spapr: add node-id property to sPAPR core ... Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
2017-05-15Merge remote-tracking branch 'kraxel/tags/pull-vga-20170511-1' into stagingStefan Hajnoczi
make display updates thread safe, batch #2 # gpg: Signature made Thu 11 May 2017 03:41:51 PM BST # gpg: using RSA key 0x4CB6D8EED3E87138 # gpg: Good signature from "Gerd Hoffmann (work) <kraxel@redhat.com>" # gpg: aka "Gerd Hoffmann <gerd@kraxel.org>" # gpg: aka "Gerd Hoffmann (private) <kraxel@gmail.com>" # Primary key fingerprint: A032 8CFF B93A 17A7 9901 FE7D 4CB6 D8EE D3E8 7138 * kraxel/tags/pull-vga-20170511-1: vga: fix display update region calculation sm501: make display updates thread safe tcx: make display updates thread safe cg3: make display updates thread safe Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
2017-05-15Merge remote-tracking branch 'dgibson/tags/ppc-for-2.10-20170511' into stagingStefan Hajnoczi
ppc patch queue for 2017-05-11 This pull request supersedes the one from yesterday (20170510), fixing an important style bug in one patch, and adding an extra couple of simple patches. Highlights of this set: * Some fixes for POWER9 * TCG support for POWER9 radix MMU * VGA rom for Mac machine types * Fixes for the XICS interrupt controller * MTTCG support for ppc targets As suggested by Paolo, I've tried to add the Docker tests to my standard pre-pull-request tests. I haven't wholly suceeded; this has been tested with some of the Docker images, but others I haven't managed due to problems that as best I can tell are not due to problems in this patch series. I'll continue working on this for future pull requests. Specifically, 'travis', 'fedora', and 'centos6' seem to work. 'min-glib' jammed while gtesting moxie, which seems very unlikely to be caused by this series. 'ubuntu', 'debian' and 'debian-bootstrap' hit build errors almost immediately that look like problems with the container configuration, and 'debian-*-cross' hit build errors later on which also look like missing dependencies from the container. # gpg: Signature made Thu 11 May 2017 05:13:46 AM BST # gpg: using RSA key 0x6C38CACA20D9B392 # gpg: Good signature from "David Gibson <david@gibson.dropbear.id.au>" # gpg: aka "David Gibson (kernel.org) <dwg@kernel.org>" # gpg: aka "David Gibson (Red Hat) <dgibson@redhat.com>" # gpg: aka "David Gibson (ozlabs.org) <dgibson@ozlabs.org>" # Primary key fingerprint: 75F4 6586 AE61 A66C C44E 87DC 6C38 CACA 20D9 B392 * dgibson/tags/ppc-for-2.10-20170511: (23 commits) target/ppc: Avoid printing wrong aliases in CPU help text pnv: Fix build failures on some host platforms target/ppc: Allow workarounds for POWER9 DD1 spapr: Don't accidentally advertise HTM support on POWER9 ppc: xics: fix compilation with CentOS 6 target/ppc: Enable RADIX mmu mode for pseries TCG guest target/ppc: Implement ISA V3.00 radix page fault handler target/ppc: Change tlbie invalid fields for POWER9 support target/ppc: Update tlbie to check privilege level based on GTSE target/ppc: Set UPRT and GTSE on all cpus in H_REGISTER_PROCESS_TABLE ppc: add qemu_vga.ndrv ROM to fw_cfg interface for NewWorld Macs ppc: add qemu_vga.ndrv ROM to fw_cfg interface for OldWorld Macs Add QemuMacDrivers qemu_vga.ndrv revision d4e7d7a built as submodule Add QemuMacDrivers as submodule ppc/xics: preserve P and Q bits for KVM IRQs ppc/xics: Fix stale irq->status bits after get target/ppc: do not reset reserve_addr in exec_enter tcg: enable MTTCG by default for PPC64 on x86 cpus: Fix CPU unplug for MTTCG target/ppc: Generate fence operations ... Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
2017-05-12Merge remote-tracking branch 'kwolf/tags/for-upstream' into stagingStefan Hajnoczi
Block layer patches # gpg: Signature made Thu 11 May 2017 10:31:37 AM EDT # 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 * kwolf/tags/for-upstream: (58 commits) MAINTAINERS: Add qemu-progress to the block layer qcow2: Discard/zero clusters by byte count qcow2: Assert that cluster operations are aligned qcow2: Optimize write zero of unaligned tail cluster iotests: Add test 179 to cover write zeroes with unmap iotests: Improve _filter_qemu_img_map qcow2: Optimize zero_single_l2() to minimize L2 churn qcow2: Make distinction between zero cluster types obvious qcow2: Name typedef for cluster type qcow2: Correctly report status of preallocated zero clusters block: Update comments on BDRV_BLOCK_* meanings qcow2: Use consistent switch indentation qcow2: Nicer variable names in qcow2_update_snapshot_refcount() tests: Add coverage for recent block geometry fixes blkdebug: Add ability to override unmap geometries blkdebug: Simplify override logic blkdebug: Add pass-through write_zero and discard support blkdebug: Refactor error injection blkdebug: Sanity check block layer guarantees qemu-io: Switch 'map' output to byte-based reporting ... Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
2017-05-12hw/usb/dev-serial: Do not try to set vendorid or productid propertiesThomas Huth
When starting QEMU with the legacy USB serial device like this: qemu-system-x86_64 -usbdevice serial:vendorid=0x1234:stdio it currently aborts since the vendorid property does not exist anymore (it has been removed by commit f29783f72ea77dfbd7ea0c9): Unexpected error in object_property_find() at qemu/qom/object.c:1008: qemu-system-x86_64: -usbdevice serial:vendorid=0x1234:stdio: Property '.vendorid' not found Aborted (core dumped) Fix this crash by issuing a more friendly error message instead (and simplify the code also a little bit this way). Signed-off-by: Thomas Huth <thuth@redhat.com> Message-id: 1493883704-27604-1-git-send-email-thuth@redhat.com Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2017-05-12xhci: relax link checkLadi Prosek
The strict td link limit added by commit "05f43d4 xhci: limit the number of link trbs we are willing to process" causes problems with Windows guests. Let's raise the limit. This change is analogous to: commit ab6b1105a2259c7072905887f71caa850ce63190 Author: Gerd Hoffmann <kraxel@redhat.com> Date: Tue Mar 7 09:40:18 2017 +0100 ohci: relax link check Signed-off-by: Ladi Prosek <lprosek@redhat.com> Message-id: 20170512102100.22675-1-lprosek@redhat.com Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2017-05-12usb-hub: clear PORT_STAT_SUSPEND on wakeupLadi Prosek
The spec says: Suspend: (PORT_SUSPEND) This field indicates whether or not the device on this port is suspended. Setting this field causes the device to suspend by not propagating bus traffic downstream. This field may be reset by a request or by resume signaling from the device attached to the port. I can't find any specific statement like "the PORT_SUSPEND field is reset automatically on remote wakeup", but without this patch, the only way to reset it is via the ClearPortFeature request so the ".. or by resume signaling from the device" clause is clearly not implemented on the remote wakeup path. The default xhci Windows driver does not issue the ClearPortFeature request and suspended devices attached to a hub don't properly get out of the suspended state. Interestingly, the default uhci Windows driver *does* issue the ClearPortFeature request and does not exhibit this problem. Signed-off-by: Ladi Prosek <lprosek@redhat.com> Message-id: 20170511125314.24549-3-lprosek@redhat.com Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2017-05-12xhci: fix loggingLadi Prosek
slotid and epid were deleted from XHCITransfer in commit d6fcb29. Also deleting one unused forward declaration. Signed-off-by: Ladi Prosek <lprosek@redhat.com> Message-id: 20170511125314.24549-2-lprosek@redhat.com Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2017-05-12usb-redir: fix stack overflow in usbredir_log_dataGerd Hoffmann
Don't reinvent a broken wheel, just use the hexdump function we have. Impact: low, broken code doesn't run unless you have debug logging enabled. Reported-by: 李强 <liqiang6-s@360.cn> Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Message-id: 20170509110128.27261-1-kraxel@redhat.com
2017-05-12virtio-gpu: move virtio_gpu_gl_blockGerd Hoffmann
Move to virtio-gpu-3d.c where all the other virgl code lives too. Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Message-id: 20170505104101.30589-2-kraxel@redhat.com
2017-05-11numa: use possible_cpus for not mapped CPUs checkIgor Mammedov
and remove corresponding part in numa.c that uses node_cpu bitmaps. Signed-off-by: Igor Mammedov <imammedo@redhat.com> Reviewed-by: David Gibson <david@gibson.dropbear.id.au> Reviewed-by: Andrew Jones <drjones@redhat.com> Message-Id: <1494415802-227633-16-git-send-email-imammedo@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2017-05-11machine: call machine init from wrapperIgor Mammedov
add machine_run_board_init() wrapper that calls machine init for now but in follow up patches it will be used to run generic machine code that should run before machine init. Signed-off-by: Igor Mammedov <imammedo@redhat.com> Reviewed-by: Andrew Jones <drjones@redhat.com> Reviewed-by: David Gibson <david@gibson.dropbear.id.au> Reviewed-by: Eduardo Habkost <ehabkost@redhat.com> Message-Id: <1494415802-227633-15-git-send-email-imammedo@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2017-05-11virt-arm: get numa node mapping from possible_cpus instead of ↵Igor Mammedov
numa_get_node_for_cpu() Signed-off-by: Igor Mammedov <imammedo@redhat.com> Reviewed-by: Andrew Jones <drjones@redhat.com> Message-Id: <1494415802-227633-11-git-send-email-imammedo@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2017-05-11spapr: get numa node mapping from possible_cpus instead of ↵Igor Mammedov
numa_get_node_for_cpu() it's safe to remove thread node_id != core node_id error branch as machine_set_cpu_numa_node() also does mismatch check and is called even before any CPU is created. Signed-off-by: Igor Mammedov <imammedo@redhat.com> Acked-by: David Gibson <david@gibson.dropbear.id.au> Message-Id: <1494415802-227633-10-git-send-email-imammedo@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2017-05-11pc: get numa node mapping from possible_cpus instead of numa_get_node_for_cpu()Igor Mammedov
Signed-off-by: Igor Mammedov <imammedo@redhat.com> Reviewed-by: Andrew Jones <drjones@redhat.com> Message-Id: <1494415802-227633-9-git-send-email-imammedo@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2017-05-11numa: mirror cpu to node mapping in MachineState::possible_cpusIgor Mammedov
Introduce machine_set_cpu_numa_node() helper that stores node mapping for CPU in MachineState::possible_cpus. CPU and node it belongs to is specified by 'props' argument. Patch doesn't remove old way of storing mapping in numa_info[X].node_cpu as removing it at the same time makes patch rather big. Instead it just mirrors mapping in possible_cpus and follow up per target patches will switch to possible_cpus and numa_info[X].node_cpu will be removed once there isn't any users left. Signed-off-by: Igor Mammedov <imammedo@redhat.com> Reviewed-by: David Gibson <david@gibson.dropbear.id.au> Reviewed-by: Andrew Jones <drjones@redhat.com> Message-Id: <1494415802-227633-7-git-send-email-imammedo@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2017-05-11virt-arm: add node-id property to CPUIgor Mammedov
it will allow switching from cpu_index to property based numa mapping in follow up patches. Signed-off-by: Igor Mammedov <imammedo@redhat.com> Reviewed-by: Andrew Jones <drjones@redhat.com> Message-Id: <1494415802-227633-5-git-send-email-imammedo@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2017-05-11pc: add node-id property to CPUIgor Mammedov
it will allow switching from cpu_index to property based numa mapping in follow up patches. PS: patch changes default value of CPUState::numa_node from 0 to CPU_UNSET_NUMA_NODE_ID. The only place for x86 that would affected is monitor's 'infor numa' command which uses that field. However legacy 0 value is still preserved by pc_cpu_pre_plug() in this patch if user/numa.c hasn't set it explicitly, so there is no change in behavior. Signed-off-by: Igor Mammedov <imammedo@redhat.com> Message-Id: <1494415802-227633-4-git-send-email-imammedo@redhat.com> Reviewed-by: Eduardo Habkost <ehabkost@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2017-05-11spapr: add node-id property to sPAPR coreIgor Mammedov
it will allow switching from cpu_index to core based numa mapping in follow up patches. Signed-off-by: Igor Mammedov <imammedo@redhat.com> Reviewed-by: David Gibson <david@gibson.dropbear.id.au> Message-Id: <1494415802-227633-3-git-send-email-imammedo@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2017-05-11numa: move source of default CPUs to NUMA node mapping into boardsIgor Mammedov
Originally CPU threads were by default assigned in round-robin fashion. However it was causing issues in guest since CPU threads from the same socket/core could be placed on different NUMA nodes. Commit fb43b73b (pc: fix default VCPU to NUMA node mapping) fixed it by grouping threads within a socket on the same node introducing cpu_index_to_socket_id() callback and commit 20bb648d (spapr: Fix default NUMA node allocation for threads) reused callback to fix similar issues for SPAPR machine even though socket doesn't make much sense there. As result QEMU ended up having 3 default distribution rules used by 3 targets /virt-arm, spapr, pc/. In effort of moving NUMA mapping for CPUs into possible_cpus, generalize default mapping in numa.c by making boards decide on default mapping and let them explicitly tell generic numa code to which node a CPU thread belongs to by replacing cpu_index_to_socket_id() with @cpu_index_to_instance_props() which provides default node_id assigned by board to specified cpu_index. Signed-off-by: Igor Mammedov <imammedo@redhat.com> Reviewed-by: Eduardo Habkost <ehabkost@redhat.com> Message-Id: <1494415802-227633-2-git-send-email-imammedo@redhat.com> Reviewed-by: David Gibson <david@gibson.dropbear.id.au> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2017-05-11hw/arm/virt: explicitly allocate cpu_index for cpusIgor Mammedov
Currently cpu_index is implicitly auto assigned during cpu.realize() time cpu_exec_realizefn()->cpu_list_add(). It happens to match index in possible_cpus so take control over it and make board initialize cpu_index to possible_cpus index explicitly. It will at least document that board is in control of it and when '-device cpu' support comes it will keep cpu_index stable regardless of order cpus are created so it won't break migration. Within this series it will be used for internal conversion from storing cpu_index based NUMA node bitmaps to property based mapping with possible_cpus, And will allow map cpu_index to a CPU entry in possible_cpus array. Signed-off-by: Igor Mammedov <imammedo@redhat.com> Reviewed-by: Andrew Jones <drjones@redhat.com> Message-Id: <1493816238-33120-5-git-send-email-imammedo@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2017-05-11hw/arm/virt: use machine->possible_cpus for storing possible topology infoIgor Mammedov
for now precalculate and store mp_afinity in possible_cpus as ARM cpus don't have socket/core/thread-id properties yet. In follow patches possible_cpus will be used for storing and setting NUMA node mapping and replace legacy bitmap based numa_info[node_id].node_cpu/numa_get_node_for_cpu() For the lack of better idea, this patch cannibalizes possible_cpus.cpus[x].props.thread_id so that *_cpu_index_to_props() callback could return addressable by props CPU which will be used by machine_set_cpu_numa_node() in follow up patches to assign a CPU to node. But cannibalizing is fine for now as that thread_id isn't exposed to users (no hotpluggable_cpus callback support for ARM yet) and it will be used only internally until 'device_add cpu' is supported where we can decide on which properties to use. Signed-off-by: Igor Mammedov <imammedo@redhat.com> Message-Id: <1493816238-33120-4-git-send-email-imammedo@redhat.com> Reviewed-by: Andrew Jones <drjones@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2017-05-11hw/arm/virt: extract mp-affinity calculation in separate functionIgor Mammedov
Signed-off-by: Igor Mammedov <imammedo@redhat.com> Message-Id: <1493816238-33120-3-git-send-email-imammedo@redhat.com> Reviewed-by: Andrew Jones <drjones@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2017-05-11numa: equally distribute memory on nodesLaurent Vivier
When there are more nodes than available memory to put the minimum allowed memory by node, all the memory is put on the last node. This is because we put (ram_size / nb_numa_nodes) & ~((1 << mc->numa_mem_align_shift) - 1); on each node, and in this case the value is 0. This is particularly true with pseries, as the memory must be aligned to 256MB. To avoid this problem, this patch uses an error diffusion algorithm [1] to distribute equally the memory on nodes. We introduce numa_auto_assign_ram() function in MachineClass to keep compatibility between machine type versions. The legacy function is used with pseries-2.9, pc-q35-2.9 and pc-i440fx-2.9 (and previous), the new one with all others. Example: qemu-system-ppc64 -S -nographic -nodefaults -monitor stdio -m 1G -smp 8 \ -numa node -numa node -numa node \ -numa node -numa node -numa node Before: (qemu) info numa 6 nodes node 0 cpus: 0 6 node 0 size: 0 MB node 1 cpus: 1 7 node 1 size: 0 MB node 2 cpus: 2 node 2 size: 0 MB node 3 cpus: 3 node 3 size: 0 MB node 4 cpus: 4 node 4 size: 0 MB node 5 cpus: 5 node 5 size: 1024 MB After: (qemu) info numa 6 nodes node 0 cpus: 0 6 node 0 size: 0 MB node 1 cpus: 1 7 node 1 size: 256 MB node 2 cpus: 2 node 2 size: 0 MB node 3 cpus: 3 node 3 size: 256 MB node 4 cpus: 4 node 4 size: 256 MB node 5 cpus: 5 node 5 size: 256 MB [1] https://en.wikipedia.org/wiki/Error_diffusion Signed-off-by: Laurent Vivier <lvivier@redhat.com> Message-Id: <20170502162955.1610-2-lvivier@redhat.com> Reviewed-by: Eduardo Habkost <ehabkost@redhat.com> [ehabkost: s/ram_size/size/ at numa_default_auto_assign_ram()] Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2017-05-11numa: Allow setting NUMA distance for different NUMA nodesHe Chen
This patch is going to add SLIT table support in QEMU, and provides additional option `dist` for command `-numa` to allow user set vNUMA distance by QEMU command. With this patch, when a user wants to create a guest that contains several vNUMA nodes and also wants to set distance among those nodes, the QEMU command would like: ``` -numa node,nodeid=0,cpus=0 \ -numa node,nodeid=1,cpus=1 \ -numa node,nodeid=2,cpus=2 \ -numa node,nodeid=3,cpus=3 \ -numa dist,src=0,dst=1,val=21 \ -numa dist,src=0,dst=2,val=31 \ -numa dist,src=0,dst=3,val=41 \ -numa dist,src=1,dst=2,val=21 \ -numa dist,src=1,dst=3,val=31 \ -numa dist,src=2,dst=3,val=21 \ ``` Signed-off-by: He Chen <he.chen@linux.intel.com> Message-Id: <1493260558-20728-1-git-send-email-he.chen@linux.intel.com> Reviewed-by: Igor Mammedov <imammedo@redhat.com> Reviewed-by: Andrew Jones <drjones@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2017-05-11nvme: Implement Write ZeroesChristoph Hellwig
Signed-off-by: Keith Busch <keith.busch@intel.com> [hch: ported over from qemu-nvme.git to mainline] Signed-off-by: Christoph Hellwig <hch@lst.de> Acked-by: Keith Busch <keith.busch@intel.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2017-05-11vga: fix display update region calculationGerd Hoffmann
vga display update mis-calculated the region for the dirty bitmap snapshot in case the scanlines are padded. This can triggere an assert in cpu_physical_memory_snapshot_get_dirty(). Fixes: fec5e8c92becad223df9d972770522f64aafdb72 Reported-by: Kevin Wolf <kwolf@redhat.com> Reported-by: 李强 <liqiang6-s@360.cn> Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Message-id: 20170509104839.19415-1-kraxel@redhat.com
2017-05-11sm501: make display updates thread safeGerd Hoffmann
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Message-id: 20170509111928.30935-1-kraxel@redhat.com
2017-05-11tcx: make display updates thread safeMark Cave-Ayland
Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> Message-id: 1494449551-20227-3-git-send-email-mark.cave-ayland@ilande.co.uk Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2017-05-11cg3: make display updates thread safeMark Cave-Ayland
Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> Message-id: 1494449551-20227-2-git-send-email-mark.cave-ayland@ilande.co.uk Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2017-05-11ui: Support non-zero minimum values for absolute input axesPhilippe Voinov
This patch refactors ui/input.c to support absolute axis minimum values other than 0. All dependent calls to qemu_input_queue_abs have been updated to explicitly supply 0 as the axis minimum value. Signed-off-by: Philippe Voinov <philippevoinov@gmail.com> Message-id: 20170505133952.29885-1-philippevoinov@gmail.com Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2017-05-11spapr: Don't accidentally advertise HTM support on POWER9David Gibson
Logic in spapr_populate_pa_features() enables the bit advertising Hardware Transactional Memory (HTM) in the guest's device tree only when KVM advertises its availability with the KVM_CAP_PPC_HTM feature. However, this assumes that the HTM bit is off in the base template used for the device tree value. That is true for POWER8, but not for POWER9. It looks like that was accidentally changed in 9fb4541 "spapr: Enable ISA 3.0 MMU mode selection via CAS". Fixes: 9fb4541f5803f8d2ba116b12113386e26482ba30 Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Reviewed-by: Thomas Huth <thuth@redhat.com>
2017-05-11target/ppc: Enable RADIX mmu mode for pseries TCG guestSuraj Jitindar Singh
Now that we have added all the infrastructure we can enable a pseries TCG guest to use radix. In order to do this we have to add the appropriate bits to the ibm,arch-vec-5-platform-support vector to represent that we support both hash and radix mmu models. A radix guest can now be booted in pseries tcg mode by specifying: -cpu POWER9 Note that we assume hash, that is we allocate a hpt, until a guest tells us otherwise via a H_REGISTER_PROCESS_TABLE call with radix specified - in which case we free the hpt. If we were right and the guest is hash then there's nothing for us to do. Signed-off-by: Suraj Jitindar Singh <sjitindarsingh@gmail.com> Reviewed-by: David Gibson <david@gibson.dropbear.id.au> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>