| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
For one setup_max_pdx(), when invoked a second time (after SRAT got
parsed), needs to start from the original max_page value again (using
the already adjusted one from the first invocation would not allow the
cut-off boundary to be moved up).
Second, _if_ we need to cut off some part of memory, we must not allow
this to also propagate into the NUMA accounting. Otherwise
cutoff_node() results in nodes_cover_memory() to find some parts of
memory apparently not having a PXM association, causing all SRAT info
to be ignored.
The only possibly problematic consumer of node_spanned_pages (the
meaning of which gets altered here in that it now also includes memory
Xen can't actively make use of) is XEN_SYSCTL_numainfo: At a first
glance the potentially larger reported memory size shouldn't confuse
tool stacks.
And finally we must not put our boot time modules at addresses which
(at that time) can't be guaranteed to be accessible later. This applies
to both the EFI boot loader and the module relocation code.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Keir Fraser <keir@xen.org>
Acked-by: Dario Faggioli <dario.faggioli@citrix.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Namely with PFN compression, MMIO ranges that the firmware may need
runtime access to can live in the holes that gets shrunk/eliminated by
PFN compression, and hence no mappings would result from simply
copying Xen's direct mapping table's L3 page table entries. Build
mappings for this "manually" in the EFI runtime call 1:1 page tables.
Use the opportunity to also properly identify (via a forcibly undefined
manifest constant) all the disabled code regions associated with it not
being acceptable for us to call SetVirtualAddressMap().
Signed-off-by: Jan Beulich <jbeulich@suse.com>
|
| |
|
|
|
|
| |
Also clean up some cases of misused/opencoded ENTRY()
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Just like Linux did many years ago, move them into a separate (data)
section, such that they no longer pollute instruction caches and TLBs.
Assertion frames, requiring two pointers to be stored, occupy two slots
in the array, with the second slot mimicking a frame the location
pointer of which doesn't match any address within .text or .init.text
(it effectively points back to the slot itself, which - being in a data
section - can't be reached by non-buggy execution).
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Keir Fraser <keir@xen.org>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
efi/boot.c makes a call to QueryVariableInfo on all systems. However,
as it is only promised for UEFI 2.0+ systems, pre-UEFI systems can
hang or crash on this call. The below patch adds a version check, a
technique used in other parts of the Xen EFI codebase.
Signed-off-by: Eric Shelton <eshelton@pobox.com>
Check runtime services version instead of EFI version (while generally
they would be in sync, nothing requires them to be).
Signed-off-by: Jan Beulich <jbeulich@suse.com>
|
| |
|
|
|
|
|
|
|
| |
... after f6254405 ("xen/arm: compile and initialize vmap") moving the
map_pages_to_xen() declaration.
Reported-by: Olaf Hering <olaf@aepfle.de>
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
|
| |
|
|
|
|
|
|
| |
clean target is never called from xen/arch/x86/efi/Makefile.
Move all needed stuff to xen/arch/x86/Makefile
and additionally remove efi.lds.
Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
|
| |
|
|
|
|
|
|
| |
The top two bits (indicating error/warning classification) need to
remain the top two bits.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Keir Fraser <keir@xen.org>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
EFI variables can be flagged as being accessible only within boot services.
This makes it awkward for us to figure out how much space they use at
runtime. In theory we could figure this out by simply comparing the results
from QueryVariableInfo() to the space used by all of our variables, but
that fails if the platform doesn't garbage collect on every boot. Thankfully,
calling QueryVariableInfo() while still inside boot services gives a more
reliable answer. This patch passes that information from the EFI boot stub
up to the efi platform code.
Based on a similarly named Linux patch by Matthew Garrett <matthew.garrett@nebula.com>.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Keir Fraser <keir@xen.org>
Acked-by: George Dunlap <george.dunlap@eu.citrix.com>
|
| |
|
|
|
|
|
|
| |
... from gnu-efi-3.0t. Decode a few of them in x86's PrintErrMesg().
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Keir Fraser <keir@xen.org>
Acked-by: George Dunlap <george.dunlap@eu.citrix.com>
|
| |
|
|
|
|
|
|
|
|
| |
This must have been a copy-and-paste mistake - get_variable uses
op->misc as output only, and wants to make sure it's zero for future
extensibility. For set_variable, this is an input though, and hence
the check is wrong.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Keir Fraser <keir@xen.org>
|
| |
|
|
|
|
|
|
|
| |
While putting together the kernel side of this I realized that c/s
26397:d9c7b82aa7b1 went a little too far in requiring a buffer for the
option ROM contents - all that is really needed is handing Dom0
physical address and size of the data block.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
This mainly involves adjusting the number of L4 entries needing copying
between page tables (which is now different between PV and HVM/idle
domains), and changing the cutoff point and method when more than the
supported amount of memory is found in a system.
Since TMEM doesn't currently cope with the full 1:1 map not always
being visible, it gets forcefully disabled in that case.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Keir Fraser <keir@xen.org>
Acked-by: Dan Magenheimer <dan.magenheimer@oracle.com>
|
| |
|
|
|
|
|
|
|
| |
Linux 3.8-rc added code to do this, so we need to support this in the
hypervisor for Dom0 to be able to get at the same information as a
native kernel.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Keir Fraser <keir@xen.org>
|
| |
|
|
|
|
|
|
|
|
|
| |
Short of a solution to the problem described in
http://lists.xen.org/archives/html/xen-devel/2012-12/msg00648.html,
deal with the bad effect this together with c/s 25751:02b4d5fedb7b has
on the EFI build by filtering out the problematic command line items.
Signed-off-by: Charles Arnold <carnold@suse.com>
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Committed-by: Jan Beulich <jbeulich@suse.com>
|
| |
|
|
|
|
|
|
|
| |
... to validate the kernel image (which is required to be in PE
format, as is e.g. the case for the Linux bzImage when built with
CONFIG_EFI_STUB).
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Keir Fraser <keir@xen.org>
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Note: these changes don't make any difference on x86.
Replace XEN_GUEST_HANDLE with XEN_GUEST_HANDLE_PARAM when it is used as
an hypercall argument.
Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Keir Fraser <keir@xen.org>
Committed-by: Ian Campbell <ian.campbell@citrix.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Namely when making use the CONFIG_XEN_COMPAT_* options in the legacy
Linux kernels, newer kernels may not be compatible with older
hypervisors, so trying to boot such a combination makes little sense.
Booting older kernels on newer hypervisors, however, has to always
work.
With the way xen.efi looks for its configuration file, allowing
individual configuration files to refer only to compatible kernels,
and referring from an older- to a newer-hypervisor one (the kernels
of which will, as said, necessarily be compatible with the older
hypervisor) allows to greatly reduce redundancy at least in
development environments where one frequently wants multiple
hypervisors and kernles to be installed in parallel.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Keir Fraser <keir@xen.org>
|
| |
|
|
|
|
|
|
| |
... rather than at boot time, removing unnecessary redundancy between
EFI and legacy boot code.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Keir Fraser <keir@xen.org>
|
| |
|
|
|
|
|
|
| |
... rather than at boot time, removing unnecessary redundancy between
EFI and legacy boot code.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Keir Fraser <keir@xen.org>
|
| |
|
|
|
|
|
|
|
| |
As a prerequisite for adding an EHCI debug port based console
implementation, set up the page tables needed for (a sub-portion of)
the fixmaps together with other boot time page table construction.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Keir Fraser <keir@xen.org>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Without this, the compilation of check.c could fail due to compiler
features such as -fstack-protector being enabled, which causes a
missing __stack_chk_fail symbol error.
Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Rather than using plain CFLAGS here, remove CFLAGS-y from them to
particularly get rid of the -MF argument referencing (the undefined
here) $(@F).
The use of CFLAGS at once allows dropping the explicit use of -Werror.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Committed-by: Jan Beulich <jbeulich@suse.com>
|
| |
|
|
|
|
|
|
| |
This eliminates pointless prologue code from functions having variable
argument lists (since that way xmm registers can't possibly be passed).
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Keir Fraser <keir@xen.org>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Largely as a result of the continuing resistance of Linux maintainers
to accept a microcode loading patch for pv-ops Xen kernels, this
follows the suggested route and provides a means to load microcode
updates without the assistance of Dom0, thus also addressing eventual
problems in the hardware much earlier.
This leverages the fact that via the multiboot protocol another blob
of data can be easily added in the form of just an extra module. Since
microcode data cannot reliably be recognized by looking at the
provided data, this requires (in the non-EFI case) the use of a
command line parameter ("ucode=<number>") to identify which of the
modules is to be parsed for an eventual microcode update (in the EFI
case the module is being identified in the config file, and hence the
command line argument, if given, will be ignored).
This required to adjust the XSM module determination logic accordingly.
The format of the data to be provided is the raw binary blob already
used for AMD CPUs, and the output of the intel-microcode2ucode utility
for the Intel case (either the per-(family,model,stepping) file or -
to make things easier for distro-s integration-wise - simply the
concatenation of all of them).
In order to not convert the spin_lock() in microcode_update_cpu() (and
then obviously also all other uses on microcode_mutex) to
spin_lock_irqsave() (which would be undesirable for the hypercall
context in which the function also runs), the boot time handling gets
done using a tasklet (instead of using on_selected_cpus()).
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Keir Fraser <keir@xen.org>
|
| |
|
|
|
|
|
|
|
|
| |
Flesh out the interface to EFI 2.0 runtime calls and implement what
can reasonably be without actually having active call paths getting
there (i.e. without actual debugging possible: The capsule interfaces
certainly require an environment where an initial implementation can
actually be tested).
Signed-off-by: Jan Beulich <jbeulich@suse.com>
|
| |
|
|
|
|
|
| |
Updates from gnu-efi 3.0m. UEFI 2.0 runtime services additions taken
from EDK 1.06.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
|
| |
|
|
|
|
|
| |
In the absence of a BIOS to handle INT13 requests, this information
must be constructed artificially instead when booted from EFI.
Signed-off-by: Jan Beulich <jbeulich@novell.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
In order to eliminate an initial hack in the EFI boot code (where
memory for the trampoline was just "claimed" instead of properly
allocated), the trampoline code must no longer make assumption on the
address at which it would be located. For the time being, the fixed
address is being retained for the traditional multiboot path.
As an additional benefit (at least from my pov) it allows confining
the visibility of the BOOT_TRAMPOLINE definition to just the boot
code.
Signed-off-by: Jan Beulich <jbeulich@novell.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Since RTC/CMOS accesses aren't atomic, there are possible races
between code paths setting the index register and subsequently
reading/writing the data register. This is supposed to be dealt with
by acquiring rtc_lock, but two places up to now lacked respective
synchronization: Accesses to the EFI time functions and
smpboot_{setup,restore}_warm_reset_vector().
This in turn requires no longer directly passing through guest writes
to the index register, but instead using a machanism similar to that
for PCI config space method 1 accesses.
Signed-off-by: Jan Beulich <jbeulich@novell.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
runtime.c: In function 'efi_rs_enter':
runtime.c:45:5: error: implicit declaration of function 'irq_enter'
[-Werror=implicit-function-declaration]
runtime.c:45:5: error: nested extern declaration of 'irq_enter'
[-Werror=nested-externs]
runtime.c: In function 'efi_rs_leave':
runtime.c:75:5: error: implicit declaration of function 'irq_exit'
[-Werror=implicit-function-declaration]
runtime.c:75:5: error: nested extern declaration of 'irq_exit'
[-Werror=nested-externs]
Signed-off-by: Olaf Hering <olaf@aepfle.de>
|
| |
|
|
|
|
|
|
| |
The missing piece was the setting up of an accessible GDT prior to
switching page tables (and reverting to the original setting after
having established the normal page tables again afterwards).
Signed-off-by: Jan Beulich <jbeulich@novell.com>
|
| |
|
|
|
|
|
| |
It's not clear this is needed - Linux doesn't use the MPS table even
if available, and no system having one was seen so far.
Signed-off-by: Jan Beulich <jbeulich@novell.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This allows Dom0 access to all suitable EFI runtime services. The
actual calls into EFI are done in "physical" mode, as entering virtual
mode has been determined to be incompatible with kexec (EFI's
SetVirtualAddressMap() can be called only once, and hence the
secondary kernel can't establish its mappings). ("Physical" mode here
being quoted because this is a mode with paging enabled [otherwise
64-bit mode wouldn't work] but all mappings being 1:1.)
Open issue (not preventing this from being committed imo):
Page (and perhaps other) faults occuring while calling runtime
functions in the context of a hypercall don't get handled correctly
(they don't even seem to reach do_page_fault()). I'm intending to
investigate this further.
Signed-off-by: Jan Beulich <jbeulich@novell.com>
|
|
|
Besides introducing the relevant code paralleling parts of what is
under xen/arch/x86/boot/, this adjusts the build logic so that with a
single compilation two images (gzip-compressed ELF and EFI
application)
can get created. The EFI part of this depends on a new enough compiler
(supposedly gcc 4.4.x and above, but so far only tested to work with
4.5.x) and a properly configured linker (must support the i386pep
emulation). If either functionality is found to not be available, the
EFI part of the build will simply be skipped.
The patch adds all code to allow Xen and the (accordingly enabled)
Dom0 kernel to boot, but doesn't allow Dom0 to make use of EFI
runtime calls (this will be the subject of the next patch).
Parts of the code were lifted from an earlier never published OS
project of ours - whether respective license information needs to be
added to the respective source file is unclear to me (I was told
internally that adding a GPLv2 license header can be done if needed by
the community).
Open issues (not preventing this from being committed imo):
The trampoline allocation and initialization isn't really nice. This
is due to the trampoline needing to be placed at a fixed address, and
hence making the trampoline relocatable would seem desirable here (as
well as for BIOS-based booting, where the trampoline location needed
to be adjusted a number of time already in the past, due to it
colliding with firmware data).
By excluding mem.S, edd.S, and video.S from copied trampoline (i.e.
moving up wakeup.S? and making sure none of the symbols are used from
EFI code), the effective trampoline size could at least be reduced.
Should the mappings of [__XEN_VIRT_START, mbi.mem_upper) and
[_end, __XEN_VIRT_START+BOOTSTRAP_MAP_BASE) be destroyed, despite
non-EFI code also keeping them?
Signed-off-by: Jan Beulich <jbeulich@novell.com>
|
