aboutsummaryrefslogtreecommitdiff
path: root/hw
AgeCommit message (Collapse)Author
2018-01-22Merge remote-tracking branch 'remotes/dgibson/tags/ppc-for-2.12-20180121' ↵Peter Maydell
into staging ppc patch queue 2018-01-21 This request supersedes the one from 2018-01-19. The only difference is that the patch deprecating ppcemb-softmmu, and thereby creating many annying warnings from make check has been removed. Highlights are: * Significant TCG speedup by optimizing cmp generation * Fix a regression caused by recent change to set compat mode on hotplugged cpus * Cleanup of default configs * Some implementation of msgsnd/msgrcv instructions for server chips # gpg: Signature made Sun 21 Jan 2018 05:30:54 GMT # gpg: using RSA key 0x6C38CACA20D9B392 # gpg: Good signature from "David Gibson <david@gibson.dropbear.id.au>" # gpg: aka "David Gibson (Red Hat) <dgibson@redhat.com>" # gpg: aka "David Gibson (ozlabs.org) <dgibson@ozlabs.org>" # gpg: aka "David Gibson (kernel.org) <dwg@kernel.org>" # Primary key fingerprint: 75F4 6586 AE61 A66C C44E 87DC 6C38 CACA 20D9 B392 * remotes/dgibson/tags/ppc-for-2.12-20180121: target/ppc/spapr_caps: Add macro to generate spapr_caps migration vmstate target/ppc: add support for hypervisor doorbells on book3s CPUs sii3112: Add explicit type casts to avoid unintended sign extension sm501: Add missing break to case target-ppc: optimize cmp translation spapr: fix device tree properties when using compatibility mode spapr: drop duplicate variable in spapr_core_plug() target/ppc: msgsnd and msgclr instructions need hypervisor privilege target/ppc: fix doorbell and hypervisor doorbell definitions hw/ppc/Makefile: Add a way to disable the PPC4xx boards default-configs/ppc-softmmu: Restructure the switches according to the machines default-configs/ppc64-softmmu: Include 32-bit configs instead of copying them Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2018-01-20target/ppc/spapr_caps: Add macro to generate spapr_caps migration vmstateSuraj Jitindar Singh
The vmstate description and the contained needed function for migration of spapr_caps is the same for each cap, with the name of the cap substituted. As such introduce a macro to allow for easier generation of these. Convert the three existing spapr_caps (htm, vsx, and dfp) to use this macro. Signed-off-by: Suraj Jitindar Singh <sjitindarsingh@gmail.com> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2018-01-20sii3112: Add explicit type casts to avoid unintended sign extensionBALATON Zoltan
Noticed by Coverity Reported-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: BALATON Zoltan <balaton@eik.bme.hu> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2018-01-20sm501: Add missing break to caseBALATON Zoltan
Noticed by Coverity, forgotten in 5690d9ece Reported-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: BALATON Zoltan <balaton@eik.bme.hu> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2018-01-20spapr: fix device tree properties when using compatibility modeGreg Kurz
Commit 51f84465dd98 changed the compatility mode setting logic: - machine reset only sets compatibility mode for the boot CPU - compatibility mode is set for other CPUs when they are put online by the guest with the "start-cpu" RTAS call This causes a regression for machines started with max-compat-cpu: the device tree nodes related to secondary CPU cores contain wrong "cpu-version" and "ibm,pa-features" values, as shown below. Guest started on a POWER8 host with: -smp cores=2 -machine pseries,max-cpu-compat=compat7 ibm,pa-features = [18 00 f6 3f c7 c0 80 f0 80 00 00 00 00 00 00 00 00 00 80 00 80 00 80 00 00 00]; cpu-version = <0x4d0200>; ^^^ second CPU core ibm,pa-features = <0x600f63f 0xc70080c0>; cpu-version = <0xf000003>; ^^^ boot CPU core The second core is advertised in raw POWER8 mode. This happens because CAS assumes all CPUs to have the same compatibility mode. Since the boot CPU already has the requested compatibility mode, the CAS code does not set it for the secondary one, and exposes the bogus device tree properties in in the CAS response to the guest. A similar situation is observed when hot-plugging a CPU core. The related device tree properties are generated and exposed to guest with the "ibm,configure-connector" RTAS before "start-cpu" is called. The CPU core is advertised to the guest in raw mode as well. It both cases, it boils down to the fact that "start-cpu" happens too late. This can be fixed globally by propagating the compatibility mode of the boot CPU to the other CPUs during reset. For this to work, the compatibility mode of the boot CPU must be set before the machine code actually resets all CPUs. It is not needed to set the compatibility mode in "start-cpu" anymore, so the code is dropped. Fixes: 51f84465dd98 Signed-off-by: Greg Kurz <groug@kaod.org> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2018-01-20spapr: drop duplicate variable in spapr_core_plug()Greg Kurz
A variable is already defined at the begining of the function to hold a pointer to the CPU core object: sPAPRCPUCore *core = SPAPR_CPU_CORE(OBJECT(dev)); No need to define it again in the pre-2.10 compatibility code snipplet. Signed-off-by: Greg Kurz <groug@kaod.org> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2018-01-20hw/ppc/Makefile: Add a way to disable the PPC4xx boardsThomas Huth
We've got the config switch CONFIG_PPC4XX, so we should use it in the Makefile accordingly and only include the PPC4xx boards if this switch has been enabled. (Note: Unfortunately, the files ppc4xx_devs.c and ppc405_uc.c still have to be included in the build anyway to fulfil some complicated linker dependencies ... so these are subject to a more thourough clean-up later) Signed-off-by: Thomas Huth <thuth@redhat.com> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2018-01-19hw/ide: Remove duplicated definitions from ahci_internal.hJohn Snow
The same definitions can also be found in include/hw/ide/ahci.h so let's remove these #defines from ahci_internal.h. Signed-off-by: Thomas Huth <thuth@redhat.com> Message-id: 1512457825-3847-1-git-send-email-thuth@redhat.com [Maintainer edit: publicize object names, privatize object macros.] Signed-off-by: John Snow <jsnow@redhat.com>
2018-01-19ide: abort TRIM operation for invalid rangeAnton Nefedov
ATA8-ACS3, 7.9 DATA SET MANAGEMENT - 06h, DMA 7.9.5 Error Outputs If the Trim bit is set to one and: a) the device detects an invalid LBA Range Entry; or b) count is greater than IDENTIFY DEVICE data word 105 (see 7.16.7.55), then the device shall return command aborted. A device may trim one or more LBA Range Entries before it returns command aborted. See table 209. This check is not in the common ide_dma_cb() as the range for TRIM is harder to reach: it is not in LBA/count registers and the buffer has to be parsed first. Signed-off-by: Anton Nefedov <anton.nefedov@virtuozzo.com> Message-id: 1512735034-35327-4-git-send-email-anton.nefedov@virtuozzo.com Signed-off-by: John Snow <jsnow@redhat.com>
2018-01-19ide: move ide_sect_range_ok() upAnton Nefedov
to use it without a forward declaration in the commit to follow Signed-off-by: Anton Nefedov <anton.nefedov@virtuozzo.com> Message-id: 1512735034-35327-3-git-send-email-anton.nefedov@virtuozzo.com Signed-off-by: John Snow <jsnow@redhat.com>
2018-01-19ide: pass IDEState to trim AIO callbackAnton Nefedov
It will be needed to handle invalid requests Signed-off-by: Anton Nefedov <anton.nefedov@virtuozzo.com> Message-id: 1512735034-35327-2-git-send-email-anton.nefedov@virtuozzo.com Signed-off-by: John Snow <jsnow@redhat.com>
2018-01-19fw_cfg: fix memory corruption when all fw_cfg slots are usedMarcel Apfelbaum
When all the fw_cfg slots are used, a write is made outside the bounds of the fw_cfg files array as part of the sort algorithm. Fix it by avoiding an unnecessary array element move. Fix also an assert while at it. Signed-off-by: Marcel Apfelbaum <marcel@redhat.com> Message-Id: <20180108215007.46471-1-marcel@redhat.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2018-01-19possible_cpus: add CPUArchId::type fieldIgor Mammedov
Remove dependency of possible_cpus on 1st CPU instance, which decouples configuration data from CPU instances that are created using that data. Also later it would be used for enabling early cpu to numa node configuration at runtime qmp_query_hotpluggable_cpus() should provide a list of available cpu slots at early stage, before machine_init() is called and the 1st cpu is created, so that mgmt might be able to call it and use output to set numa mapping. Use MachineClass::possible_cpu_arch_ids() callback to set cpu type info, along with the rest of possible cpu properties, to let machine define which cpu type* will be used. * for SPAPR it will be a spapr core type and for ARM/s390x/x86 a respective descendant of CPUClass. Move parse_numa_opts() in vl.c after cpu_model is parsed into cpu_type so that possible_cpu_arch_ids() would know which cpu_type to use during layout initialization. Signed-off-by: Igor Mammedov <imammedo@redhat.com> Reviewed-by: David Gibson <david@gibson.dropbear.id.au> Message-Id: <1515597770-268979-1-git-send-email-imammedo@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2018-01-19nvdimm: add 'unarmed' optionHaozhong Zhang
Currently the only vNVDIMM backend can guarantee the guest write persistence is device DAX on Linux, because no host-side kernel cache is involved in the guest access to it. The approach to detect whether the backend is device DAX needs to access sysfs, which may not work with SELinux. Instead, we add the 'unarmed' option to device 'nvdimm', so that users or management utils, which have enough knowledge about the backend, can control the unarmed flag in guest ACPI NFIT via this option. The guest Linux NVDIMM driver, for example, will mark the corresponding vNVDIMM device read-only if the unarmed flag in guest NFIT is set. The default value of 'unarmed' option is 'off' in order to keep the backwards compatibility. Signed-off-by: Haozhong Zhang <haozhong.zhang@intel.com> Message-Id: <20171211072806.2812-4-haozhong.zhang@intel.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2018-01-19nvdimm: add a macro for property "label-size"Haozhong Zhang
Signed-off-by: Haozhong Zhang <haozhong.zhang@intel.com> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> Message-Id: <20171211072806.2812-3-haozhong.zhang@intel.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2018-01-19qdev: Check for the availability of a hotplug controller before adding a deviceThomas Huth
The qdev_unplug() function contains a g_assert(hotplug_ctrl) statement, so QEMU crashes when the user tries to device_add + device_del a device that does not have a corresponding hotplug controller. This could be provoked for a couple of devices in the past (see commit 4c93950659487c7ad or 84ebd3e8c7d4fe955 for example), and can currently for example also be triggered like this: $ s390x-softmmu/qemu-system-s390x -M none -nographic QEMU 2.10.50 monitor - type 'help' for more information (qemu) device_add qemu-s390x-cpu,id=x (qemu) device_del x ** ERROR:qemu/qdev-monitor.c:872:qdev_unplug: assertion failed: (hotplug_ctrl) Aborted (core dumped) So devices clearly need a hotplug controller when they should be usable with device_add. The code in qdev_device_add() already checks whether the bus has a proper hotplug controller, but for devices that do not have a corresponding bus, there is no appropriate check available yet. In that case we should check whether the machine itself provides a suitable hotplug controller and refuse to plug the device if none is available. Reviewed-by: Igor Mammedov <imammedo@redhat.com> Signed-off-by: Thomas Huth <thuth@redhat.com> Message-Id: <1509617407-21191-3-git-send-email-thuth@redhat.com> Reviewed-by: Cornelia Huck <cohuck@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2018-01-19q35: Allow only supported dynamic sysbus devicesEduardo Habkost
The only user-creatable sysbus devices in qemu-system-x86_64 are amd-iommu, intel-iommu, and xen-backend. xen-backend is handled by xen_set_dynamic_sysbus(), so we only need to add amd-iommu and intel-iommu. Cc: "Michael S. Tsirkin" <mst@redhat.com> Cc: Marcel Apfelbaum <marcel.a@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com> Message-Id: <20171125151610.20547-7-ehabkost@redhat.com> Reviewed-by: Marcel Apfelbaum <marcel@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2018-01-19xen: Add only xen-sysdev to dynamic sysbus device listEduardo Habkost
There's no need to make the machine allow every possible sysbus device. We can now just add xen-sysdev to the allowed list. Cc: Stefano Stabellini <sstabellini@kernel.org> Cc: Anthony Perard <anthony.perard@citrix.com> Cc: xen-devel@lists.xenproject.org Cc: Juergen Gross <jgross@suse.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com> Message-Id: <20171125151610.20547-6-ehabkost@redhat.com> Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com> Acked-by: Anthony PERARD <anthony.perard@citrix.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2018-01-19spapr: Allow only supported dynamic sysbus devicesEduardo Habkost
TYPE_SPAPR_PCI_HOST_BRIDGE is the only dynamic sysbus device not rejected by ppc_spapr_reset(), so it can be the only entry on the allowed list. Cc: David Gibson <david@gibson.dropbear.id.au> Cc: Alexander Graf <agraf@suse.de> Cc: qemu-ppc@nongnu.org Signed-off-by: Eduardo Habkost <ehabkost@redhat.com> Message-Id: <20171125151610.20547-5-ehabkost@redhat.com> Acked-by: David Gibson <david@gibson.dropbear.id.au> Reviewed-by: Greg Kurz <groug@kaod.org> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2018-01-19ppc: e500: Allow only supported dynamic sysbus devicesEduardo Habkost
platform_bus_create_devtree() already rejects all dynamic sysbus devices except TYPE_ETSEC_COMMON, so register it as the only allowed dynamic sysbus device for the ppce500 machine-type. Cc: Alexander Graf <agraf@suse.de> Cc: David Gibson <david@gibson.dropbear.id.au> Cc: qemu-ppc@nongnu.org Signed-off-by: Eduardo Habkost <ehabkost@redhat.com> Message-Id: <20171125151610.20547-4-ehabkost@redhat.com> Acked-by: David Gibson <david@gibson.dropbear.id.au> Reviewed-by: Greg Kurz <groug@kaod.org> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2018-01-19hw/arm/virt: Allow only supported dynamic sysbus devicesEduardo Habkost
Replace the TYPE_SYS_BUS_DEVICE entry in the allowed sysbus device list with the two device types that are really supported by the virt machine: vfio-amd-xgbe and vfio-calxeda-xgmac. Cc: Peter Maydell <peter.maydell@linaro.org> Cc: qemu-arm@nongnu.org Signed-off-by: Eduardo Habkost <ehabkost@redhat.com> Message-Id: <20171125151610.20547-3-ehabkost@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2018-01-19machine: Replace has_dynamic_sysbus with list of allowed devicesEduardo Habkost
The existing has_dynamic_sysbus flag makes the machine accept every user-creatable sysbus device type on the command-line. Replace it with a list of allowed device types, so machines can easily accept some sysbus devices while rejecting others. To keep exactly the same behavior as before, the existing has_dynamic_sysbus=true assignments are replaced with a TYPE_SYS_BUS_DEVICE entry on the allowed list. Other patches will replace the TYPE_SYS_BUS_DEVICE entries with more specific lists of devices. Cc: Peter Maydell <peter.maydell@linaro.org> Cc: Marcel Apfelbaum <marcel@redhat.com> Cc: "Michael S. Tsirkin" <mst@redhat.com> Cc: Alexander Graf <agraf@suse.de> Cc: David Gibson <david@gibson.dropbear.id.au> Cc: Stefano Stabellini <sstabellini@kernel.org> Cc: Anthony Perard <anthony.perard@citrix.com> Cc: qemu-arm@nongnu.org Cc: qemu-ppc@nongnu.org Cc: xen-devel@lists.xenproject.org Signed-off-by: Eduardo Habkost <ehabkost@redhat.com> Message-Id: <20171125151610.20547-2-ehabkost@redhat.com> Reviewed-by: Greg Kurz <groug@kaod.org> Reviewed-by: David Gibson <david@gibson.dropbear.id.au> Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com> Reviewed-by: Marcel Apfelbaum <marcel@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2018-01-18vhost: remove assertion to prevent crashJay Zhou
QEMU will assert on vhost-user backed virtio device hotplug if QEMU is using more RAM regions than VHOST_MEMORY_MAX_NREGIONS (for example if it were started with a lot of DIMM devices). Fix it by returning error instead of asserting and let callers of vhost_set_mem_table() handle error condition gracefully. Cc: qemu-stable@nongnu.org Signed-off-by: Igor Mammedov <imammedo@redhat.com> Signed-off-by: Jay Zhou <jianjay.zhou@huawei.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2018-01-18vhost-user: fix misaligned access to payloadMichael S. Tsirkin
We currently take a pointer to a misaligned field of a packed structure. clang reports this as a build warning. A fix is to keep payload in a separate structure, and access is it from there using a vectored write. Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2018-01-18vhost-user: factor out msg head and payloadMichael S. Tsirkin
split header and payload into separate structures, to enable easier handling of alignment issues. Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2018-01-18x86_iommu: check if machine has PCI busMohammed Gamal
Starting qemu with qemu-system-x86_64 -S -M isapc -device {amd|intel}-iommu leads to a segfault. The code assume PCI bus is present and tries to access the bus structure without checking. Since Intel VT-d and AMDVI should only work with PCI, add a check for PCI bus and return error if not present. Reviewed-by: Peter Xu <peterx@redhat.com> Reviewed-by: Eduardo Habkost <ehabkost@redhat.com> Signed-off-by: Mohammed Gamal <mgamal@redhat.com> Reviewed-by: Thomas Huth <thuth@redhat.com>
2018-01-18x86_iommu: Move machine check to x86_iommu_realize()Mohammed Gamal
Instead of having the same error checks in vtd_realize() and amdvi_realize(), move that over to the generic x86_iommu_realize(). Reviewed-by: Peter Xu <peterx@redhat.com> Reviewed-by: Eduardo Habkost <ehabkost@redhat.com> Signed-off-by: Mohammed Gamal <mgamal@redhat.com> Reviewed-by: Thomas Huth <thuth@redhat.com>
2018-01-18hw/acpi-build: Make next_base easy to followDou Liyang
It may be hard to read the assignment statement of "next_base", so S/next_base += (1ULL << 32) - pcms->below_4g_mem_size; /next_base = mem_base + mem_len; ... for readability. No functionality change. Signed-off-by: Dou Liyang <douly.fnst@cn.fujitsu.com> Reviewed-by: Igor Mammedov <imammedo@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2018-01-18hw/pci-bridge: fix QEMU crash because of pcie-root-portMarcel Apfelbaum
If we try to use more pcie_root_ports then available slots and an IO hint is passed to the port, QEMU crashes because we try to init the "IO hint" capability even if the device is not created. Fix it by checking for error before adding the capability, so QEMU can fail gracefully. Signed-off-by: Marcel Apfelbaum <marcel@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2018-01-18intel-iommu: Extend address width to 48 bitsPrasad Singamsetty
The current implementation of Intel IOMMU code only supports 39 bits iova address width. This patch provides a new parameter (x-aw-bits) for intel-iommu to extend its address width to 48 bits but keeping the default the same (39 bits). The reason for not changing the default is to avoid potential compatibility problems with live migration of intel-iommu enabled QEMU guest. The only valid values for 'x-aw-bits' parameter are 39 and 48. After enabling larger address width (48), we should be able to map larger iova addresses in the guest. For example, a QEMU guest that is configured with large memory ( >=1TB ). To check whether 48 bits aw is enabled, we can grep in the guest dmesg output with line: "DMAR: Host address width 48". Signed-off-by: Prasad Singamsetty <prasad.singamsety@oracle.com> Reviewed-by: Peter Xu <peterx@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2018-01-18intel-iommu: Redefine macros to enable supporting 48 bit address widthPrasad Singamsetty
The current implementation of Intel IOMMU code only supports 39 bits host/iova address width so number of macros use hard coded values based on that. This patch is to redefine them so they can be used with variable address widths. This patch doesn't add any new functionality but enables adding support for 48 bit address width. Signed-off-by: Prasad Singamsetty <prasad.singamsety@oracle.com> Reviewed-by: Peter Xu <peterx@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2018-01-18pci/shpc: Move function to generic header fileYuval Shaia
This function should be declared in generic header file so we can utilize it. Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Signed-off-by: Yuval Shaia <yuval.shaia@oracle.com> Signed-off-by: Marcel Apfelbaum <marcel@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2018-01-18virtio: improve virtio devices initialization timeGal Hammer
The loading time of a VM is quite significant when its virtio devices use a large amount of virt-queues (e.g. a virtio-serial device with max_ports=511). Most of the time is spend in the creation of all the required event notifiers (ioeventfd and memory regions). This patch pack all the changes to the memory regions in a single memory transaction. Reported-by: Sitong Liu <siliu@redhat.com> Reported-by: Xiaoling Gao <xiagao@redhat.com> Signed-off-by: Gal Hammer <ghammer@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2018-01-18virtio: postpone the execution of event_notifier_cleanup functionGal Hammer
Use the EventNotifier's cleanup callback function to execute the event_notifier_cleanup function after kvm unregistered the eventfd. This change supports running the virtio_bus_set_host_notifier function inside a memory region transaction. Otherwise, a closed fd is sent to kvm, which results in a failure. Signed-off-by: Gal Hammer <ghammer@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2018-01-18vhost-user-blk: introduce a new vhost-user-blk host deviceChangpeng Liu
This commit introduces a new vhost-user device for block, it uses a chardev to connect with the backend, same with Qemu virito-blk device, Guest OS still uses the virtio-blk frontend driver. To use it, start QEMU with command line like this: qemu-system-x86_64 \ -chardev socket,id=char0,path=/path/vhost.socket \ -device vhost-user-blk-pci,chardev=char0,num-queues=2, \ bootindex=2... \ Users can use different parameters for `num-queues` and `bootindex`. Different with exist Qemu virtio-blk host device, it makes more easy for users to implement their own I/O processing logic, such as all user space I/O stack against hardware block device. It uses the new vhost messages(VHOST_USER_GET_CONFIG) to get block virtio config information from backend process. Signed-off-by: Changpeng Liu <changpeng.liu@intel.com> Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2018-01-18vhost-user: add new vhost user messages to support virtio config spaceChangpeng Liu
Add VHOST_USER_GET_CONFIG/VHOST_USER_SET_CONFIG messages which can be used for live migration of vhost user devices, also vhost user devices can benefit from the messages to get/set virtio config space from/to the I/O target. For the purpose to support virtio config space change, VHOST_USER_SLAVE_CONFIG_CHANGE_MSG message is added as the event notifier in case virtio config space change in the slave I/O target. Signed-off-by: Changpeng Liu <changpeng.liu@intel.com> Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2018-01-18Merge remote-tracking branch 'remotes/ehabkost/tags/x86-pull-request' into ↵Peter Maydell
staging x86 queue, 2018-01-17 Highlight: new CPU models that expose CPU features that guests can use to mitigate CVE-2017-5715 (Spectre variant #2). # gpg: Signature made Thu 18 Jan 2018 02:00:03 GMT # gpg: using RSA key 0x2807936F984DC5A6 # gpg: Good signature from "Eduardo Habkost <ehabkost@redhat.com>" # Primary key fingerprint: 5A32 2FD5 ABC4 D3DB ACCF D1AA 2807 936F 984D C5A6 * remotes/ehabkost/tags/x86-pull-request: i386: Add EPYC-IBPB CPU model i386: Add new -IBRS versions of Intel CPU models i386: Add FEAT_8000_0008_EBX CPUID feature word i386: Add spec-ctrl CPUID bit i386: Add support for SPEC_CTRL MSR i386: Change X86CPUDefinition::model_id to const char* target/i386: add clflushopt to "Skylake-Server" cpu model pc: add 2.12 machine types Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2018-01-17pc: add 2.12 machine typesHaozhong Zhang
Signed-off-by: Haozhong Zhang <haozhong.zhang@intel.com> Message-Id: <20171219033730.12748-2-haozhong.zhang@intel.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2018-01-17ppc/pnv: change initrd addressCédric Le Goater
When skiboot starts, it first clears the CPU structs for all possible CPUs on a system : for (i = 0; i <= cpu_max_pir; i++) memset(&cpu_stacks[i].cpu, 0, sizeof(struct cpu_thread)); On POWER9, cpu_max_pir is quite big, 0x7fff, and the skiboot cpu_stacks array overlaps with the memory region in which QEMU maps the initramfs file. Move it upwards in memory to keep it safe. Signed-off-by: Cédric Le Goater <clg@kaod.org> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2018-01-17ppc/pnv: fix XSCOM core addressing on POWER9Cédric Le Goater
The XSCOM base address of the core chiplet was wrongly calculated. Use the OPAL macros to fix that and do a couple of renames. Signed-off-by: Cédric Le Goater <clg@kaod.org> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2018-01-17ppc/pnv: introduce pnv*_is_power9() helpersCédric Le Goater
These are useful when instantiating device models which are shared between the POWER8 and the POWER9 processor families. Signed-off-by: Cédric Le Goater <clg@kaod.org> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2018-01-17ppc/pnv: change core mask for POWER9Cédric Le Goater
When addressed by XSCOM, the first core has the 0x20 chiplet ID but the CPU PIR can start at 0x0. Signed-off-by: Cédric Le Goater <clg@kaod.org> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2018-01-17ppc/pnv: use POWER9 DD2 processorCédric Le Goater
commit 1ed9c8af501f ("target/ppc: Add POWER9 DD2.0 model information") deprecated the POWER9 model v1.0. Signed-off-by: Cédric Le Goater <clg@kaod.org> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2018-01-17spapr: Adjust default VSMT value for better migration compatibilityDavid Gibson
fa98fbfc "PC: KVM: Support machine option to set VSMT mode" introduced the "vsmt" parameter for the pseries machine type, which controls the spacing of the vcpu ids of thread 0 for each virtual core. This was done to bring some consistency and stability to how that was done, while still allowing backwards compatibility for migration and otherwise. The default value we used for vsmt was set to the max of the host's advertised default number of threads and the number of vthreads per vcore in the guest. This was done to continue running without extra parameters on older KVM versions which don't allow the VSMT value to be changed. Unfortunately, even that smaller than before leakage of host configuration into guest visible configuration still breaks things. Specifically a guest with 4 (or less) vthread/vcore will get a different vsmt value when running on a POWER8 (vsmt==8) and POWER9 (vsmt==4) host. That means the vcpu ids don't line up so you can't migrate between them, though you should be able to. Long term we really want to make vsmt == smp_threads for sufficiently new machine types. However, that means that qemu will then require a sufficiently recent KVM (one which supports changing VSMT) - that's still not widely enough deployed to be really comfortable to do. In the meantime we need some default that will work as often as possible. This patch changes that default to 8 in all circumstances. This does change guest visible behaviour (including for existing machine versions) for many cases - just not the most common/important case. Following is case by case justification for why this is still the least worst option. Note that any of the old behaviours can still be duplicated after this patch, it's just that it requires manual intervention by setting the vsmt property on the command line. KVM HV on POWER8 host: This is the overwhelmingly common case in production setups, and is unchanged by design. POWER8 hosts will advertise a default VSMT mode of 8, and > 8 vthreads/vcore isn't permitted KVM HV on POWER7 host: Will break, but POWER7s allowing KVM were never released to the public. KVM HV on POWER9 host: Not yet released to the public, breaking this now will reduce other breakage later. KVM HV on PowerPC 970: Will theoretically break it, but it was barely supported to begin with and already required various user visible hacks to work. Also so old that I just don't care. TCG: This is the nastiest one; it means migration of TCG guests (without manual vsmt setting) will break. Since TCG is rarely used in production I think this is worth it for the other benefits. It does also remove one more barrier to TCG<->KVM migration which could be interesting for debugging applications. KVM PR: As with TCG, this will break migration of existing configurations, without adding extra manual vsmt options. As with TCG, it is rare in production so I think the benefits outweigh breakages. Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Reviewed-by: Laurent Vivier <lvivier@redhat.com> Reviewed-by: Jose Ricardo Ziviani <joserz@linux.vnet.ibm.com> Reviewed-by: Greg Kurz <groug@kaod.org>
2018-01-17spapr: Allow some cases where we can't set VSMT mode in the kernelDavid Gibson
At present if we require a vsmt mode that's not equal to the kernel's default, and the kernel doesn't let us change it (e.g. because it's an old kernel without support) then we always fail. But in fact we can cope with the kernel having a different vsmt as long as a) it's >= the actual number of vthreads/vcore (so that guest threads that are supposed to be on the same core act like it) b) it's a submultiple of the requested vsmt mode (so that guest threads spaced by the vsmt value will act like they're on different cores) Allowing this case gives us a bit more freedom to adjust the vsmt behaviour without breaking existing cases. Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Reviewed-by: Laurent Vivier <lvivier@redhat.com> Tested-by: Greg Kurz <groug@kaod.org> Reviewed-by: Greg Kurz <groug@kaod.org>
2018-01-17target/ppc: Clarify compat mode max_threads valueDavid Gibson
We recently had some discussions that were sidetracked for a while, because nearly everyone misapprehended the purpose of the 'max_threads' field in the compatiblity modes table. It's all about guest expectations, not host expectations or support (that's handled elsewhere). In an attempt to avoid a repeat of that confusion, rename the field to 'max_vthreads' and add an explanatory comment. Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Reviewed-by: Laurent Vivier <lvivier@redhat.com> Reviewed-by: Greg Kurz <groug@kaod.org> Reviewed-by: Jose Ricardo Ziviani <joserz@linux.vnet.ibm.com>
2018-01-17spapr: Remove unnecessary 'options' field from sPAPRCapabilityInfoDavid Gibson
The options field here is intended to list the available values for the capability. It's not used yet, because the existing capabilities are boolean. We're going to add capabilities that aren't, but in that case the info on the possible values can be folded into the .description field. Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2018-01-17hw/ppc/spapr_caps: Rework spapr_caps to use uint8 internal representationSuraj Jitindar Singh
Currently spapr_caps are tied to boolean values (on or off). This patch reworks the caps so that they can have any uint8 value. This allows more capabilities with various values to be represented in the same way internally. Capabilities are numbered in ascending order. The internal representation of capability values is an array of uint8s in the sPAPRMachineState, indexed by capability number. Capabilities can have their own name, description, options, getter and setter functions, type and allow functions. They also each have their own section in the migration stream. Capabilities are only migrated if they were explictly set on the command line, with the assumption that otherwise the default will match. On migration we ensure that the capability value on the destination is greater than or equal to the capability value from the source. So long at this remains the case then the migration is considered compatible and allowed to continue. This patch implements generic getter and setter functions for boolean capabilities. It also converts the existings cap-htm, cap-vsx and cap-dfp capabilities to this new format. Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2018-01-17spapr: Handle Decimal Floating Point (DFP) as an optional capabilityDavid Gibson
Decimal Floating Point has been available on POWER7 and later (server) cpus. However, it can be disabled on the hypervisor, meaning that it's not available to guests. We currently handle this by conditionally advertising DFP support in the device tree depending on whether the guest CPU model supports it - which can also depend on what's allowed in the host for -cpu host. That can lead to confusion on migration, since host properties are silently affecting guest visible properties. This patch handles it by treating it as an optional capability for the pseries machine type. Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Reviewed-by: Greg Kurz <groug@kaod.org>
2018-01-17spapr: Handle VMX/VSX presence as an spapr capability flagDavid Gibson
We currently have some conditionals in the spapr device tree code to decide whether or not to advertise the availability of the VMX (aka Altivec) and VSX vector extensions to the guest, based on whether the guest cpu has those features. This can lead to confusion and subtle failures on migration, since it makes a guest visible change based only on host capabilities. We now have a better mechanism for this, in spapr capabilities flags, which explicitly depend on user options rather than host capabilities. Rework the advertisement of VSX and VMX based on a new VSX capability. We no longer bother with a conditional for VMX support, because every CPU that's ever been supported by the pseries machine type supports VMX. NOTE: Some userspace distributions (e.g. RHEL7.4) already rely on availability of VSX in libc, so using cap-vsx=off may lead to a fatal SIGILL in init. Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Reviewed-by: Greg Kurz <groug@kaod.org>
generated by cgit v1.2.3 (git 2.26.2) at 2025-02-11 01:59:43 +0000