The Intel GPU uses a two pages NVS region called OpRegion.
In order to get full support for the driver in the guest
we need to map this region.
This patch reserves 2 pages on the top of the memory in the
reserved area and mark this region as NVS in the e820. Then
we write the address to the config space (offset 0xfc) so the
device model can map the OpRegion at this address in the guest.
Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
Committed-by: Keir Fraser <keir@xen.org>
This avoids a conflict with SeaBIOS's memory management. Moreover
there is no reason that acp_info must live below 1MB, and moving it
out actually simplifies our code.
Signed-off-by: Keir Fraser <keir@xen.org>
SeaBIOS will reserve memory in the e820 as necessary, including BIOS
data structures such as the EBDA, any tables it creates or copies into
pleace etc. Therefore arrange that the memory map provided by
hvmloader to SeaBIOS reserves only things which HVMloader has created.
Since ROMBIOS is more tightly coupled with hvmloader we retain the
ability to reserve BIOS regions in the hvmloader produced e820 and use
that from the ROMBIOS backend.
The code for this could probably have been simpler but the existing
code avoids overlapping e820 areas and so the new code does the same
(many guest OSes sanitize the e820 map to handle this, but I wouldn't
trust that all do, so I didn't take the risk)
For ROMBIOS the resulting e820 map as seen by the guest is the same
except the reserved regions at 0x9e000-0x9fc00,0x9fc00-0xa0000 are
merged into a single region 0x9e000-0xa0000 (Linux guests sanitize the
e820 to look like this anyway).
For SeaBIOS the result is that the lowmem reserved region is from
0x9f000-0xa0000 rather than 0x9e000-0xa0000 which correctly reflects
SeaBIOS's actual usage.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
I mistakenly thought that the "struct bios_info" was a ROMBIOS
specific data structure and so caused it to be populated only in the
ROMBIOS case.
However it turns out that the majority of the struct's fields are
actually referenced from the ACPI DSDT and hence are needed for
SeaBIOS too.
While in principal it might have been possible to continue to mix
ROMBIOS and ACPI bits in this datastructure this is, evidently,
confusing but also leads to header file dependencies from
ROMBIOS->hvmloader which I had been hoping to avoid so as to head-off
future accidental re-entanglement of ROMBIOS and hvmloader.
So instead I have split the ACPI parts into a new "struct acpi_info"
which is defined entirely within the acpi building code in hvmloader
and which comes with a big comment pointing to the DSDT interaction.
This new ACPI info is placed at 0x9F000 which is available under both
ROMBIOS and SeaBIOS. This address is in a reserved region of the E820
and is just above the ROMBIOS stack.
The resulting "struct rombios_info" is hardly worthy of its own
structure but keep it anyway.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Currently we have ->bios_high_setup, which is called relatively early
and returns a cookie which is passed to ->bios_info_setup which runs
towards the end and creates the BIOS info, incorporating the cookie
which (in the case of ROMBIOS) happens to be the BIOS's high load
address . This is rather ROMBIOS specific.
Refactor to have ->bios_info_setup which is called early and prepares
the bios_info, ->bios_relocate which does any necessary relocation
(updating the BIOS info as necessary) and ->bios_info_finish which
finalises the info (e.g. by calculating the checksum).
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Returns memory which is passed to the subsequent BIOS but can be
reused once the contents is consumed. An example of this would be a
BIOS table which the BIOS consumes by copying rather than simply
referencing.
Users which need a temporary scratch buffer for internal use
scratch_start which follows these allocations.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
SeaBIOS has functionality to load ROMs from the PCI device directly,
it makes sense to use this when it is available.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
The SeaBIOS integration here is only semi-complete and is targetted at
developers and very early adopters who can be expected to cope with
some rough edges. In particular the user must clone, patch as
necessary and compile SeaBIOS themselves since this patchset does not
cover any of that (in the same way we currently do not integrate
upstream qemu clone+build). Include a big comment to that effect next
to the Config.mk option.
Many of the bios_config callback functions are not yet used by
SeaBIOS.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Ian Jackson <ian.jackson.citrix.com>
Committed-by: Ian Jackson <ian.jackson.citrix.com>
For now abstract away the actual ROM bits themselves and the various
load addresses.
Create a rombios.c to contain the ROMBIOS specific parts. ROMBIOS is
still statically selected for the time being.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Keir Fraser <keir@xen.org>
Although happen to live at the same physical address their lifespans
do not overlap. The scratch and hypercall spaces are used only within
hvmloader and the same area is reused as a heap within ROMBIOS. But
each is free to make its own decisions about where to place things.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Keir Fraser <keir@xen.org>
Pass the table address as a paramter to the build function and cause
it to return the number of entries. Pass both base and offset as
parameters to the dump function.
This adds a duplicated e820.h header to ROMBIOS. Since the e820 data
structure is well defined by existing BIOS implementations I think
this is OK and simplifies the cross talk between hvmloader and
ROMBIOS.
Reduces the cross talk between ROMBIOS and hvmloader.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Keir Fraser <keir@xen.org>
Currently rombios and hvmloader are rather intertwined. Separate the
ROMBIOS configuration options out into a ROMBIOS provided file so that
the dependency can become strictly from hvmloader to rombios.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Keir Fraser <keir@xen.org>
accordingly
-- currently firmware has got 'vcpus' from xend, this patch add parse
'vcpu_avail' to firmware;
-- setup madt 'lapic' subitems of processors accoring to vcpus and
vcpu_avail which finally come from config;
Signed-off-by: Liu, Jinsong <jinsong.liu@intel.com>
Signed-off-by: Keir Fraser <keir.fraser@citrix.com>
In order to support HVM vcpu add/remove, we need set dsdt
infrastructure.
-- By using mk_dsdt.c, it auto-produce related asl code when
compiling.
-- It define processor related objects and control methods (_MAT,
_EJ0, _STA, etc).
-- It also define GPE _L02 and Notify control method for SCI
interrupt, which will trigger HVM acpi driver to add/remove cpu.
Signed-off-by: Liu, Jinsong <jinsong.liu@intel.com>
Signed-off-by: Keir Fraser <keir.fraser@citrix.com>
This gets rid of shenanigans with relocating the jump table around the
place.
Also clean up bios_info table while we are updating it.
Signed-off-by: Keir Fraser <keir.fraser@citrix.com>
To make memory management easier in hvmloader, defer building a
generic E820 map until the end of hvmloader bootstrap.
Signed-off-by: Keir Fraser <keir.fraser@citrix.com>
hvm_info_table to describe memory parameters in a simpler form from
domain builder to hvmloader.
Also move reserved special page mappings immediately below the 4GB
boundary.
Signed-off-by: Keir Fraser <keir.fraser@citrix.com>
BIOS. Current Xen hard coded VGA ROM at 0xC0000 and etherboot ROM
at 0xD0000. This makes the space in [0xC0000 - 0xDFFFF] to be
fragments, which makes it hard to find enough space to hold another
Option ROM.
Signed-off-by: Shan Haitao <haitao.shan@intel.com>
Device model is not present in external qemu repository, and
functionality was never exposed through the toolstack.
Signed-off-by: Keir Fraser <keir.fraser@citrix.com>
* Cleanly define a scratch area for temporary storage
* Raise Etherboot ROM out of the way of larger VGA BIOSes
Also detect virtual VGA adaptors more cleanly.
Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
Signed-off-by: Keir Fraser <keir.fraser@citrix.com>
- Move MTRR MSR initialisation into hvmloader.
- Simplify initialisation logic by overlaying UC on default WB rather
than vice versa.
- Clean up hypervisor HVM MTRR/PAE code's interface with rest of
hypervisor.
Signed-off-by: Keir Fraser <keir.fraser@citrix.com>
This patch adds extboot to Xen. It should be pretty harmless as the
moment because it's never enabled. extboot allows arbitrary block
devices to be used to boot guests including SCSI and PV disks. I've
tested it with both Windows and Linux guests in QEMU.
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
Once the presence of LPT1 is baked into a Windows guest, it gets upset
if it is subsequently removed. Hence we add the 'LTP1' device object
back into the ACPI DSDT, and remove IRQ 7 from the list of IRQs usable
by the PCI-ISA links.
Signed-off-by: Keir Fraser <keir@xensource.com>
definition from the ACPI DSDT. This avoids conflict with FDC on IRQ6
(it is a bit more likely that someone will want to connect a floppy
image to a guest than it is that anyone will ever care about
parallel-port functionality).
Signed-off-by: Keir Fraser <keir@xensource.com>
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>
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>
Jean Guyader
Keir Fraser
Ian Campbell
Keir Fraser
kfraser@localhost.localdomain
kaf24@localhost.localdomain