aboutsummaryrefslogtreecommitdiff
path: root/target/i386
AgeCommit message (Collapse)Author
2020-06-10target/i386: Fix OUTL debug outputPhilippe Mathieu-Daudé
Fix OUTL instructions incorrectly displayed as OUTW. Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-Id: <20200517110147.26026-1-f4bug@amsat.org> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-06-09target/i386/cpu: Use the IEC binary prefix definitionsPhilippe Mathieu-Daudé
IEC binary prefixes ease code review: the unit is explicit. Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-Id: <20200601142930.29408-9-f4bug@amsat.org> Signed-off-by: Laurent Vivier <laurent@vivier.eu>
2020-06-08Merge remote-tracking branch ↵Peter Maydell
'remotes/vivier2/tags/linux-user-for-5.1-pull-request' into staging linux-user pull request 20200605-v2 Implement F_OFD_ fcntl() command, /proc/cpuinfo for hppa Fix socket(), prnctl() error codes, underflow in target_mremap, epoll_create() strace, oldumount for alpha User-mode build dependencies improvement # gpg: Signature made Sat 06 Jun 2020 14:15:36 BST # gpg: using RSA key CD2F75DDC8E3A4DC2E4F5173F30C38BD3F2FBE3C # gpg: issuer "laurent@vivier.eu" # gpg: Good signature from "Laurent Vivier <lvivier@redhat.com>" [full] # gpg: aka "Laurent Vivier <laurent@vivier.eu>" [full] # gpg: aka "Laurent Vivier (Red Hat) <lvivier@redhat.com>" [full] # Primary key fingerprint: CD2F 75DD C8E3 A4DC 2E4F 5173 F30C 38BD 3F2F BE3C * remotes/vivier2/tags/linux-user-for-5.1-pull-request: stubs: Restrict ui/win32-kbd-hook to system-mode hw/core: Restrict CpuClass::get_crash_info() to system-mode target/s390x: Restrict CpuClass::get_crash_info() to system-mode target/i386: Restrict CpuClass::get_crash_info() to system-mode arch_init: Remove unused 'qapi-commands-misc.h' include exec: Assert CPU migration is not used on user-only build target/riscv/cpu: Restrict CPU migration to system-mode stubs/Makefile: Reduce the user-mode object list util/Makefile: Reduce the user-mode object list tests/Makefile: Restrict some softmmu-only tests tests/Makefile: Only display TCG-related tests when TCG is available configure: Avoid building TCG when not needed Makefile: Only build virtiofsd if system-mode is enabled linux-user: implement OFD locks linux-user/mmap.c: fix integer underflow in target_mremap linux-user/strace.list: fix epoll_create{,1} -strace output linux-user: Add support for /proc/cpuinfo on hppa platform linux-user: return target error codes for socket() and prctl() linux-user, alpha: fix oldumount syscall Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2020-06-05target/i386: Restrict CpuClass::get_crash_info() to system-modePhilippe Mathieu-Daudé
Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Laurent Vivier <laurent@vivier.eu> Tested-by: Laurent Vivier <laurent@vivier.eu> Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com> Message-Id: <20200522172510.25784-11-philmd@redhat.com> Signed-off-by: Laurent Vivier <laurent@vivier.eu>
2020-05-27i386: Fix x86_cpu_load_model() error API violationMarkus Armbruster
The Error ** argument must be NULL, &error_abort, &error_fatal, or a pointer to a variable containing NULL. Passing an argument of the latter kind twice without clearing it in between is wrong: if the first call sets an error, it no longer points to NULL for the second call. x86_cpu_load_model() is wrong that way. Harmless, because its @errp is always &error_abort. To fix, cut out the @errp middleman. Cc: Paolo Bonzini <pbonzini@redhat.com> Cc: Richard Henderson <rth@twiddle.net> Cc: Eduardo Habkost <ehabkost@redhat.com> Signed-off-by: Markus Armbruster <armbru@redhat.com> Message-Id: <20200505101908.6207-11-armbru@redhat.com>
2020-05-19softfloat: Name compare relation enumRichard Henderson
Give the previously unnamed enum a typedef name. Use it in the prototypes of compare functions. Use it to hold the results of the compare functions. Reviewed-by: Alex Bennée <alex.bennee@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2020-05-15qdev: Unrealize must not failMarkus Armbruster
Devices may have component devices and buses. Device realization may fail. Realization is recursive: a device's realize() method realizes its components, and device_set_realized() realizes its buses (which should in turn realize the devices on that bus, except bus_set_realized() doesn't implement that, yet). When realization of a component or bus fails, we need to roll back: unrealize everything we realized so far. If any of these unrealizes failed, the device would be left in an inconsistent state. Must not happen. device_set_realized() lets it happen: it ignores errors in the roll back code starting at label child_realize_fail. Since realization is recursive, unrealization must be recursive, too. But how could a partly failed unrealize be rolled back? We'd have to re-realize, which can fail. This design is fundamentally broken. device_set_realized() does not roll back at all. Instead, it keeps unrealizing, ignoring further errors. It can screw up even for a device with no buses: if the lone dc->unrealize() fails, it still unregisters vmstate, and calls listeners' unrealize() callback. bus_set_realized() does not roll back either. Instead, it stops unrealizing. Fortunately, no unrealize method can fail, as we'll see below. To fix the design error, drop parameter @errp from all the unrealize methods. Any unrealize method that uses @errp now needs an update. This leads us to unrealize() methods that can fail. Merely passing it to another unrealize method cannot cause failure, though. Here are the ones that do other things with @errp: * virtio_serial_device_unrealize() Fails when qbus_set_hotplug_handler() fails, but still does all the other work. On failure, the device would stay realized with its resources completely gone. Oops. Can't happen, because qbus_set_hotplug_handler() can't actually fail here. Pass &error_abort to qbus_set_hotplug_handler() instead. * hw/ppc/spapr_drc.c's unrealize() Fails when object_property_del() fails, but all the other work is already done. On failure, the device would stay realized with its vmstate registration gone. Oops. Can't happen, because object_property_del() can't actually fail here. Pass &error_abort to object_property_del() instead. * spapr_phb_unrealize() Fails and bails out when remove_drcs() fails, but other work is already done. On failure, the device would stay realized with some of its resources gone. Oops. remove_drcs() fails only when chassis_from_bus()'s object_property_get_uint() fails, and it can't here. Pass &error_abort to remove_drcs() instead. Therefore, no unrealize method can fail before this patch. device_set_realized()'s recursive unrealization via bus uses object_property_set_bool(). Can't drop @errp there, so pass &error_abort. We similarly unrealize with object_property_set_bool() elsewhere, always ignoring errors. Pass &error_abort instead. Several unrealize methods no longer handle errors from other unrealize methods: virtio_9p_device_unrealize(), virtio_input_device_unrealize(), scsi_qdev_unrealize(), ... Much of the deleted error handling looks wrong anyway. One unrealize methods no longer ignore such errors: usb_ehci_pci_exit(). Several realize methods no longer ignore errors when rolling back: v9fs_device_realize_common(), pci_qdev_unrealize(), spapr_phb_realize(), usb_qdev_realize(), vfio_ccw_realize(), virtio_device_realize(). Signed-off-by: Markus Armbruster <armbru@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Paolo Bonzini <pbonzini@redhat.com> Message-Id: <20200505152926.18877-17-armbru@redhat.com>
2020-05-15qom: Drop parameter @errp of object_property_add() & friendsMarkus Armbruster
The only way object_property_add() can fail is when a property with the same name already exists. Since our property names are all hardcoded, failure is a programming error, and the appropriate way to handle it is passing &error_abort. Same for its variants, except for object_property_add_child(), which additionally fails when the child already has a parent. Parentage is also under program control, so this is a programming error, too. We have a bit over 500 callers. Almost half of them pass &error_abort, slightly fewer ignore errors, one test case handles errors, and the remaining few callers pass them to their own callers. The previous few commits demonstrated once again that ignoring programming errors is a bad idea. Of the few ones that pass on errors, several violate the Error API. The Error ** argument must be NULL, &error_abort, &error_fatal, or a pointer to a variable containing NULL. Passing an argument of the latter kind twice without clearing it in between is wrong: if the first call sets an error, it no longer points to NULL for the second call. ich9_pm_add_properties(), sparc32_ledma_realize(), sparc32_dma_realize(), xilinx_axidma_realize(), xilinx_enet_realize() are wrong that way. When the one appropriate choice of argument is &error_abort, letting users pick the argument is a bad idea. Drop parameter @errp and assert the preconditions instead. There's one exception to "duplicate property name is a programming error": the way object_property_add() implements the magic (and undocumented) "automatic arrayification". Don't drop @errp there. Instead, rename object_property_add() to object_property_try_add(), and add the obvious wrapper object_property_add(). Signed-off-by: Markus Armbruster <armbru@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Reviewed-by: Paolo Bonzini <pbonzini@redhat.com> Message-Id: <20200505152926.18877-15-armbru@redhat.com> [Two semantic rebase conflicts resolved]
2020-05-15qom: Drop object_property_set_description() parameter @errpMarkus Armbruster
object_property_set_description() and object_class_property_set_description() fail only when property @name is not found. There are 85 calls of object_property_set_description() and object_class_property_set_description(). None of them can fail: * 84 immediately follow the creation of the property. * The one in spapr_rng_instance_init() refers to a property created in spapr_rng_class_init(), from spapr_rng_properties[]. Every one of them still gets to decide what to pass for @errp. 51 calls pass &error_abort, 32 calls pass NULL, one receives the error and propagates it to &error_abort, and one propagates it to &error_fatal. I'm actually surprised none of them violates the Error API. What are we gaining by letting callers handle the "property not found" error? Use when the property is not known to exist is simpler: you don't have to guard the call with a check. We haven't found such a use in 5+ years. Until we do, let's make life a bit simpler and drop the @errp parameter. Signed-off-by: Markus Armbruster <armbru@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Reviewed-by: Paolo Bonzini <pbonzini@redhat.com> Message-Id: <20200505152926.18877-8-armbru@redhat.com> [One semantic rebase conflict resolved]
2020-05-14target-arm: kvm64: handle SIGBUS signal from kernel or KVMDongjiu Geng
Add a SIGBUS signal handler. In this handler, it checks the SIGBUS type, translates the host VA delivered by host to guest PA, then fills this PA to guest APEI GHES memory, then notifies guest according to the SIGBUS type. When guest accesses the poisoned memory, it will generate a Synchronous External Abort(SEA). Then host kernel gets an APEI notification and calls memory_failure() to unmapped the affected page in stage 2, finally returns to guest. Guest continues to access the PG_hwpoison page, it will trap to KVM as stage2 fault, then a SIGBUS_MCEERR_AR synchronous signal is delivered to Qemu, Qemu records this error address into guest APEI GHES memory and notifes guest using Synchronous-External-Abort(SEA). In order to inject a vSEA, we introduce the kvm_inject_arm_sea() function in which we can setup the type of exception and the syndrome information. When switching to guest, the target vcpu will jump to the synchronous external abort vector table entry. The ESR_ELx.DFSC is set to synchronous external abort(0x10), and the ESR_ELx.FnV is set to not valid(0x1), which will tell guest that FAR is not valid and hold an UNKNOWN value. These values will be set to KVM register structures through KVM_SET_ONE_REG IOCTL. Signed-off-by: Dongjiu Geng <gengdongjiu@huawei.com> Signed-off-by: Xiang Zheng <zhengxiang9@huawei.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Acked-by: Xiang Zheng <zhengxiang9@huawei.com> Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Igor Mammedov <imammedo@redhat.com> Message-id: 20200512030609.19593-10-gengdongjiu@huawei.com Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2020-05-14KVM: Move hwpoison page related functions into kvm-all.cDongjiu Geng
kvm_hwpoison_page_add() and kvm_unpoison_all() will both be used by X86 and ARM platforms, so moving them into "accel/kvm/kvm-all.c" to avoid duplicate code. For architectures that don't use the poison-list functionality the reset handler will harmlessly do nothing, so let's register the kvm_unpoison_all() function in the generic kvm_init() function. Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Dongjiu Geng <gengdongjiu@huawei.com> Signed-off-by: Xiang Zheng <zhengxiang9@huawei.com> Acked-by: Xiang Zheng <zhengxiang9@huawei.com> Message-id: 20200512030609.19593-8-gengdongjiu@huawei.com Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2020-04-29various: Remove suspicious '\' character outside of #define in C codePhilippe Mathieu-Daudé
Fixes the following coccinelle warnings: $ spatch --sp-file --verbose-parsing ... \ scripts/coccinelle/remove_local_err.cocci ... SUSPICIOUS: a \ character appears outside of a #define at ./target/ppc/translate_init.inc.c:5213 SUSPICIOUS: a \ character appears outside of a #define at ./target/ppc/translate_init.inc.c:5261 SUSPICIOUS: a \ character appears outside of a #define at ./target/microblaze/cpu.c:166 SUSPICIOUS: a \ character appears outside of a #define at ./target/microblaze/cpu.c:167 SUSPICIOUS: a \ character appears outside of a #define at ./target/microblaze/cpu.c:169 SUSPICIOUS: a \ character appears outside of a #define at ./target/microblaze/cpu.c:170 SUSPICIOUS: a \ character appears outside of a #define at ./target/microblaze/cpu.c:171 SUSPICIOUS: a \ character appears outside of a #define at ./target/microblaze/cpu.c:172 SUSPICIOUS: a \ character appears outside of a #define at ./target/microblaze/cpu.c:173 SUSPICIOUS: a \ character appears outside of a #define at ./target/i386/cpu.c:5787 SUSPICIOUS: a \ character appears outside of a #define at ./target/i386/cpu.c:5789 SUSPICIOUS: a \ character appears outside of a #define at ./target/i386/cpu.c:5800 SUSPICIOUS: a \ character appears outside of a #define at ./target/i386/cpu.c:5801 SUSPICIOUS: a \ character appears outside of a #define at ./target/i386/cpu.c:5802 SUSPICIOUS: a \ character appears outside of a #define at ./target/i386/cpu.c:5804 SUSPICIOUS: a \ character appears outside of a #define at ./target/i386/cpu.c:5805 SUSPICIOUS: a \ character appears outside of a #define at ./target/i386/cpu.c:5806 SUSPICIOUS: a \ character appears outside of a #define at ./target/i386/cpu.c:6329 SUSPICIOUS: a \ character appears outside of a #define at ./hw/sd/sdhci.c:1133 SUSPICIOUS: a \ character appears outside of a #define at ./hw/scsi/scsi-disk.c:3081 SUSPICIOUS: a \ character appears outside of a #define at ./hw/net/virtio-net.c:1529 SUSPICIOUS: a \ character appears outside of a #define at ./hw/riscv/sifive_u.c:468 SUSPICIOUS: a \ character appears outside of a #define at ./dump/dump.c:1895 SUSPICIOUS: a \ character appears outside of a #define at ./block/vhdx.c:2209 SUSPICIOUS: a \ character appears outside of a #define at ./block/vhdx.c:2215 SUSPICIOUS: a \ character appears outside of a #define at ./block/vhdx.c:2221 SUSPICIOUS: a \ character appears outside of a #define at ./block/vhdx.c:2222 SUSPICIOUS: a \ character appears outside of a #define at ./block/replication.c:172 SUSPICIOUS: a \ character appears outside of a #define at ./block/replication.c:173 Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com> Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Message-Id: <20200412223619.11284-2-f4bug@amsat.org> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Acked-by: David Gibson <david@gibson.dropbear.id.au> Signed-off-by: Markus Armbruster <armbru@redhat.com>
2020-04-15gdbstub: i386: Fix gdb_get_reg16() parameter to unbreak gdbPeter Xu
We should only pass in gdb_get_reg16() with the GByteArray* object itself, no need to shift. Without this patch, gdb remote attach will crash QEMU: (gdb) target remote :1234 Remote debugging using :1234 Remote communication error. Target disconnected.: Connection reset by peer. $ qemu-system-x86_64 -m 1G -smp 4 ... -s ERROR:qemu/gdbstub.c:1843:handle_read_all_regs: assertion failed: (len == gdbserver_state.mem_buf->len) Bail out! ERROR:qemu/gdbstub.c:1843:handle_read_all_regs: assertion failed: (len == gdbserver_state.mem_buf->len) Fixes: a010bdbe719 ("extend GByteArray to read register helpers") Signed-off-by: Peter Xu <peterx@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Signed-off-by: Alex Bennée <alex.bennee@linaro.org> Tested-by: Stefano Garzarella <sgarzare@redhat.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-Id: <20200409164954.36902-3-peterx@redhat.com> Message-Id: <20200414200631.12799-12-alex.bennee@linaro.org>
2020-04-14hax: Windows doesn't like posix device namesVolker Rümelin
Patch acb9f95a7c "i386: Fix GCC warning with snprintf when HAX is enabled" replaced Windows device names with posix device names. Revert this. Fixes: acb9f95a7c "i386: Fix GCC warning with snprintf when HAX is enabled" Signed-off-by: Volker Rümelin <vr_qemu@t-online.de> Message-Id: <20200322210211.29603-1-vr_qemu@t-online.de> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-04-03Merge remote-tracking branch 'remotes/ehabkost/tags/x86-next-pull-request' ↵Peter Maydell
into staging x86 queue for -rc2 Fixes: * EPYC CPU model APIC ID topology fixes (Babu Moger) * Fix crash when enabling intel-pt on older machine types (Luwei Kang) * Add missing ARCH_CAPABILITIES bits to Icelake-Server CPU model (Xiaoyao Li) # gpg: Signature made Thu 02 Apr 2020 23:18:30 BST # gpg: using RSA key 5A322FD5ABC4D3DBACCFD1AA2807936F984DC5A6 # gpg: issuer "ehabkost@redhat.com" # gpg: Good signature from "Eduardo Habkost <ehabkost@redhat.com>" [full] # Primary key fingerprint: 5A32 2FD5 ABC4 D3DB ACCF D1AA 2807 936F 984D C5A6 * remotes/ehabkost/tags/x86-next-pull-request: target/i386: Add ARCH_CAPABILITIES related bits into Icelake-Server CPU model target/i386: set the CPUID level to 0x14 on old machine-type i386: Fix pkg_id offset for EPYC cpu models target/i386: Enable new apic id encoding for EPYC based cpus models hw/i386: Move arch_id decode inside x86_cpus_init i386: Introduce use_epyc_apic_id_encoding in X86CPUDefinition hw/i386: Introduce apicid functions inside X86MachineState target/i386: Cleanup and use the EPYC mode topology functions hw/386: Add EPYC mode topology decoding functions Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2020-04-02target/i386: do not set unsupported VMX secondary execution controlsVitaly Kuznetsov
Commit 048c95163b4 ("target/i386: work around KVM_GET_MSRS bug for secondary execution controls") added a workaround for KVM pre-dating commit 6defc591846d ("KVM: nVMX: include conditional controls in /dev/kvm KVM_GET_MSRS") which wasn't setting certain available controls. The workaround uses generic CPUID feature bits to set missing VMX controls. It was found that in some cases it is possible to observe hosts which have certain CPUID features but lack the corresponding VMX control. In particular, it was reported that Azure VMs have RDSEED but lack VMX_SECONDARY_EXEC_RDSEED_EXITING; attempts to enable this feature bit result in QEMU abort. Resolve the issue but not applying the workaround when we don't have to. As there is no good way to find out if KVM has the fix itself, use 95c5c7c77c ("KVM: nVMX: list VMX MSRs in KVM_GET_MSR_INDEX_LIST") instead as these [are supposed to] come together. Fixes: 048c95163b4 ("target/i386: work around KVM_GET_MSRS bug for secondary execution controls") Suggested-by: Paolo Bonzini <pbonzini@redhat.com> Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com> Message-Id: <20200331162752.1209928-1-vkuznets@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-04-02i386: hvf: Reset IRQ inhibition after moving RIPRoman Bolshakov
The sequence of instructions exposes an issue: sti hlt Interrupts cannot be delivered to hvf after hlt instruction cpu because HF_INHIBIT_IRQ_MASK is set just before hlt is handled and never reset after moving instruction pointer beyond hlt. So, after hvf_vcpu_exec() returns, CPU thread gets locked up forever in qemu_wait_io_event() (cpu_thread_is_idle() evaluates inhibition flag and considers the CPU idle if the flag is set). Cc: Cameron Esfahani <dirty@apple.com> Signed-off-by: Roman Bolshakov <r.bolshakov@yadro.com> Message-Id: <20200328174411.51491-1-r.bolshakov@yadro.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-03-31target/i386: Add ARCH_CAPABILITIES related bits into Icelake-Server CPU modelXiaoyao Li
Current Icelake-Server CPU model lacks all the features enumerated by MSR_IA32_ARCH_CAPABILITIES. Add them, so that guest of "Icelake-Server" can see all of them. Signed-off-by: Xiaoyao Li <xiaoyao.li@intel.com> Message-Id: <20200316095605.12318-1-xiaoyao.li@intel.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2020-03-31target/i386: set the CPUID level to 0x14 on old machine-typeLuwei Kang
The CPUID level need to be set to 0x14 manually on old machine-type if Intel PT is enabled in guest. E.g. the CPUID[0].EAX(level)=7 and CPUID[7].EBX[25](intel-pt)=1 when the Qemu with "-machine pc-i440fx-3.1 -cpu qemu64,+intel-pt" parameter. Some Intel PT capabilities are exposed by leaf 0x14 and the missing capabilities will cause some MSRs access failed. This patch add a warning message to inform the user to extend the CPUID level. Suggested-by: Eduardo Habkost <ehabkost@redhat.com> Signed-off-by: Luwei Kang <luwei.kang@intel.com> Message-Id: <1584031686-16444-1-git-send-email-luwei.kang@intel.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2020-03-31i386: Fix pkg_id offset for EPYC cpu modelsBabu Moger
If the system is numa configured the pkg_offset needs to be adjusted for EPYC cpu models. Fix it calling the model specific handler. Signed-off-by: Babu Moger <babu.moger@amd.com> Reviewed-by: Igor Mammedov <imammedo@redhat.com> Acked-by: Michael S. Tsirkin <mst@redhat.com> Message-Id: <158396725589.58170.16424607815207074485.stgit@naples-babu.amd.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2020-03-31target/i386: Enable new apic id encoding for EPYC based cpus modelsBabu Moger
The APIC ID is decoded based on the sequence sockets->dies->cores->threads. This works fine for most standard AMD and other vendors' configurations, but this decoding sequence does not follow that of AMD's APIC ID enumeration strictly. In some cases this can cause CPU topology inconsistency. When booting a guest VM, the kernel tries to validate the topology, and finds it inconsistent with the enumeration of EPYC cpu models. The more details are in the bug https://bugzilla.redhat.com/show_bug.cgi?id=1728166. To fix the problem we need to build the topology as per the Processor Programming Reference (PPR) for AMD Family 17h Model 01h, Revision B1 Processors. The documentation is available from the bugzilla Link below. Link: https://bugzilla.kernel.org/show_bug.cgi?id=206537 It is also available at https://www.amd.com/system/files/TechDocs/55570-B1_PUB.zip Here is the text from the PPR. Operating systems are expected to use Core::X86::Cpuid::SizeId[ApicIdSize], the number of least significant bits in the Initial APIC ID that indicate core ID within a processor, in constructing per-core CPUID masks. Core::X86::Cpuid::SizeId[ApicIdSize] determines the maximum number of cores (MNC) that the processor could theoretically support, not the actual number of cores that are actually implemented or enabled on the processor, as indicated by Core::X86::Cpuid::SizeId[NC]. Each Core::X86::Apic::ApicId[ApicId] register is preset as follows: • ApicId[6] = Socket ID. • ApicId[5:4] = Node ID. • ApicId[3] = Logical CCX L3 complex ID • ApicId[2:0]= (SMT) ? {LogicalCoreID[1:0],ThreadId} : {1'b0,LogicalCoreID[1:0]} The new apic id encoding is enabled for EPYC and EPYC-Rome models. Signed-off-by: Babu Moger <babu.moger@amd.com> Acked-by: Michael S. Tsirkin <mst@redhat.com> Acked-by: Igor Mammedov <imammedo@redhat.com> Message-Id: <158396724913.58170.3539083528095710811.stgit@naples-babu.amd.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2020-03-31i386: Introduce use_epyc_apic_id_encoding in X86CPUDefinitionBabu Moger
Add a boolean variable use_epyc_apic_id_encoding in X86CPUDefinition. This will be set if this cpu model needs to use new EPYC based apic id encoding. Override the handlers with EPYC based handlers if use_epyc_apic_id_encoding is set. This will be done in x86_cpus_init. Signed-off-by: Babu Moger <babu.moger@amd.com> Message-Id: <158396723514.58170.14825482171652019765.stgit@naples-babu.amd.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2020-03-31target/i386: Cleanup and use the EPYC mode topology functionsBabu Moger
Use the new functions from topology.h and delete the unused code. Given the sockets, nodes, cores and threads, the new functions generate apic id for EPYC mode. Removes all the hardcoded values. Signed-off-by: Babu Moger <babu.moger@amd.com> Acked-by: Michael S. Tsirkin <mst@redhat.com> Acked-by: Igor Mammedov <imammedo@redhat.com> Message-Id: <158396722151.58170.8031705769621392927.stgit@naples-babu.amd.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2020-03-26linux-user/i386: Emulate x86_64 vsyscallsRichard Henderson
Notice the magic page during translate, much like we already do for the arm32 commpage. At runtime, raise an exception to return cpu_loop for emulation. Reviewed-by: Paolo Bonzini <pbonzini@redhat.com> Signed-off-by: Richard Henderson <richard.henderson@linaro.org> Message-Id: <20200213032223.14643-4-richard.henderson@linaro.org> Signed-off-by: Laurent Vivier <laurent@vivier.eu>
2020-03-26target/i386: Renumber EXCP_SYSCALLRichard Henderson
We are not short of numbers for EXCP_*. There is no need to confuse things by having EXCP_VMEXIT and EXCP_SYSCALL overlap, even though the former is only used for system mode and the latter is only used for user mode. Reviewed-by: Paolo Bonzini <pbonzini@redhat.com> Reviewed-by: Alex Bennée <alex.bennee@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Signed-off-by: Richard Henderson <richard.henderson@linaro.org> Message-Id: <20200213032223.14643-2-richard.henderson@linaro.org> Signed-off-by: Laurent Vivier <laurent@vivier.eu>
2020-03-19Merge remote-tracking branch ↵Peter Maydell
'remotes/ehabkost/tags/x86-and-machine-pull-request' into staging x86 and machine queue for 5.0 soft freeze Bug fixes: * memory encryption: Disable mem merge (Dr. David Alan Gilbert) Features: * New EPYC CPU definitions (Babu Moger) * Denventon-v2 CPU model (Tao Xu) * New 'note' field on versioned CPU models (Tao Xu) Cleanups: * x86 CPU topology cleanups (Babu Moger) * cpu: Use DeviceClass reset instead of a special CPUClass reset (Peter Maydell) # gpg: Signature made Wed 18 Mar 2020 01:16:43 GMT # gpg: using RSA key 5A322FD5ABC4D3DBACCFD1AA2807936F984DC5A6 # gpg: issuer "ehabkost@redhat.com" # gpg: Good signature from "Eduardo Habkost <ehabkost@redhat.com>" [full] # Primary key fingerprint: 5A32 2FD5 ABC4 D3DB ACCF D1AA 2807 936F 984D C5A6 * remotes/ehabkost/tags/x86-and-machine-pull-request: hw/i386: Rename apicid_from_topo_ids to x86_apicid_from_topo_ids hw/i386: Update structures to save the number of nodes per package hw/i386: Remove unnecessary initialization in x86_cpu_new machine: Add SMP Sockets in CpuTopology hw/i386: Consolidate topology functions hw/i386: Introduce X86CPUTopoInfo to contain topology info cpu: Use DeviceClass reset instead of a special CPUClass reset machine/memory encryption: Disable mem merge hw/i386: Rename X86CPUTopoInfo structure to X86CPUTopoIDs i386: Add 2nd Generation AMD EPYC processors i386: Add missing cpu feature bits in EPYC model target/i386: Add new property note to versioned CPU models target/i386: Add Denverton-v2 (no MPX) CPU model Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2020-03-18Merge remote-tracking branch ↵Peter Maydell
'remotes/stsquad/tags/pull-testing-and-gdbstub-170320-1' into staging Testing and gdbstub updates: - docker updates for VirGL - re-factor gdbstub for static GDBState - re-factor gdbstub for dynamic arrays - add SVE support to arm gdbstub - add some guest debug tests to check-tcg - add aarch64 userspace register tests - remove packet size limit to gdbstub - simplify gdbstub monitor code - report vContSupported in gdbstub to use proper single-step # gpg: Signature made Tue 17 Mar 2020 17:47:46 GMT # gpg: using RSA key 6685AE99E75167BCAFC8DF35FBD0DB095A9E2A44 # gpg: Good signature from "Alex Bennée (Master Work Key) <alex.bennee@linaro.org>" [full] # Primary key fingerprint: 6685 AE99 E751 67BC AFC8 DF35 FBD0 DB09 5A9E 2A44 * remotes/stsquad/tags/pull-testing-and-gdbstub-170320-1: (28 commits) gdbstub: Fix single-step issue by confirming 'vContSupported+' feature to gdb gdbstub: do not split gdb_monitor_write payload gdbstub: change GDBState.last_packet to GByteArray tests/tcg/aarch64: add test-sve-ioctl guest-debug test tests/tcg/aarch64: add SVE iotcl test tests/tcg/aarch64: add a gdbstub testcase for SVE registers tests/guest-debug: add a simple test runner configure: allow user to specify what gdb to use tests/tcg/aarch64: userspace system register test target/arm: don't bother with id_aa64pfr0_read for USER_ONLY target/arm: generate xml description of our SVE registers target/arm: default SVE length to 64 bytes for linux-user target/arm: explicitly encode regnum in our XML target/arm: prepare for multiple dynamic XMLs gdbstub: extend GByteArray to read register helpers target/i386: use gdb_get_reg helpers target/m68k: use gdb_get_reg helpers target/arm: use gdb_get_reg helpers gdbstub: add helper for 128 bit registers gdbstub: move mem_buf to GDBState and use GByteArray ... Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2020-03-17hw/i386: Update structures to save the number of nodes per packageBabu Moger
Update structures X86CPUTopoIDs and CPUX86State to hold the number of nodes per package. This is required to build EPYC mode topology. Signed-off-by: Babu Moger <babu.moger@amd.com> Reviewed-by: Igor Mammedov <imammedo@redhat.com> Acked-by: Michael S. Tsirkin <mst@redhat.com> Message-Id: <158396720035.58170.1973738805301006456.stgit@naples-babu.amd.com>
2020-03-17hw/i386: Consolidate topology functionsBabu Moger
Now that we have all the parameters in X86CPUTopoInfo, we can just pass the structure to calculate the offsets and width. Signed-off-by: Babu Moger <babu.moger@amd.com> Reviewed-by: Igor Mammedov <imammedo@redhat.com> Acked-by: Michael S. Tsirkin <mst@redhat.com> Message-Id: <158396717953.58170.5628042059144117669.stgit@naples-babu.amd.com>
2020-03-17cpu: Use DeviceClass reset instead of a special CPUClass resetPeter Maydell
The CPUClass has a 'reset' method. This is a legacy from when TYPE_CPU used not to inherit from TYPE_DEVICE. We don't need it any more, as we can simply use the TYPE_DEVICE reset. The 'cpu_reset()' function is kept as the API which most places use to reset a CPU; it is now a wrapper which calls device_cold_reset() and then the tracepoint function. This change should not cause CPU objects to be reset more often than they are at the moment, because: * nobody is directly calling device_cold_reset() or qdev_reset_all() on CPU objects * no CPU object is on a qbus, so they will not be reset either by somebody calling qbus_reset_all()/bus_cold_reset(), or by the main "reset sysbus and everything in the qbus tree" reset that most devices are reset by Note that this does not change the need for each machine or whatever to use qemu_register_reset() to arrange to call cpu_reset() -- that is necessary because CPU objects are not on any qbus, so they don't get reset when the qbus tree rooted at the sysbus bus is reset, and this isn't being changed here. All the changes to the files under target/ were made using the included Coccinelle script, except: (1) the deletion of the now-inaccurate and not terribly useful "CPUClass::reset" comments was done with a perl one-liner afterwards: perl -n -i -e '/ CPUClass::reset/ or print' target/*/*.c (2) this bit of the s390 change was done by hand, because the Coccinelle script is not sophisticated enough to handle the parent_reset call being inside another function: | @@ -96,8 +96,9 @@ static void s390_cpu_reset(CPUState *s, cpu_reset_type type) | S390CPU *cpu = S390_CPU(s); | S390CPUClass *scc = S390_CPU_GET_CLASS(cpu); | CPUS390XState *env = &cpu->env; |+ DeviceState *dev = DEVICE(s); | |- scc->parent_reset(s); |+ scc->parent_reset(dev); | cpu->env.sigp_order = 0; | s390_cpu_set_state(S390_CPU_STATE_STOPPED, cpu); Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Message-Id: <20200303100511.5498-1-peter.maydell@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Tested-by: Philippe Mathieu-Daudé <philmd@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2020-03-17i386: Add 2nd Generation AMD EPYC processorsMoger, Babu
Adds the support for 2nd Gen AMD EPYC Processors. The model display name will be EPYC-Rome. Adds the following new feature bits on top of the feature bits from the first generation EPYC models. perfctr-core : core performance counter extensions support. Enables the VM to use extended performance counter support. It enables six programmable counters instead of four counters. clzero : instruction zeroes out the 64 byte cache line specified in RAX. xsaveerptr : XSAVE, XSAVE, FXSAVEOPT, XSAVEC, XSAVES always save error pointers and FXRSTOR, XRSTOR, XRSTORS always restore error pointers. wbnoinvd : Write back and do not invalidate cache ibpb : Indirect Branch Prediction Barrier amd-stibp : Single Thread Indirect Branch Predictor clwb : Cache Line Write Back and Retain xsaves : XSAVES, XRSTORS and IA32_XSS support rdpid : Read Processor ID instruction support umip : User-Mode Instruction Prevention support The Reference documents are available at https://developer.amd.com/wp-content/resources/55803_0.54-PUB.pdf https://www.amd.com/system/files/TechDocs/24594.pdf Depends on following kernel commits: 40bc47b08b6e ("kvm: x86: Enumerate support for CLZERO instruction") 504ce1954fba ("KVM: x86: Expose XSAVEERPTR to the guest") 6d61e3c32248 ("kvm: x86: Expose RDPID in KVM_GET_SUPPORTED_CPUID") 52297436199d ("kvm: svm: Update svm_xsaves_supported") Signed-off-by: Babu Moger <babu.moger@amd.com> Message-Id: <157314966312.23828.17684821666338093910.stgit@naples-babu.amd.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2020-03-17i386: Add missing cpu feature bits in EPYC modelMoger, Babu
Adds the following missing CPUID bits: perfctr-core : core performance counter extensions support. Enables the VM to use extended performance counter support. It enables six programmable counters instead of 4 counters. clzero : instruction zeroes out the 64 byte cache line specified in RAX. xsaveerptr : XSAVE, XSAVE, FXSAVEOPT, XSAVEC, XSAVES always save error pointers and FXRSTOR, XRSTOR, XRSTORS always restore error pointers. ibpb : Indirect Branch Prediction Barrie. xsaves : XSAVES, XRSTORS and IA32_XSS supported. Depends on following kernel commits: 40bc47b08b6e ("kvm: x86: Enumerate support for CLZERO instruction") 504ce1954fba ("KVM: x86: Expose XSAVEERPTR to the guest") 52297436199d ("kvm: svm: Update svm_xsaves_supported") These new features will be added in EPYC-v3. The -cpu help output after the change. x86 EPYC-v1 AMD EPYC Processor x86 EPYC-v2 AMD EPYC Processor (with IBPB) x86 EPYC-v3 AMD EPYC Processor Signed-off-by: Babu Moger <babu.moger@amd.com> Message-Id: <157314965662.23828.3063243729449408327.stgit@naples-babu.amd.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2020-03-17target/i386: Add new property note to versioned CPU modelsTao Xu
Add additional information for -cpu help to indicate the changes in this version of CPU model. Suggested-by: Eduardo Habkost <ehabkost@redhat.com> Signed-off-by: Tao Xu <tao3.xu@intel.com> Message-Id: <20200212081328.7385-4-tao3.xu@intel.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2020-03-17target/i386: Add Denverton-v2 (no MPX) CPU modelTao Xu
Because MPX is being removed from the linux kernel, remove MPX feature from Denverton. Signed-off-by: Tao Xu <tao3.xu@intel.com> Message-Id: <20200212081328.7385-2-tao3.xu@intel.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2020-03-17gdbstub: extend GByteArray to read register helpersAlex Bennée
Instead of passing a pointer to memory now just extend the GByteArray to all the read register helpers. They can then safely append their data through the normal way. We don't bother with this abstraction for write registers as we have already ensured the buffer being copied from is the correct size. Signed-off-by: Alex Bennée <alex.bennee@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Acked-by: David Gibson <david@gibson.dropbear.id.au> Reviewed-by: Damien Hedde <damien.hedde@greensocs.com> Message-Id: <20200316172155.971-15-alex.bennee@linaro.org>
2020-03-17target/i386: use gdb_get_reg helpersAlex Bennée
This is cleaner than poking memory directly and will make later clean-ups easier. Signed-off-by: Alex Bennée <alex.bennee@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Message-Id: <20200316172155.971-14-alex.bennee@linaro.org>
2020-03-16WHPX: Use proper synchronization primitives while processingSunil Muthuswamy
WHPX wasn't using the proper synchronization primitives while processing async events, which can cause issues with SMP. Signed-off-by: Sunil Muthuswamy <sunilmut@microsoft.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-03-16i386: Fix GCC warning with snprintf when HAX is enabledJulio Faracco
When HAX is enabled (--enable-hax), GCC 9.2.1 reports issues with snprintf(). Replacing old snprintf() by g_strdup_printf() fixes the problem with boundary checks of vm_id and vcpu_id and finally the warnings produced by GCC. For more details, one example of warning: CC i386-softmmu/target/i386/hax-posix.o qemu/target/i386/hax-posix.c: In function ‘hax_host_open_vm’: qemu/target/i386/hax-posix.c:124:56: error: ‘%02d’ directive output may be truncated writing between 2 and 11 bytes into a region of size 3 [-Werror=format-truncation=] 124 | snprintf(name, sizeof HAX_VM_DEVFS, "/dev/hax_vm/vm%02d", vm_id); | ^~~~ qemu/target/i386/hax-posix.c:124:41: note: directive argument in the range [-2147483648, 64] 124 | snprintf(name, sizeof HAX_VM_DEVFS, "/dev/hax_vm/vm%02d", vm_id); | ^~~~~~~~~~~~~~~~~~~~ In file included from /usr/include/stdio.h:867, from qemu/include/qemu/osdep.h:99, from qemu/target/i386/hax-posix.c:14: /usr/include/bits/stdio2.h:67:10: note: ‘__builtin___snprintf_chk’ output between 17 and 26 bytes into a destination of size 17 67 | return __builtin___snprintf_chk (__s, __n, __USE_FORTIFY_LEVEL - 1, | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 68 | __bos (__s), __fmt, __va_arg_pack ()); | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Signed-off-by: Julio Faracco <jcfaracco@gmail.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-03-16qom/object: Use common get/set uint helpersFelipe Franciosi
Several objects implemented their own uint property getters and setters, despite them being straightforward (without any checks/validations on the values themselves) and identical across objects. This makes use of an enhanced API for object_property_add_uintXX_ptr() which offers default setters. Some of these setters used to update the value even if the type visit failed (eg. because the value being set overflowed over the given type). The new setter introduces a check for these errors, not updating the value if an error occurred. The error is propagated. Signed-off-by: Felipe Franciosi <felipe@nutanix.com> Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-03-16WHPX: Use QEMU values for trapped CPUIDSunil Muthuswamy
Currently, WHPX is using some default values for the trapped CPUID functions. These were not in sync with the QEMU values because the CPUID values were never set with WHPX during VCPU initialization. Additionally, at the moment, WHPX doesn't support setting CPUID values in the hypervisor at runtime (i.e. after the partition has been setup). That is needed to be able to set the CPUID values in the hypervisor during VCPU init. Until that support comes, use the QEMU values for the trapped CPUIDs. Signed-off-by: Sunil Muthuswamy <sunilmut@microsoft.com> Message-Id: <SN4PR2101MB0880A8323EAD0CD0E8E2F423C0EB0@SN4PR2101MB0880.namprd21.prod.outlook.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-03-16WHPX: TSC get and set should be dependent on VM stateSunil Muthuswamy
Currently, TSC is set as part of the VM runtime state. Setting TSC at runtime is heavy and additionally can have side effects on the guest, which are not very resilient to variances in the TSC. This patch uses the VM state to determine whether to set TSC or not. Some minor enhancements for getting TSC values as well that considers the VM state. Additionally, while setting the TSC, the partition is suspended to reduce the variance in the TSC value across vCPUs. Signed-off-by: Sunil Muthuswamy <sunilmut@microsoft.com> Message-Id: <SN4PR2101MB08804D23439166E81FF151F7C0EA0@SN4PR2101MB0880.namprd21.prod.outlook.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-02-25Merge branch 'exec_rw_const_v4' of https://github.com/philmd/qemu into HEADPaolo Bonzini
2020-02-25target/i386: check for empty register in FXAMPaolo Bonzini
The fxam instruction returns the wrong result after fdecstp or after an underflow. Check fptags to handle this. Reported-by: <chengang@emindsoft.com.cn> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-02-20Avoid cpu_physical_memory_rw() with a constant is_write argumentPhilippe Mathieu-Daudé
This commit was produced with the included Coccinelle script scripts/coccinelle/exec_rw_const. Inspired-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com>
2020-02-20Let cpu_[physical]_memory() calls pass a boolean 'is_write' argumentPhilippe Mathieu-Daudé
Use an explicit boolean type. This commit was produced with the included Coccinelle script scripts/coccinelle/exec_rw_const. Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com>
2020-02-20Avoid address_space_rw() with a constant is_write argumentPeter Maydell
The address_space_rw() function allows either reads or writes depending on the is_write argument passed to it; this is useful when the direction of the access is determined programmatically (as for instance when handling the KVM_EXIT_MMIO exit reason). Under the hood it just calls either address_space_write() or address_space_read_full(). We also use it a lot with a constant is_write argument, though, which has two issues: * when reading "address_space_rw(..., 1)" this is less immediately clear to the reader as being a write than "address_space_write(...)" * calling address_space_rw() bypasses the optimization in address_space_read() that fast-paths reads of a fixed length This commit was produced with the included Coccinelle script scripts/coccinelle/exec_rw_const.cocci. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Edgar E. Iglesias <edgar.iglesias@xilinx.com> Reviewed-by: Laurent Vivier <lvivier@redhat.com> Reviewed-by: Cédric Le Goater <clg@kaod.org> Acked-by: Christian Borntraeger <borntraeger@de.ibm.com> Reviewed-by: Cornelia Huck <cohuck@redhat.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Acked-by: David Gibson <david@gibson.dropbear.id.au> Message-Id: <20200218112457.22712-1-peter.maydell@linaro.org> [PMD: Update macvm_set_cr0() reported by Laurent Vivier] Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com>
2020-02-20Let address_space_rw() calls pass a boolean 'is_write' argumentPhilippe Mathieu-Daudé
Since its introduction in commit ac1970fbe8, address_space_rw() takes a boolean 'is_write' argument. Fix the codebase by using an explicit boolean type. This commit was produced with the included Coccinelle script scripts/coccinelle/exec_rw_const. Inspired-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com>
2020-02-20Remove unnecessary cast when using the cpu_[physical]_memory APIPhilippe Mathieu-Daudé
This commit was produced with the included Coccinelle script scripts/coccinelle/exec_rw_const. Suggested-by: Stefan Weil <sw@weilnetz.de> Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com>
2020-02-20Remove unnecessary cast when using the address_space APIPhilippe Mathieu-Daudé
This commit was produced with the included Coccinelle script scripts/coccinelle/exec_rw_const. Two lines in hw/net/dp8393x.c that Coccinelle produced that were over 80 characters were re-wrapped by hand. Suggested-by: Stefan Weil <sw@weilnetz.de> Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com>
2020-02-18target/i386/whpx: Remove superfluous semicolonPhilippe Mathieu-Daudé
Fixes: 812d49f2a3e Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com> Acked-by: Paolo Bonzini <pbonzini@redhat.com> Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com> Reviewed-by: Juan Quintela <quintela@redhat.com> Message-Id: <20200218094402.26625-12-philmd@redhat.com> Signed-off-by: Laurent Vivier <laurent@vivier.eu>