These have broken the build and it seems to be difficult to fix. So
we will revert the whole lot for now, and await corrected patch(es).
Revert "fix the build when CONFIG_QEMU is specified by the user"
Revert "tools: fix permissions of git-checkout.sh"
Revert "scripts/git-checkout.sh: Is not bash specific. Invoke with /bin/sh."
Revert "Clone and build Seabios by default"
Revert "Clone and build upstream Qemu by default"
Revert "Rename ioemu-dir as qemu-xen-traditional-dir"
Revert "Move the ioemu-dir-find shell script to an external file"
Signed-off-by: Ian Jackson <ian.jackson@eu.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>
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>
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>
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>
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>
If you use -MMD -MF then the correct .o filename is written to the
.*.d file as the compiler driver arranges everything. This was done
in 19010:275abe1c5d24 for the hypervisor.
In this patch we do the same elsewhere in the xen-unstable tree,
particularly tools/. Specifically:
* Change tools/Rules.mk to add -MMD -MF ... to CFLAGS and set DEPS.
* Remove -Wp,-MD... from every other Makefile
* Remove setting of DEPS from every other Makefile
* Ensure that every Makefile says -include $(DEPS)
* Ensure that every Makefile's clean target removes $(DEPS)
Some Makefiles were already halfway there, but often for a different
variable name eg PROG_DEP. The variable name is now standardised in
Rules.mk as DEPS.
I have done a test build with this change, on Debian etch.
Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.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>
pass for the HVM guest to successfully boot.
Currently only one test (REP INS across page boundaries) but more will
be added in future.
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>
In particular:
- BIOS release date
- BIOS characteristics
- BIOS extended characteristics (Targeted Content Distribution is
required to be specified to pass WHQL).
- CPU speed
Based on a patch by Kamala Narasimhan <kamala.narasimhan@citrix.com>
Signed-off-by: Keir Fraser <keir.fraser@citrix.com>
tools/firmware/etherboot by default (the dependency of eb_roms.h on
Config does not seem to always prevent the build from going ahead, for
some reason).
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>
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>
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>
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>
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>
it to interrogate Xen version information. Also add support
for HVM hypercall execution on 64-bit host.
Signed-off-by: Steven Smith <ssmith@xensource.com>
Signed-off-by: Keir Fraser <keir@xensource.com>
Currently the ROMBIOS includes static MP tables for only four
configurations: 1-way, 2-way, 4-way, and 8-way.
This patch makes the creation of MP tables more dynamic by creating them
from within HVMLOADER based upon the VCPU number provided by the HVM
information table.
Note: Some of the information included used to create the MP tables is
still hard coded and based upon values used in the original ROMBIOS MP
tables. Data such as the CPU family/model/stepping information should
probably be made to match the information provided to the guest when
executing a CPUID.
Signed-off-by: Travis Betak <travis.betak@amd.com>