aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2016-07-11Merge remote-tracking branch 'remotes/rth/tags/pull-rth-20160710' into stagingPeter Maydell4-26/+13
build fix for travis # gpg: Signature made Sun 10 Jul 2016 18:07:02 BST # gpg: using RSA key 0xAD1270CC4DD0279B # gpg: Good signature from "Richard Henderson <rth7680@gmail.com>" # gpg: aka "Richard Henderson <rth@redhat.com>" # gpg: aka "Richard Henderson <rth@twiddle.net>" # Primary key fingerprint: 9CB1 8DDA F8E8 49AD 2AFC 16A4 AD12 70CC 4DD0 279B * remotes/rth/tags/pull-rth-20160710: build: Use $(AS) for optionrom explicitly linux-user: Fix i386 safe-syscall.S Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2016-07-11gtk: fix buildGerd Hoffmann2-0/+2
Commit "9d8256e virgl: pass whole GL scanout dimensions" missed the opengl code path for gtk versions >= 3.16. Update that one too and fix the build with recent gtk versions. Reported-by: Dr. David Alan Gilbert <dgilbert@redhat.com> Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Message-id: 1467876563-1351-1-git-send-email-kraxel@redhat.com Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2016-07-11s390x/pci: make hot-unplug handler smootherYi Min Zhao2-1/+37
The current implementation of hot-unplug handler is abrupt. Any pci operation will be just rejected if pci device is unconfigured. Thus a pci device can not be reset or destroyed in a right, smooth and safe way. Improve this as follows: - Notify the guest via a HP_EVENT_DECONFIGURE_REQUEST(0x303) event in the unplug handler, giving it a chance to deconfigure the device via sclp and allowing us to continue hot-unplug afterwards. - Set up a timer that will generate the HP_EVENT_CONFIGURE_TO_STBRES (0x304) event as before if the guest did not react after an adequate time. Signed-off-by: Yi Min Zhao <zyimin@linux.vnet.ibm.com> Reviewed-by: Pierre Morel <pmorel@linux.vnet.ibm.com> Signed-off-by: Cornelia Huck <cornelia.huck@de.ibm.com>
2016-07-11s390x/pci: replace fid with idx in msg data of msixYi Min Zhao3-7/+8
Present code uses fid as the part of message data of msix for looking up the specific zpci device. However it limits the usable range of fid, and the code looking up the zpci device may fail due to truncation of the fid. In addition, fh is composed of enabled bit, FH_VIRT and the array index. So we can use the array index as the identifier to store in msg data. Signed-off-by: Yi Min Zhao <zyimin@linux.vnet.ibm.com> Reviewed-by: Pierre Morel <pmorel@linux.vnet.ibm.com> Signed-off-by: Cornelia Huck <cornelia.huck@de.ibm.com>
2016-07-11s390x/pci: fix stpcifc_service_callYi Min Zhao1-1/+9
Firstly the function misses dmaas checking. This patch adds it. Secondly the function uses s390_pci_find_dev_by_fh() to look up the zpci device. This may fail if the guest provides a valid and disabled fh but fh of the associated zpci device is enabled. Thus we use s390_pci_find_dev_by_idx() instead. Signed-off-by: Yi Min Zhao <zyimin@linux.vnet.ibm.com> Reviewed-by: Pierre Morel <pmorel@linux.vnet.ibm.com> Signed-off-by: Cornelia Huck <cornelia.huck@de.ibm.com>
2016-07-11s390x/pci: refactor list_pciYi Min Zhao3-26/+45
Because of the refactor of s390_pci_find_dev_by_idx(), list_pci() should be updated. We introduce a new function to get the next available zpci device. It simplifies the code of looking up zpci devices. Signed-off-by: Yi Min Zhao <zyimin@linux.vnet.ibm.com> Acked-by: Pierre Morel <pmorel@linux.vnet.ibm.com> Signed-off-by: Cornelia Huck <cornelia.huck@de.ibm.com>
2016-07-11s390x/pci: refactor s390_pci_find_dev_by_idxYi Min Zhao1-20/+1
s390_find_dev_by_idx() only indexes usable zpci devices. It implies that the index value of each zpci device is dynamic and may change if a new zpci device is plugged. So we have to use a constant index to look up the device. Signed-off-by: Yi Min Zhao <zyimin@linux.vnet.ibm.com> Reviewed-by: Pierre Morel <pmorel@linux.vnet.ibm.com> Signed-off-by: Cornelia Huck <cornelia.huck@de.ibm.com>
2016-07-11s390x/pci: add checkings in CLP_SET_PCI_FNYi Min Zhao1-0/+21
The code in CLP_SET_PCI_FN case misses some checkings. Let's add them. Signed-off-by: Yi Min Zhao <zyimin@linux.vnet.ibm.com> Reviewed-by: Pierre Morel <pmorel@linux.vnet.ibm.com> Signed-off-by: Cornelia Huck <cornelia.huck@de.ibm.com>
2016-07-11s390x/pci: enable zpci hot-plug/hot-unplugYi Min Zhao1-46/+73
We need to support hot-plug/hot-unplug for the new zpci devices as well. This patch enables the present hot-plug/hot-unplug handlers to support not only generic pci devices but also zpci devices. Signed-off-by: Yi Min Zhao <zyimin@linux.vnet.ibm.com> Reviewed-by: Pierre Morel <pmorel@linux.vnet.ibm.com> Signed-off-by: Cornelia Huck <cornelia.huck@de.ibm.com>
2016-07-11s390x/pci: enable uid-checkingYi Min Zhao3-5/+5
The uid-checking facility guarantees uniqueness of the uid within the vm and exposes the real uid to the guest when listing pci devices. Let's always enable it and present it to the guest in the response to the list pci clp command. Signed-off-by: Yi Min Zhao <zyimin@linux.vnet.ibm.com> Reviewed-by: Pierre Morel <pmorel@linux.vnet.ibm.com> Signed-off-by: Cornelia Huck <cornelia.huck@de.ibm.com>
2016-07-11s390x/pci: introduce S390PCIBusDevice qdevYi Min Zhao2-8/+261
To support definitions of s390 pci attributes in Qemu cmdline, we have to make current S390PCIBusDevice struct inherit DeviceState and add three properties for it. Currently we only support definitions of uid and fid. 'uid' is optionally defined by users, identifies a zpci device and must be defined with a 16-bit and non-zero unique value. 'fid' ranges from 0x0 to 0xFFFFFFFF. For fid property, we introduce a new PropertyInfo by the name of s390_pci_fid_propinfo with our special setter and getter. As 'fid' is optional, introduce 'fid_defined' to track whether the user specified a fid. 'target' field is to direct qemu to find the corresponding generic PCI device. It is equal to the 'id' value of one of generic pci devices. If the user doesn't specify 'id' parameter for a generic pci device, its 'id' value will be generated automatically and use this value as 'target' to create an associated zpci device. If the user did not specify 'uid' or 'fid', values are generated automatically. 'target' is required. In addition, if a pci device has no associated zpci device, the code will generate a zpci device automatically for it. Signed-off-by: Yi Min Zhao <zyimin@linux.vnet.ibm.com> Reviewed-by: Pierre Morel <pmorel@linux.vnet.ibm.com> Signed-off-by: Cornelia Huck <cornelia.huck@de.ibm.com>
2016-07-11s390x/pci: introduce S390PCIIOMMUYi Min Zhao2-10/+18
Currently each zpci device holds its own DMA address space and memory region. At the same time, all instances of zpci device are stored in S390pciState. So duirng the initialization of S390pciState, all zpci devices are created and then all DMA address spaces are created. Thus, when initializing pci devices, their corresponding DMA address spaces could be found. But zpci qdev will be introduced later. Zpci device may be initialized and plugged afterwards generic pci device. So we should initialize all DMA address spaces and memory regions before initializing zpci devices. We introduce a new struct named S390PCIIOMMU. And a new field of S390pciState, which is an array to store all instances of S390PCIIOMMU, is added so that qemu pci code could find the corresponding DMA address space when initializing a generic pci device. And this should be done before the connection of a zpci device and a generic pci device is built. Signed-off-by: Yi Min Zhao <zyimin@linux.vnet.ibm.com> Acked-by: Pierre Morel <pmorel@linux.vnet.ibm.com> Signed-off-by: Cornelia Huck <cornelia.huck@de.ibm.com>
2016-07-11s390x/pci: introduce S390PCIBusYi Min Zhao2-0/+18
To enable S390PCIBusDevice as qdev, there should be a new bus to plug and manage all instances of S390PCIBusDevice. Due to this, S390PCIBus is introduced. Signed-off-by: Yi Min Zhao <zyimin@linux.vnet.ibm.com> Reviewed-by: Pierre Morel <pmorel@linux.vnet.ibm.com> Signed-off-by: Cornelia Huck <cornelia.huck@de.ibm.com>
2016-07-11s390x/pci: enforce zPCI state checkingYi Min Zhao5-82/+230
Current code uses some fields combinatorially to indicate the state of a s390 pci device. This patch introduces device states in order to make the code more readable and more logical. Signed-off-by: Yi Min Zhao <zyimin@linux.vnet.ibm.com> Reviewed-by: Pierre Morel <pmorel@linux.vnet.ibm.com> Signed-off-by: Cornelia Huck <cornelia.huck@de.ibm.com>
2016-07-11s390x/pci: refactor s390_pci_find_dev_by_fhYi Min Zhao1-11/+4
Because this function is called very frequently, we should use a more effective way to find the zpci device. So we use the FH's index to get the device directly. Signed-off-by: Yi Min Zhao <zyimin@linux.vnet.ibm.com> Reviewed-by: Pierre Morel <pmorel@linux.vnet.ibm.com> Signed-off-by: Cornelia Huck <cornelia.huck@de.ibm.com>
2016-07-11s390x/pci: unify FH_ macrosYi Min Zhao3-15/+18
Present code uses some macros to structure PCI Function Handle. But their names don't have a uniform format. Let's use FH_MASK_ as the unified prefix. While we're at it, differentiate the SHM bits: use different bits for vfio and emulated devices. Signed-off-by: Yi Min Zhao <zyimin@linux.vnet.ibm.com> Reviewed-by: Pierre Morel <pmorel@linux.vnet.ibm.com> Signed-off-by: Cornelia Huck <cornelia.huck@de.ibm.com>
2016-07-11s390x/pci: write fid in CLP_QUERY_PCI_FNYi Min Zhao1-0/+1
We forgot to write the fid; fix that. Signed-off-by: Yi Min Zhao <zyimin@linux.vnet.ibm.com> Acked-by: Pierre Morel <pmorel@linux.vnet.ibm.com> Signed-off-by: Cornelia Huck <cornelia.huck@de.ibm.com>
2016-07-11s390x/pci: acceleration for getting S390pciStateYi Min Zhao1-33/+20
There are a number of places where the code needs to get the instance of S390pciState. It calls object_resolve_path() every time. This wastes a lot of time and leads to low performance. Thus we add s390_get_phb() to improve it. Because we always have a phb, we remove all return checkings in the callers and add an assert in s390_get_phb() to make sure that phb is getted successfully. Signed-off-by: Yi Min Zhao <zyimin@linux.vnet.ibm.com> Reviewed-by: Pierre Morel <pmorel@linux.vnet.ibm.com> Signed-off-by: Cornelia Huck <cornelia.huck@de.ibm.com>
2016-07-11s390x/pci: fix failures of dma map/unmapYi Min Zhao1-4/+2
In commit d78c19b5cf4821d0c198f4132a085bdbf19dda4c, vfio code stores the IOMMU's offset_within_address_space and adjusts the IOVA before calling vfio_dma_map/vfio_dma_unmap. But s390_translate_iommu already considers the base address of an IOMMU memory region. Thus we use pal as the size and 0x0 as the base address to initialize IOMMU memory subregion. Signed-off-by: Yi Min Zhao <zyimin@linux.vnet.ibm.com> Reviewed-by: Pierre Morel <pmorel@linux.vnet.ibm.com> Signed-off-by: Cornelia Huck <cornelia.huck@de.ibm.com>
2016-07-11s390x/css: Unplug handler of virtual css bridgeJing Liu7-57/+164
The previous patch moved virtual css bridge and bus out from virtio-ccw, but kept the direct reference of virtio-ccw specific unplug function inside css-bridge.c. To make the virtual css bus and bridge useful for non-virtio devices, this introduces a common unplug function pointer "unplug" to call specific virtio-ccw unplug parts. Thus, the tight coupling to virtio-ccw can be removed. This unplug pointer is a member of CCWDeviceClass, which is introduced as an abstract device layer called "ccw-device". This layer is between DeviceState and specific devices which are plugged in virtual css bus, like virtio-ccw device. The specific unplug handlers should be assigned to "unplug" during initialization. Signed-off-by: Jing Liu <liujbjl@linux.vnet.ibm.com> Reviewed-by: Sascha Silbe <silbe@linux.vnet.ibm.com> Reviewed-by: Dong Jia Shi <bjsdjshi@linux.vnet.ibm.com> Reviewed-by: Yi Min Zhao <zyimin@linux.vnet.ibm.com> Signed-off-by: Cornelia Huck <cornelia.huck@de.ibm.com>
2016-07-11s390x/css: Factor out virtual css bridge and busJing Liu6-88/+127
Currently, common base layers virtual css bridge and bus are defined in hw/s390x/virtio-ccw.c(h). In order to support multiple types of devices in the virtual channel subsystem, especially non virtio-ccw, refactoring work needs to be done. This work is just a pure code move without any functional change except dropping an empty function virtual_css_bridge_init() and virtio_ccw_busdev_unplug() changing. virtio_ccw_busdev_unplug() is specific to virtio-ccw but gets referenced from the common virtual css bridge code. To keep the functional changes to a minimum we export this function from virtio-ccw.c and continue to reference it inside virtual_css_bridge_class_init() (now living in hw/s390x/css-bridge.c). A follow-up patch will clean this up. Signed-off-by: Jing Liu <liujbjl@linux.vnet.ibm.com> Reviewed-by: Sascha Silbe <silbe@linux.vnet.ibm.com> Reviewed-by: Dong Jia Shi <bjsdjshi@linux.vnet.ibm.com> Signed-off-by: Cornelia Huck <cornelia.huck@de.ibm.com>
2016-07-11s390x/css: use define for "virtual-css-bridge" literalSascha Silbe3-3/+6
Introduce a TYPE_* define (like we already use for a couple of other QOM types) for the name of the virtual CSS bridge QOM type instead of sprinkling the same string literal over several source files. Signed-off-by: Sascha Silbe <silbe@linux.vnet.ibm.com> Signed-off-by: Cornelia Huck <cornelia.huck@de.ibm.com>
2016-07-11s390x/css: factor out some generic code from virtio_ccw_device_realize()Sascha Silbe4-110/+175
A lot of what virtio_ccw_device_realize() does isn't specific to virtio; it would apply to emulated CCW as well. Factor it out to make it easier to implement emulated CCW devices later on. Signed-off-by: Sascha Silbe <silbe@linux.vnet.ibm.com> Reviewed-by: Dong Jia Shi <bjsdjshi@linux.vnet.ibm.com> Reviewed-by: Halil Pasic <pasic@linux.vnet.ibm.com> Signed-off-by: Cornelia Huck <cornelia.huck@de.ibm.com>
2016-07-11s390x/ipl: fix reboots for migration from different biosDavid Hildenbrand2-2/+11
When migrating from a different QEMU version, the start_address and bios_start_address may differ. During migration these values are migrated and overwrite the values that were detected by QEMU itself. On a reboot, QEMU will reload its own BIOS, but use the migrated start addresses, which does not work if the values differ. Fix this by not relying on the migrated values anymore, but still provide them during migration, so existing QEMUs continue to work. Signed-off-by: David Hildenbrand <dahi@linux.vnet.ibm.com> Cc: qemu-stable@nongnu.org Signed-off-by: Cornelia Huck <cornelia.huck@de.ibm.com>
2016-07-11s390x/ipl: Support IPL from selected SCSI deviceAlexander Yarygin2-0/+31
If bootindex is specified for a device, we need to IPL from it. Currently it works for ccw devices, but not for SCSI. To be able to IPL from the specific device, pc-bios needs to know its address. For this reason we add special QEMU_SCSI IPL type into the IPLB structure, that contains the scsi device address. We enhance the ipl block with a currently qemu-only parameter block that allows us to specify a concrete scsi device. Signed-off-by: Alexander Yarygin <yarygin@linux.vnet.ibm.com> Reviewed-by: Eric Farman <farman@linux.vnet.ibm.com> Signed-off-by: Cornelia Huck <cornelia.huck@de.ibm.com>
2016-07-11pc-bios/s390-ccw.img: rebuild imageCornelia Huck1-0/+0
Contains: - pc-bios/s390-ccw: Pass selected SCSI device to IPL Signed-off-by: Cornelia Huck <cornelia.huck@de.ibm.com>
2016-07-11pc-bios/s390-ccw: Pass selected SCSI device to IPLEugene (jno) Dvurechenski4-0/+37
There is ,bootindex=%d argument to specify the lookup order of boot devices. If a bootindex assigned to the device, then IPL Parameter Info Block is created for that device when it is IPLed from. If it is a mere SCSI device (not FCP), then IPIB is created with a special SCSI type and its fields are used to store SCSI address of the device. This new ipl block is private to qemu for now. If the device to IPL from is specified this way, then SCSI bus lookup is bypassed and prescribed devices uses the address specified. Signed-off-by: Eugene (jno) Dvurechenski <jno@linux.vnet.ibm.com> Signed-off-by: Alexander Yarygin <yarygin@linux.vnet.ibm.com> Signed-off-by: Cornelia Huck <cornelia.huck@de.ibm.com>
2016-07-10build: Use $(AS) for optionrom explicitlyRichard Henderson3-8/+7
For clang before 3.5, -fno-integrated-as does not exist, so the workaround in 5f6f0e27fb24 fails to build. Use clang's default assembler for linux-user/safe-syscall.S, and explicitly change to use the system assembler for the option roms. Tested-by: Alex Bennée <alex.bennee@linaro.org> Reviewed-by: Alex Bennée <alex.bennee@linaro.org> Signed-off-by: Richard Henderson <rth@twiddle.net>
2016-07-08translate-all: Fix user-mode self-modifying code in 2 page long TBStanislav Shmarov1-5/+5
In user-mode emulation Translation Block can consist of 2 guest pages. In that case QEMU also mprotects 2 host pages that are dedicated for guest memory, containing instructions. QEMU detects self-modifying code with SEGFAULT signal processing. In case if instruction in 1st page is modifying memory of 2nd page (or vice versa) QEMU will mark 2nd page with PAGE_WRITE, invalidate TB, generate new TB contatining 1 guest instruction and exit to CPU loop. QEMU won't call mprotect, and new TB will cause same SEGFAULT. Page will have both PAGE_WRITE_ORG and PAGE_WRITE flags, so QEMU will handle the signal as guest binary problem, and exit with guest SEGFAULT. Solution is to do following: In case if current TB was invalidated continue to invalidate TBs from remaining guest pages and mark pages as PAGE_WRITE. After that disable host page protection with mprotect. If current tb was invalidated longjmp to main loop. That is more efficient, since we won't get SEGFAULT when executing new TB. Reviewed-by: Sergey Fedorov <sergey.fedorov@linaro.org> Signed-off-by: Stanislav Shmarov <snarpix@gmail.com> Message-Id: <1467880392-1043630-1-git-send-email-snarpix@gmail.com> Signed-off-by: Richard Henderson <rth@twiddle.net>
2016-07-08cputlb: Fix for self-modifying writes across page boundariesSamuel Damashek1-9/+35
As it currently stands, QEMU does not properly handle self-modifying code when the write is unaligned and crosses a page boundary. The procedure for handling a write to the current translation block is to write-protect the current translation block, catch the write, split up the translation block into the current instruction (which remains write-protected so that the current instruction is not modified) and the remaining instructions in the translation block, and then restore the CPU state to before the write occurred so the write will be retried and successfully executed. However, since unaligned writes across pages are split into one-byte writes for simplicity, writes to the second page (which is not the current TB) may succeed before a write to the current TB is attempted, and since these writes are not invalidated before resuming state after splitting the TB, these writes will be performed a second time, thus corrupting the second page. Credit goes to Patrick Hulin for discovering this. In recent 64-bit versions of Windows running in emulated mode, this results in either being very unstable (a BSOD after a couple minutes of uptime), or being entirely unable to boot. Windows performs one or more 8-byte unaligned self-modifying writes (xors) which intersect the end of the current TB and the beginning of the next TB, which runs into the aforementioned issue. This commit fixes that issue by making the unaligned write loop perform the writes in forwards order, instead of reverse order. This way, QEMU immediately tries to write to the current TB, and splits the TB before any write to the second page is executed. The write then proceeds as intended. With this patch applied, I am able to boot and use Windows 7 64-bit and Windows 10 64-bit in QEMU without KVM. Per Richard Henderson's input, this patch also ensures the second page is in the TLB before executing the write loop, to ensure the second page is mapped. The original discussion of the issue is located at http://lists.nongnu.org/archive/html/qemu-devel/2014-08/msg02161.html. Signed-off-by: Samuel Damashek <samuel.damashek@invincea.com> Message-Id: <20160706182652.16190-1-samuel.damashek@invincea.com> Signed-off-by: Richard Henderson <rth@twiddle.net>
2016-07-08cputlb: Add address parameter to VICTIM_TLB_HITSamuel Damashek2-7/+7
[rth: Split out from the original patch.] Signed-off-by: Samuel Damashek <samuel.damashek@invincea.com> Message-Id: <20160706182652.16190-1-samuel.damashek@invincea.com> Signed-off-by: Richard Henderson <rth@twiddle.net>
2016-07-08cputlb: Move VICTIM_TLB_HIT out of lineRichard Henderson2-25/+29
There are currently 22 invocations of this function, and we're about to increase that number. Signed-off-by: Richard Henderson <rth@twiddle.net>
2016-07-07linux-user: Fix i386 safe-syscall.SRichard Henderson1-18/+6
Clang insists that "cmp" is ambiguous with a memory destination, requiring an explicit size suffix. There was a true error in the use of .cfi_def_cfa_offset in the epilogue, but changing to use the proper .cfi_adjust_cfa_offset runs afoul of a clang bug wrt .cfi_restore_state. Better to fold the two epilogues so that we don't trigger the bug. Signed-off-by: Richard Henderson <rth@twiddle.net>
2016-07-07target-i386: Enable LMCE for '-cpu host' if supported by hostHaozhong Zhang1-0/+15
If -cpu host is used, LMCE will be automatically enabled when it's supported by host. Signed-off-by: Haozhong Zhang <haozhong.zhang@intel.com> Reviewed-by: Eduardo Habkost <ehabkost@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2016-07-07target-i386: Publish advised value of MSR_IA32_FEATURE_CONTROL via fw_cfgHaozhong Zhang2-0/+33
It's a prerequisite that certain bits of MSR_IA32_FEATURE_CONTROL should be set before some features (e.g. VMX and LMCE) can be used, which is usually done by the firmware. This patch adds a fw_cfg file "etc/msr_feature_control" which contains the advised value of MSR_IA32_FEATURE_CONTROL and can be used by guest firmware (e.g. SeaBIOS). Suggested-by: Paolo Bonzini <pbonzini@redhat.com> Signed-off-by: Haozhong Zhang <haozhong.zhang@intel.com> Reviewed-by: Paolo Bonzini <pbonzini@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2016-07-07target-i386: kvm: Add basic Intel LMCE supportAshok Raj4-4/+67
This patch adds the support to inject SRAR and SRAO as LMCE, i.e. they are injected to only one VCPU rather than broadcast to all VCPUs. As KVM reports LMCE support on Intel platforms, this features is only available on Intel platforms. LMCE is disabled by default and can be enabled/disabled by cpu option 'lmce=on/off'. Signed-off-by: Ashok Raj <ashok.raj@intel.com> [Haozhong: Enable LMCE only on Intel platforms Disable LMCE by default and add a cpu option 'lmce' Handle the error if LMCE is enabled w/o host support Remove MCG_LMCE_P from MCE_CAP_DEF Add migration support for LMCE Minor code style changes] Signed-off-by: Haozhong Zhang <haozhong.zhang@intel.com> Reviewed-by: Eduardo Habkost <ehabkost@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2016-07-07target-i386: Report hyperv feature words through qomEvgeny Yakovlev3-48/+120
This change adds hyperv feature words report through qom rpc. When VM is configured with hyperv features enabled libvirt will check that required feature words are set in cpuid leaf 40000003 through qom request. Currently qemu does not report hyperv feature words which prevents windows guests from starting with libvirt. To avoid conflicting with current hyperv properties all added feature words cannot be set directly with -cpu +feature yet. Signed-off-by: Evgeny Yakovlev <eyakovlev@virtuozzo.com> Signed-off-by: Denis V. Lunev <den@openvz.org> CC: Paolo Bonzini <pbonzini@redhat.com> CC: Richard Henderson <rth@twiddle.net> CC: Eduardo Habkost <ehabkost@redhat.com> CC: Marcelo Tosatti <mtosatti@redhat.com> Reviewed-by: Eduardo Habkost <ehabkost@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2016-07-07target-i386: Show host and VM TSC frequencies on mismatchEduardo Habkost1-1/+3
Improve the TSC frequency mismatch warning to show the host and VM TSC frequencies. Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com> Reviewed-by: Marcelo Tosatti <mtosatti@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2016-07-07pc: Parse CPU features only onceIgor Mammedov4-55/+28
Considering that features are converted to global properties and global properties are automatically applied to every new instance of created CPU (at object_new() time), there is no point in parsing cpu_model string every time a CPU created. So move parsing outside CPU creation loop and do it only once. Parsing also should be done before any CPU is created so that features would affect the first CPU a well. Signed-off-by: Igor Mammedov <imammedo@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2016-07-07arm: virt: Parse cpu_model only onceIgor Mammedov2-22/+21
Considering that features are converted to global properties and global properties are automatically applied to every new instance of created CPU (at object_new() time), there is no point in parsing cpu_model string every time a CPU created. So move parsing outside CPU creation loop and do it only once. Parsing also should be done before any CPU is created so that features would affect the first CPU a well. Signed-off-by: Igor Mammedov <imammedo@redhat.com> Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2016-07-07cpu: Use CPUClass->parse_features() as convertor to global propertiesIgor Mammedov4-22/+54
Currently CPUClass->parse_features() is used to parse -cpu features string and set properties on created CPU instances. But considering that features specified by -cpu apply to every created CPU instance, it doesn't make sense to parse the same features string for every CPU created. It also makes every target that cares about parsing features string explicitly call CPUClass->parse_features() parser, which gets in a way if we consider using generic device_add for CPU hotplug as device_add has not a clue about CPU specific hooks. Turns out we can use global properties mechanism to set properties on every created CPU instance for a given type. That way it's possible to convert CPU features into a set of global properties for CPU type specified by -cpu cpu_model and common Device.device_post_init() will apply them to CPU of given type automatically regardless whether it's manually created CPU or CPU created with help of device_add. Signed-off-by: Igor Mammedov <imammedo@redhat.com> Reviewed-by: Eduardo Habkost <ehabkost@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2016-07-07target-i386: Avoid using locals outside their scopePaolo Bonzini1-1/+1
x86_cpu_parse_featurestr has a "val = num;" assignment just before num goes out of scope. Push num up to fix the issue. Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Reviewed-by: Igor Mammedov <imammedo@redhat.com> Reviewed-by: Eduardo Habkost <ehabkost@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2016-07-07target-i386: TCG can support CPUID.07H:EBX.ermsPaolo Bonzini1-2/+3
ERMS just says "rep movsb" and "rep stosb" are fast. It does not imply any new instruction, so we can support it easily. Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Reviewed-by: Eduardo Habkost <ehabkost@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2016-07-07target-sparc: Use sparc_cpu_parse_features() directlyIgor Mammedov1-3/+4
Make SPARC target use sparc_cpu_parse_features() directly so it won't get in the way of switching other propertified targets to handling features as global properties. Signed-off-by: Igor Mammedov <imammedo@redhat.com> Reviewed-by: Eduardo Habkost <ehabkost@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2016-07-07vl: Set errp to &error_abort on machine compat_propsEduardo Habkost1-0/+2
Use the new GlobalProperty.errp field to handle compat_props errors. Example output before this change: (with an intentionally broken entry added to PC_COMPAT_1_3 just for testing) $ qemu-system-x86_64 -machine pc-1.3 qemu-system-x86_64: hw/core/qdev-properties.c:1091: qdev_prop_set_globals_for_type: Assertion `prop->user_provided' failed. Aborted (core dumped) After: $ qemu-system-x86_64 -machine pc-1.3 Unexpected error in x86_cpuid_set_vendor() at /home/ehabkost/rh/proj/virt/qemu/target-i386/cpu.c:1688: qemu-system-x86_64: can't apply global cpu.vendor=x: Property '.vendor' doesn't take value 'x' Aborted (core dumped) Suggested-by: Paolo Bonzini <pbonzini@redhat.com> Reviewed-by: Marcel Apfelbaum <marcel@redhat.com> Reviewed-by: Markus Armbruster <armbru@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2016-07-07machine: Add machine_register_compat_props() functionEduardo Habkost3-7/+19
Move the compat_props handling to core machine code. Reviewed-by: Marcel Apfelbaum <marcel@redhat.com> Reviewed-by: Markus Armbruster <armbru@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2016-07-07qdev: GlobalProperty.errp fieldEduardo Habkost2-3/+12
The new field will allow error handling to be configured by qdev_prop_register_global() callers: &error_fatal and &error_abort can be used to make QEMU exit or abort if any errors are reported when applying the properties. While doing it, change the error message from "global %s.%s=%s ignored" to "can't apply global %s.%s=%s". Suggested-by: Paolo Bonzini <pbonzini@redhat.com> Reviewed-by: Igor Mammedov <imammedo@redhat.com> Reviewed-by: Markus Armbruster <armbru@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2016-07-07qdev: Eliminate qemu_add_globals() functionEduardo Habkost3-22/+16
The function is just a helper to handle the -global options, it can stay in vl.c like most qemu_opts_foreach() calls. Reviewed-by: Igor Mammedov <imammedo@redhat.com> Reviewed-by: Markus Armbruster <armbru@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2016-07-07qdev: Don't stop applying globals on first errorEduardo Habkost1-1/+0
qdev_prop_set_globals_for_type() stops applying global properties on the first error. It is a leftover from when QEMU exited on any error when applying global property. Commit 25f8dd9 changed the fatal error to a warning, but neglected to drop the stopping. Fix that. For example, the following command-line will not set CPUID level to 3, but will warn only about "x86_64-cpu.vendor" being ignored. $ ./x86_64-softmmu/qemu-system-x86_64 \ -global x86_64-cpu.vendor=x \ -global x86_64-cpu.level=3 qemu-system-x86_64: Warning: global x86_64-cpu.vendor=x ignored: Property '.vendor' doesn't take value 'x' Fix this by not returning from qdev_prop_set_globals_for_type() on the first error. Cc: Markus Armbruster <armbru@redhat.com> Reviewed-by: Markus Armbruster <armbru@redhat.com> Reviewed-by: Marcel Apfelbaum <marcel@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2016-07-07Merge remote-tracking branch ↵Peter Maydell15-30/+107
'remotes/pmaydell/tags/pull-target-arm-20160707' into staging target-arm queue: * fix a wrong variable type for A64 SYS_HEAPINFO semihosting call * xlnx_dp: fix iffy xlnx_dp_aux_push_tx_fifo * aux: fix break that wanted to break two levels out * aux: Rename aux.[ch] to auxbus.[ch] for the benefit of Windows * hw/block/m25p80: fix resource leak * i.MX: split the GPT timer implementation into per SOC definitions # gpg: Signature made Thu 07 Jul 2016 14:48:09 BST # gpg: using RSA key 0x3C2525ED14360CDE # gpg: Good signature from "Peter Maydell <peter.maydell@linaro.org>" # gpg: aka "Peter Maydell <pmaydell@gmail.com>" # gpg: aka "Peter Maydell <pmaydell@chiark.greenend.org.uk>" # Primary key fingerprint: E1A5 C593 CD41 9DE2 8E83 15CF 3C25 25ED 1436 0CDE * remotes/pmaydell/tags/pull-target-arm-20160707: i.MX: split the GPT timer implementation into per SOC definitions hw/block/m25p80: fix resource leak aux: Rename aux.[ch] to auxbus.[ch] for the benefit of Windows aux: fix break that wanted to break two levels out xlnx_dp: fix iffy xlnx_dp_aux_push_tx_fifo target-arm/arm-semi.c: In SYS_HEAPINFO use correct type for 'limit' Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
generated by cgit v1.1 at 2024-11-20 01:05:20 +0000