Initialize KVM paravirt cpuid leaf and allow user to control guest
visible PV features through -cpu flag.
Signed-off-by: Gleb Natapov <gleb@redhat.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
Now, if we inject a fatal MCE into guest OS, for example Linux, Linux
will go panic and then reboot. But if we inject another MCE now,
system will reset directly instead of go panic firstly, because
MCG_STATUS.MCIP is set to 1 and not cleared after reboot. This is does
not follow the behavior in real hardware.
This patch fixes this via set env->mcg_status to 0 during system reset.
Signed-off-by: Huang Ying <ying.huang@intel.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
The CPUID features QEMU presented to the guest were not up-to-date
with QEMU's emulated feature set.
Add the missing bits of recent (and not so recent) additions to
QEMU's emulation engine.
For stability reasons only the user mode usable bits are exposed for
now, features like Monitor or CR8LEG are left out.
Signed-off-by: Andre Przywara <andre.przywara@amd.com>
Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
The multicore CPUID code detects whether the guest is an Intel or an
AMD CPU, because the Linux kernel is picky about the CmpLegacy bit.
KVM by default passes through the host's vendor, which was not
catched by the code. So fork out the vendor determining bits into a
separate function to be used from both places and always get the real
vendor.
This fixes KVM's multicore setup on Intel CPUs.
Signed-off-by: Andre Przywara <andre.przywara@amd.com>
Reported-by: Dietmar Maurer <dietmar@proxmox.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
There is absolutely no need to call reset functions when initializing
devices. Since we are already registering them, calling qemu_system_reset()
should suffice. Actually, it is what happens when we reboot the machine,
and using the same process instead of a special case semantics will even
allow us to find bugs easier.
Furthermore, the fact that we initialize things like the cpu quite early,
leads to the need to introduce synchronization stuff like qemu_system_cond.
This patch removes it entirely. All we need to do is call qemu_system_reset()
only when we're already sure the system is up and running
I tested it with qemu (with and without io-thread) and qemu-kvm, and it
seems to be doing okay - although qemu-kvm uses a slightly different patch.
[ v2: user mode still needs cpu_reset, so put it in ifdef. ]
[ v3: leave qemu_system_cond for now. ]
Signed-off-by: Glauber Costa <glommer@redhat.com>
Signed-off-by: Blue Swirl <blauwirbel@gmail.com>
mce_banks is always MCE_BANKS_DEF * 4 in size, value never change
CC: Huang Ying <ying.huang@intel.com>
Signed-off-by: Juan Quintela <quintela@redhat.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
This makes the savevm code correct, and sign extensins gives us exactly
what we need (namely, sign extend to 64 bits when used with 64bit addresess.
Once there, change 0x100000 for 1 << 20, that maks all a20 use the same syntax.
Signed-off-by: Juan Quintela <quintela@redhat.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
In the very least, a change like this requires discussion on the list.
The naming convention is goofy and it causes a massive merge problem. Something
like this _must_ be presented on the list first so people can provide input
and cope with it.
This reverts commit 99a0949b72.
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
Problem: Our file sys-queue.h is a copy of the BSD file, but there are
some additions and it's not entirely compatible. Because of that, there have
been conflicts with system headers on BSD systems. Some hacks have been
introduced in the commits 15cc923584,
f40d753718,
96555a96d7 and
3990d09adf but the fixes were fragile.
Solution: Avoid the conflict entirely by renaming the functions and the
file. Revert the previous hacks.
Signed-off-by: Blue Swirl <blauwirbel@gmail.com>
Direct call to kvm_arch_get_registers() bypass logic in
cpu_synchronize_state()
Signed-off-by: Gleb Natapov <gleb@redhat.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
In addition to the TCG based qemu64 type let's introduce a kvm64 CPU type,
which is the least common denominator of all KVM-capable x86-CPUs
(based on Intel Pentium 4 Prescott). It can be used as a base type
for migration.
Signed-off-by: Andre Przywara <andre.przywara@amd.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
The CPUID level determines how many CPUID leafs are exposed to the guest.
Some features (like multi-core) cannot be propagated without the proper
level, but guests maybe confused by bogus entries in some leafs.
So add level= and xlevel= to the list of -cpu options to allow the user to
override the default settings. While at it, merge unnecessary local
variables into one and allow hexadecimal arguments.
Signed-off-by: Andre Przywara <andre.przywara@amd.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
Controlled by the enhanced -smp option set the CPUID bits to present the
guest the desired topology. This is vendor specific, but (with the exception
of the CMP_LEGACY bit) not conflicting, so we set all bits everytime.
There is no real multithreading support for AMD CPUs, so report cores
instead.
Signed-off-by: Andre Przywara <andre.przywara@amd.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
Intel CPUs store the number of cores in CPUID leaf 4. So push
the maxleaf value to 4 to allow the guests access to this leaf.
Signed-off-by: Andre Przywara <andre.przywara@amd.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
kqemu introduces a number of restrictions on the i386 target. The worst is that
it prevents large memory from working in the default build.
Furthermore, kqemu is fundamentally flawed in a number of ways. It relies on
the TSC as a time source which will not be reliable on a multiple processor
system in userspace. Since most modern processors are multicore, this severely
limits the utility of kqemu.
kvm is a viable alternative for people looking to accelerate qemu and has the
benefit of being supported by the upstream Linux kernel. If someone can
implement work arounds to remove the restrictions introduced by kqemu, I'm
happy to avoid and/or revert this patch.
N.B. kqemu will still function in the 0.11 series but this patch removes it from
the 0.12 series.
Paul, please Ack or Nack this patch.
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
Since we recently do not disable 3DNOW! support anymore, we should
avoid setting the bits in the default qemu64 CPU model to ease
migration. TCG does not support it anyway and even AMD deprecates
it's usage nowadays.
If you want to use it in KVM, use the phenom, athlon or host CPU
model.
Signed-off-by: Andre Przywara <andre.przywara@amd.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
This allows to set segment registers via gdb also in system emulation
mode. Basic sanity checks are applied and nothing is changed if they
fail. But screwing up the target via this interface will never be
complicated, so I avoided being too paranoid here.
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
- MCE features are initialized when VCPU is intialized according to CPUID.
- A monitor command "mce" is added to inject a MCE.
- A new interrupt mask: CPU_INTERRUPT_MCE is added to inject the MCE.
aliguori: fix build for linux-user
Signed-off-by: Huang Ying <ying.huang@intel.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
KVM provides an in-kernel feature to disable CPUID bits that are not
present in the current host. So there is no need here to duplicate this
work. Additionally allows 3DNow! on capable processors, since the
restriction seems to apply to QEMU/TCG only.
Signed-off-by: Andre Przywara <andre.przywara@amd.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
If we want to trim the user provided CPUID bits for KVM to be not greater
than that of the host, we should not remove the bits _after_ we sent
them to the kernel.
This fixes the masking of features that are not present on the host by
moving the trim function and it's call from helper.c to kvm.c.
It helps to use -cpu host.
Signed-off-by: Andre Przywara <andre.przywara@amd.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
Although the guest's CPUID bits can be controlled in a fine grained way
in QEMU, a simple way to inject the host CPU is missing. This is handy
for KVM desktop virtualization, where one wants the guest to support the
full host feature set.
Introduce another CPU type called 'host', which will propagate the host's
CPUID bits to the guest. Unwanted bits can still be turned off by using
the existing syntax (-cpu host,-skinit)
Signed-off-by: Andre Przywara <andre.przywara@amd.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
KVM defaults to the hypervisor CPUID bit to be set, whereas pure
QEMU clears it. On some occasions one wants to set or clear it the
other way round (for instance to get HyperV running inside a guest).
Move the bit-set to be done before the command line parsing and
enable it by default. One can disable it by using: -cpu qemu64,-hypervisor
Fix some whitespace damage on the way.
Signed-off-by: Andre Przywara <andre.przywara@amd.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
This should fix compilation problem in case of CONFIG_USER_ONLY.
Currently INIT/SIPI is handled in the context of CPU that sends IPI.
This patch changes this to handle them like all other events in a main
cpu exec loop. When KVM will gain thread per vcpu capability it will
be much more clear to handle those event by cpu thread itself and not
modify one cpu's state from the context of the other.
Signed-off-by: Gleb Natapov <gleb@redhat.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
As per the IA32 processor manual, the accessed bit is set to 1 in the
processor state after reset. qemu pc cpu_reset code was missing this
accessed bit setting.
Signed-off-by: Nitin A Kamble <nitin.a.kamble@intel.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
KVM-enabled QEMU will always report the vendor ID of the physical CPU it is
running on. Allow to override this if explicitly requested on the
command line. It will not suffice to name a CPU type (like -cpu phenom),
but you have to explicitly set the vendor: -cpu phenom,vendor=AuthenticAMD
Signed-off-by: Andre Przywara <andre.przywara@amd.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
Include assert.h from qemu-common.h and remove other direct uses.
cpu-all.h still need to include it because of the dyngen-exec.h hacks
Signed-off-by: Paul Brook <paul@codesourcery.com>
Remove cpu features that are not supported by kvm from the cpuid features
reported to the guest.
Signed-off-by: Avi Kivity <avi@redhat.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
QEMU allows adding or removing cpu features by using the syntax '-cpu +feature'
or '-cpu -feature'. Some cpuid features cause more than one bit to be set or
cleared; but QEMU stops after just one bit has been modified, causing the
feature bits to be inconsistent.
Fix by allowing all feature bits corresponding to a given name to be set.
Signed-off-by: Avi Kivity <avi@redhat.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
Parse the descriptor flags that segment registers refer to and show the
result in a more human-friendly format. The output of info registers eg.
then looks like this:
[...]
ES =007b 00000000 ffffffff 00cff300 DPL=3 DS [-WA]
CS =0060 00000000 ffffffff 00c09b00 DPL=0 CS32 [-RA]
SS =0068 00000000 ffffffff 00c09300 DPL=0 DS [-WA]
DS =007b 00000000 ffffffff 00cff300 DPL=3 DS [-WA]
FS =0000 00000000 00000000 00000000
GS =0033 b7dd66c0 ffffffff b7dff3dd DPL=3 DS [-WA]
LDT=0000 00000000 00000000 00008200 DPL=0 LDT
TR =0080 c06da700 0000206b 00008900 DPL=0 TSS32-avl
[...]
Changes in this version:
- refactoring so that only a single helper is used for dumping the
segment descriptor cache
- tiny typo fixed that broke 64-bit segment type names
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
git-svn-id: svn://svn.savannah.nongnu.org/qemu/trunk@7179 c046a42c-6fe2-441c-8c8c-71466251a162
Cpuid should return into vec, not overwrite past address in count.
Changeset 6565 broke this.
Signed-off-by: Lubomir Rintel <lkundrak@v3.sk>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
git-svn-id: svn://svn.savannah.nongnu.org/qemu/trunk@6689 c046a42c-6fe2-441c-8c8c-71466251a162
The CPUID instruction takes the value of ECX as an input parameter
in addition to the value of EAX as the count for functions 4, 0xb
and 0xd. Make sure we pass the value to the instruction.
Also convert to the qemu-style whitespace for the surrounding code.
Signed-off-by: Amit Shah <amit.shah@redhat.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
git-svn-id: svn://svn.savannah.nongnu.org/qemu/trunk@6565 c046a42c-6fe2-441c-8c8c-71466251a162
As part of my ongoing effort to make nested SVM useful, I started working to get
VMware ESX run inside KVM.
VMware couples itself pretty tightly to the CPUID, so it's a good idea to emulate
a machine that officially supports SVM and should thus exploit the powers of
nested virtualization.
This patch adds a Phenom CPU identifier, that resembles a real-world phenom
CPU as closely as possible.
Signed-off-by: Alexander Graf <agraf@suse.de>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
git-svn-id: svn://svn.savannah.nongnu.org/qemu/trunk@6501 c046a42c-6fe2-441c-8c8c-71466251a162
Original idea&code by Kevin Wolf, split-up in two patches and added more
archs.
This patch introduces a flag to log CPU resets. Useful for tracing
unexpected resets (such as those triggered by x86 triple faults).
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
git-svn-id: svn://svn.savannah.nongnu.org/qemu/trunk@6452 c046a42c-6fe2-441c-8c8c-71466251a162
The attached patch updates the FSF address in the GPL/LGPL boilerplate
in most GPL/LGPLed files, and also in COPYING.LIB.
Signed-off-by: Stuart Brady <stuart.brady@gmail.com>
Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
git-svn-id: svn://svn.savannah.nongnu.org/qemu/trunk@6162 c046a42c-6fe2-441c-8c8c-71466251a162
Gleb Natapov