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>
Rather than building the tables twice, once purely to figure out the
size, just allocate each individual table as we go.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
1024 bytes create a lot of wastage when the majority of allocations
are of BIOS table data structures which are generally happy with much
lower alignment. I conservatively chose 16 bytes.
Most callers pass 0 for the alignment anyway, for the rombios high
code allocation I kept it 1024 byte aligned since it was the only case
that didn't seem obviously ok with a smaller alignment.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Build the various BIOS tables and arrange for them to be passed to
SeaBIOS. We define a simple data structure structure at a known
physical address for this purpose.
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>
There is an implicit assumption in the PCI spec that the primary VGA
device (e.g. something with class==VGA) will have I/O enabled in order
to make the standard VGA I/O registers (e.g. at 0x3xx) available, even
though the device has no explicit I/O BARS.
The qemu device model for the Cirrus VGA card does not actually
enforce this but SeaBIOS looks for a VGA device with I/O enabled
before running the VGA ROM. Coreboot has similar behaviour and I
verified on a physical Cirrus GD 5446 that the BIOS had enable I/O
cycles.
The thread at
http://www.seabios.org/pipermail/seabios/2011-May/001804.html
contains more info.
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>
Windows SVVP tests require an HPET table even if the HPET is disabled.
This makes sense since the HPET _is_ in the DSDT and, while the OS
does not know that, in principle it's status may change.
(For what it's worth SeaBIOS, in addition to doing this, totally
ignores QEMU's -no-hpet flag and always reports 0x0f for the HPET's
_STA method).
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Keir Fraser <keir@xen.org>
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>
Executing UD2 (invalid opcode) triggers a triple fault which signals
reboot to the toolstack, rather than crash.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Signed-off-by: Keir Fraser <keir@xen.org>
Also, generate roms.inc file in a scratch location and then move in
place. This is more reliable if make is terminated at an arbitrary
point.
Signed-off-by: Keir Fraser <keir@xen.org>
Allow the toolstack to select the BIOS to use via a xenstore key.
Defaults to "rombios" for compatibility with toolstacks which do not
write the key (e.g. xend).
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Signed-off-by: Keir Fraser <keir@xen.org>
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>
Add an option to use debug Cirrus video BIOS, simply as a convenience.
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>
Instead of hardcoding in a header.
Reduces the cross talk between ROMBIOS and hvmloader.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Keir Fraser <keir@xen.org>
Instead of hardcoding in a header.
Reduces the cross talk between ROMBIOS and hvmloader.
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>
It's not needed unless you are including headers in the current
directory _and_ you can't use "" instead of <> because the headers are
to be installed.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
Otherwise make can search the path relative to certain standard paths
such as /usr/include (e.g., the line '-include $(XEN_ROOT)/.config' in
Config.mk suffers from this).
Signed-off-by: Keir Fraser <keir@xen.org>
1. Remove unportable O and D format specifiers
2. Fix X format specifier to print upper-case hex characters
3. Fix d format specifier to print -ve numbers
4. Fix handling of int vs. long (although not actually an issue
for the i386 compile target)
5. Don't use the antiquated C 'register' type attribute.
Signed-off-by: Keir Fraser <keir@xen.org>
Keir Fraser
Ian Campbell
Paolo Bonzini