Instead do this only on context switches. In cases where we need
access to state that is only saved to the VMCB on VMSAVE, we track
whether the state is in sync via a per-vcpu flag and VMSAVE on demand.
The context switch code can be further improved:
1. No need to VMLOAD host state if we are switching to another SVM VCPU.
2. No need to VMSAVE host state at all (except once at start of day)
because the registers that are saved do not change (or at least, none
of the ones that matter change).
The performance is improvement is about 650 cycles for a null
hypercall. This reduces the total null-hypercall time for a non-debug
build of Xen down to around 3300 cycles on my AMD X2 system.
Signed-off-by: Keir Fraser <keir@xensource.com>
It turns out that although PIIX4 hardware defines the S5 type code to
be 000, all OSes will discover the correct code by evlauating an \_Sx
object in the ACPI DSDT. And we set the type code in that object to be
111.
So this patch keeps the other cleanups made to the piix4acpi.c file,
but switches back to checking for code 111. It also makes it clearer
in both the ioemu code and in the dsdt source code where these magic
numbers come from.
Let's hope noone actually has the true PIIX4 type codes hardcoded
(it's highly doubtful that anyone would).
Signed-off-by: Keir Fraser <keir@xensource.com>
Do it earlier on x86/64, properly free non-superpages on x86/32, and
leave a mapping of the boot trampoline (0x90000-0xA0000) in place.
Signed-off-by: Keir Fraser <keir@xensource.com>
handling.
1. Do not copy all VMCB register state in cpu_user_regs on every
vmexit.
2. Save/restore RAX inside asm stub (in particular, before STGI on
vmexit).
3. Simplify store/load_cpu_guest_regs() hook functions to synchronise
precisely the same state as VMX.
By my measurements this reduces the round-trip latency for a null
hypercall by around 150 cycles. This is about 3% of the ~5000-cycle
total on my AMD X2 system. Not a great win, but a nice extra on top of
the code rationalisation.
1. Remove erroneous modification to e820.c
2. Make sure Xen is relocated as high as possible below 4GB.
Signed-off-by: Keir Fraser <keir@xensource.com>
1. x86/64 Xen now relocates itself to physical high memory. This is
useful if we have devices that need very low memory, or if in
future we want to grant a 1:1 mapping of low physical memory to a
special 'native client domain'.
2. We now only map low 16MB RAM statically. All other RAM is mapped
dynamically within the constraints of the e820 map. It is
recommended never to map MMIO regions, and this change means that
Xen now obeys this constraint.
3. The CPU bootup trampoline is now permanently installed at
0x90000. This is necessary prereq for CPU hotplug.
4. Start-of-day asm is generally cleaned up and diff between x86/32
and x86/64 is reduced.
Signed-off-by: Keir Fraser <keir@xensource.com>
Fix wrong python list assignment for "monitor=1". The old assignment
only works when using qemu-dm.debug in configure file.
Signed-off-by: You YongKang <yongkang.you@intel.com>
Signed-off-by: Zhang Xin <xing.z.zhang@intel.com>
Currently it returns supported_bootloaders as a string. This patch
returns supported_bootloaders as a 'string set' - per the spec. The
c-bindings fail to parse response, expecting a set but only finding a
string.
Signed-off-by: Jim Fehlig <jfehlig@novell.com>
Steven Hand
Keir Fraser
Christian Limpach
kfraser@localhost.localdomain
Ian Campbell
Tim Deegan