compiled with gcc and linked into the hvmloader as a byte-array.
Hvmloader allocates memory (rounded up to next 64kb) from the e820
table
below 4GB, copies and relocates the 32bit code in the allocated area
and
copies a jumptable (located in a section '.biosjumptable') pointing to
the 'exported' functions into the Bochs BIOS's memory area to link the
two code sections. The memory area has been reserved and can be
identified with the signature '___JMPT'.
In the Bochs BIOS only stub functions are provided. These load the
index
of a particular function in the jump table, switch to protected mode
and
call the function in the high memory area. The stack is prepared such
that functions compiled by gcc can just pick the parameters from the
stack as usual - this means that the 16bit real-mode return address is
taken off the stack. The stub functions should have the same signature
as those in 32bit space. For ABI compatibility reasons parameters
inside
the Bochs BIOS stubs should all be 32bit wide.
This patch includes a test function that calls three gcc-compiled
functions in the high memory area and displays their success status.
Simple tests are done doing multiplication and addition of 32-bit
numbers and reading and modification of a static variable. These
functions test the interface and the relocation code. The test code is
removed in patch part 3.
Signed-off-by: Stefan Berger <stefanb@us.ibm.com>
This is a built-in assumption of HPET 'legacy' IRQ routing, which is
why we have changed to this routing strategy now.
Signed-off-by: Keir Fraser <keir@xensource.com>
This is rudimentary support for parts of the BIOS Boot Specification,
just enough to use Etherboot ROM images.
Signed-off-by: Tim Deegan <Tim.Deegan@xensource.com>
According to Intel Spec, segments registors are cleared when exiting
virtual-8086 mode through trap or interrupts gate, so it's no need to
save their values in stack.
Signed-off-by: Xin Li <xin.b.li@intel.com>
for the RSDP in memory (up to the BIOS) rather than calculating its
start address. Recent changes seem to have moved the RSDP to another
location in memory so that I received 'BAD RSPD signature' messages.
I have also fixed some other possible issues related to return codes
and alignment of ACPI entries.
Signed-off-by: Stefan Berger <stefanb@us.ibm.com>
Also simplify the HVM builder interface by doing more work in
the python wrapper, and fix mapping of shared_info page after the
change to map foreign pages by GMFN rather than MFN.
Signed-off-by: Keir Fraser <keir@xensource.com>
Actually the conflict between LAPIC ID 0x00 and IOAPIC ID 0x00
really doesn't matter even in a native system but we can avoid
any risk of a warning by shifting the LAPIC ID space by one.
Also the changeset fixes construction of the MADT (LAPIC info
was overwriting the IOAPIC info) so we can now boot with ACPI
MADT again.
Signed-off-by: Keir Fraser <keir@xensource.com>
1. Override ISA IRQs 5,6,10,11 as active-low level-triggered.
These are 'wired' to PCI devices.
2. Limit PCI-ISA link routers to route to 5,6,10,11. Others
are active-high edge-triggered and so invalid to use for
PCI devices. In any case, four ISA IRQs is sufficient to
avoid unnecessary aliasing among four links.
Also remove PCI device 0 IRQ info. It's an embedded host bridge with
no interrupt sources.
Signed-off-by: Keir Fraser <keir@xensource.com>
TODO:
1. Fix IO-APIC ID to not conflict with LAPIC IDS.
2. Fix i8259 device model (seems to work already though!).
3. Add INTSRC overrides in MPBIOS and ACPI tables so
that PCI legacy IRQ routing always ends up at an
IO-APIC input with level trigger. Restricting link
routing to {5,6,10,11} and setting overrides for all
four of those would work.
Signed-off-by: Keir Fraser <keir@xensource.com>
Avoids possible vga driver loading problem in HVM Windows guest.
Also fixes a Makefile bug in hvmloader directory.
Signed-off-by: Qing He <qing.he@intel.com>
The bug occurs when the guest is entering protected mode and reaches
the far jump to set up the 32-bit segment registers for the virtual
VMENTER we're about to perform. vmxassist, in protected_mode(), looks
at the segment registers, which might be 16-bit segments or might be
32-bit segment selectors at this stage (depending on whether the OS
has reloaded them since entering protected mode); and it tries to load
the segments from the GDT. Unconditionally. Even if the segment
register still actually contains a real mode 16-bit segment. Whoops.
vmxassist already has code to detect 16-bit segments that survived
unmodified from a transition into and out of protected mode, and to
save and restore those appropriately. It does this using
"saved_rm_regs", which get cleared on entry to protected mode, and
then set to the old segment value if we fail to set a given 32-bit
segment correctly.
The fix is to save the 16-bit segments *always*, on entry to protected
mode when %CR0(PE) is first set; and to clear the saved 16-bit segment
and set the 32-bit variant in oldctx whenever a 32-bit segment
descriptor is set during the transition to 32-bit CS. Then, when we
finally do the VMENTER, we will set up the VMCS from only the 32-bit
segments, clearing the VMCS entries for segments that have not been
assigned valid 32-bit segments yet.
Tested on various RHEL-5 boot.isos, including ones which worked before
and ones which triggered the bug; all now boot correctly.
Signed-off-by: Stephen Tweedie <sct@redhat.com>
and extra code in hvm_vcpu_initialise(). Remove 'apic' config
option -- HVM CPUs will always have an APIC (which should be
set up in virtual wire mode for backward compatibility, just as
in a real system).
Signed-off-by: Keir Fraser <keir@xensource.com>
parse HVM e820 tables in Xen (add some extra HVM parameters as a
cleaner alternative). Lots of code removal.
Signed-off-by: Keir Fraser <keir@xensource.com>
directory pending tighter integration of table generation
into hvmloader. This patch also includes the TPM TIS SSDT
generator from Stefan Berger at IBM.
Signed-off-by: Keir Fraser <keir@xensource.com>
We found Vista polls ACPI timer very frequently (about 15 times
averagely) when handling timer (RTC @ 64HZ) interrupt routine. Though
the exact reason is known, it should be related to system time
adjustment. When it's in Qemu, the overhead is big. After moving,
Vista's idle overhead decreases dramatically from ~10% to 0.9%.=20
Another benefit is that Vista can only pass Performance rating with
this patch. The root cause is that ACPI timer in Qemu isn't
synchronous with other platform timer in HV, which results in Vista
complains "can't measure TSC frequency".
This patch changes vpit.h to vpt.h, for it not only has pit structure
in it, but other platform timer's structure. Another change is moving
ACPI timer and related address from acpi.h to ioreq.h, which can be shared
by HV and ACPI firmware.
Signed-off-by: Xiaowei Yang <xiaowei.yang@intel.com>
Address space access limit in VMXAssist is 4G, because IA-32 only has
4GB virtual address space which VMXassist can use to map physical
memory. The issue is, win2k3 server with more than 4G memory will put
AP GDT above 4G, so when AP changes its mode from real mode to PAE
paging mode, the long jump instrction it uses need access AP GDT
entries which resides above 4G, but because of this constraint, it can
not access GDT and so fails boot.
Signed-off-by: Xin Li <xin.b.li@intel.com>
1. GNU ld does not understand -m{32,64}. It must be cooked for it by
the GCC driver program.
2. Where GNU ld is directly called we must use -melf_{i386,x86_64}.
3. We cannot avoid calling GNU ld directly in some cases (e.g., when
specifying GNU-specific linker scripts) as on some host
architectures the GCC driver is configured to call the host
linker.
4. We cannot add -melf_{i386,x86_64} to LDFLAGS as the option is
not recognised by GCC.
Hence we define new LDFLAGS_DIRECT, to be added to the command line
only when invoking GNU ld directly.
Signed-off-by: Keir Fraser <keir@xensource.com>
