I broke the 'correct' fix when I copied it out of an email. The
actual correct version, with an extra +1 in the for-loop header is
rather abusive of for loops, so I've changed it now to a do-while loop
and an extra comment so I don't screw up this backwards loop ever
again.
This version does actually boot. :-)
Signed-off-by: Keir Fraser <keir@xensource.com>
- convert raw "install" command to use $(INSTALL)
- convert some $(INSTALL) to $(INSTALL_DATA) as appropriate
- modify the specific $(INSTALL) definitions to use -p.
Original patch by Ben Thomas <ben@virtualiron.com>
Signed-off-by: Keir Fraser <keir@xensource.com>
I've no idea what it does, and it doesn't appear to be valid on some
systems. Use a more generic approach.
Signed-off-by: Ben Thomas <ben@virtualiron.com>
allowed and the functions are marked __init on x86/64.
Use HYPERVISOR_update_va_mapping() directly instead.
Signed-off-by: Keir Fraser <keir@xensource.com>
so that they don't get confused by the way that shadow_teardown()
leaves some of the mode bits set after releasing the shadow resources.
Signed-off-by: Tim Deegan <Tim.Deegan@xensource.com>
Add ia64 mapping for cpuinfo data and make the case where #vcpu !=
#pcpu more flexible (don't rely on cpu0 existing).
Signed-off-by: Alex Williamson <alex.williamson@hp.com>
Since the guest's CR0.PG is always set (in shadow paging), EFER.LME must
be cleared along with EFER.LMA when the guest is disabling paging.
Signed-off-by: Travis Betak <travis.betak@amd.com>
Return the shadow of the guest's EFER instead of the VMCB. This helps
with things such as the unlikely event the guest wants to check EFER.LME
immediately after setting it (The VMCB's EFER.LME remains clear until
the guest enables paging).
Signed-off-by: Travis Betak <travis.betak@amd.com>
The SVM cpu state was being used inconsistently and, besides, it makes
more sense to instead rely on the guest's shadow registers to determine
the current guest state.
Signed-off-by: Travis Betak <travis.betak@amd.com>
While shuffling quite a few things around, this gets us closer to
native, which clearly had a reason to do the DMI scan early.
Signed-off-by: Jan Beulich <jbeulich@novell.com>
Do init memory reservation in a single step rather then piece-wise.
This is not really addressing a problem, but simplifies things a
little.
Signed-off-by: Jan Beulich <jbeulich@novell.com>
Former is safer (in case TIF_IO_BITMAP is out-of-sync with actual
existence of an I/O bitmap for this process) and more readable, and
probably results in faster code too.
Signed-off-by: Keir Fraser <keir@xensource.com>
This adds (or moves to the proper place) annotations paralleling those
added in native code in 2.6.18. To make this look less ugly, it
required moving around a few things.
Signed-off-by: Jan Beulich <jbeulich@novell.com>
The differences of arch/x86_64/kernel/x8664_ksyms-xen.c over its
native original are benign - the Xen special can therefore be
removed.
Signed-off-by: Jan Beulich <jbeulich@novell.com>
The sole (x86-64 specific) difference of
arch/i386/kernel/alternative-xen.c
over its native original can be eliminated by slightly adjusting
x86-64's make_readonly(), and the Xen special can then be removed.
Signed-off-by: Jan Beulich <jbeulich@novell.com>
arch/i386/kernel/cpu/intel_cacheinfo-xen.c is identical to
arch/i386/kernel/cpu/intel_cacheinfo.c, hence the Xen special can be
removed.
Signed-off-by: Jan Beulich <jbeulich@novell.com>
