All BIOSes but ROMBIOS needs to be loaded via modules.
ROMBIOS is handled as a special case.
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
... and do not include the SeaBIOS ROM into hvmloader anymore.
This also fix the dependency on roms.inc, hvmloader.o does not include it.
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
The BIOS blob can be found an entry called "firmware" of the modlist of
the hvm_start_info struct.
The found BIOS blob is not loaded by this patch, but only passed as
argument to bios_load() function.
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
The path to the BIOS blob can be overriden by the xl's
bios_path_override option, or provided by u.hvm.bios_firmware in the
domain_build_info struct by other libxl user.
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
Acked-by: Wei Liu <wei.liu2@citrix.com>
Those paths are to be used by libxl, in order to load the firmware in
memory. If a system path is not defined via --with-system-seabios or
--with-system-ovmf, then default to the Xen firmware directory.
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Acked-by: Wei Liu <wei.liu2@citrix.com>
... and load BIOS/UEFI firmware into guest memory.
This adds a new firmware module, system_firmware_module. It is loaded in
the guest memory and final location is provided to hvmloader via the
hvm_start_info struct.
This patch create the hvm_start_info struct for HVM guest that have a
device model, so this is now common code with HVM guest without device
model.
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
Acked-by: Wei Liu <wei.liu2@citrix.com>
This patch use xc_dom_alloc_segment() to allocate the memory space for the
ACPI modules and the SMBIOS modules. This is to replace the arbitrary
placement of 1MB (+ extra for MB alignement) after the hvmloader image.
This patch can help if one add extra ACPI table and hvmloader contain
OVMF (OVMF is a 2MB binary), as in that case the extra ACPI table could
easily be loaded past the address 4MB, but hvmloader use a range of
memory from 4MB to 10MB to perform tests and in the process, clears the
memory, before loading the modules.
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
Acked-by: Wei Liu <wei.liu2@citrix.com>
This is a side-effect of commit c36e1c, which currently prevents compiling
xenalyze with libcs that don't have argp built-in.
Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
Acked-by: George Dunlap <george.dunlap@citrix.com>
Acked-by: Wei Liu <wei.liu2@citrix.com>
Instead of having several representation of hvm_start_info in C, define
it in public/arch-x86/hvm/start_info.h so both libxc and hvmloader can
use it.
Also move the comment describing the binary format to be alongside the
C struct.
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Wei Liu <wei.liu2@citrix.com>
Certain opcodes would so far not have got #UD when a LOCK prefix was
present. Adjust this by
- moving the too early generic check into destination operand decoding,
where DstNone and DstReg already have respective handling
- switching source and destination of TEST r,r/m, for it to be taken
care of by aforementioned generic checks
- explicitly dealing with all forms of CMP, SHLD, SHRD, as well as
TEST $imm,r/m
To make the handling of opcodes F6 and F7 more obvious, reduce the
amount of state set in the table, and adjust the respective switch()
statement accordingly.
Also eliminate the latent bug of the check in DstNone handling not
considering the opcode extension set.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
Just like said in commit c0bc0adf24 ("x86emul: use DstEax where
possible"): While it avoids just a few instructions, we should
nevertheless make use of generic code as much as possible. Here we can
arrange for that by simply introducing SrcEax (which requires no other
code adjustments).
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
This was meant to be numerically sorted (with reasonable exceptions),
but we've manage to diverge from that.
No functional change, only code movement.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
Slightly extending the emulate_2op*() macro machinery makes it usable
for IMUL r,r/m too, which has the benefit of smaller source code and
the EFLAGS output being guaranteed to match actual hardware behavior.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
Just like said in commit c0bc0adf24 ("x86emul: use DstEax where
possible"): While it avoids just a few instructions, we should
nevertheless make use of generic code as much as possible.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
Qemu needs access to this for the domain it controls, both due to it
being used by xc_domain_memory_mapping() (which qemu calls) and the
explicit use in hw/xenpv/xen_domainbuild.c:xen_domain_poll(). Extend
permissions to that of any "ordinary" domctl: A domain controlling the
targeted domain can invoke this operation for that target domain (which
is being achieved by no longer passing NULL to xsm_domctl()).
This at once avoids a for_each_domain() loop when the ID of an
existing domain gets passed in.
Reported-by: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com>
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
As of commit a800e4f611 ("x86emul: drop pointless and add useful
default cases") we no longer need the early bailing when "d == 0" (the
default cases in the main switch() statements take care of that),
removal of which renders both callers of internal_error() wrong and
SrcInvalid useless. Drop them, as they're going to get in the way of
completing the decoder to cover all known insns (to allow it to be
used by more callers) without at the same time completing the actual
emulation logic.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
Moving ahead the "early operand adjustments" logic, the "test $imm,r/m"
special logic in the determination of the instruction boundary is no
longer necessary.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
As of commit 989cdfa9b4 ("x86emul: don't special case fetching unsigned
8-bit immediates") the conditional being removed has been always false.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
... and use it for RET, LRET, and ENTER processing to limit the amount
of "manual" insn bytes fetching. Note that for the RET and LRET paths
the change utilizes that SrcImplicit (aka SrcNone) table entries leave
src.val as zero.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
Besides being more logical this also allows verifying correct recording
of alignments in .o files.
The cpu0_stack related ASSERT() in xen.lds.S is now of questionable
value (as it now verifies correct tool chain behavior), but I've left
it in nevertheless.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
The initial size check in xen_build_id_check() came too late (after the
first access to the structure), but was mostly redundant with checks
done in all callers; convert it to a properly placed ASSERT(). The
"mostly" part being addressed too: xen_build_init() was off by one.
And then there was a stray semicolon.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
While it avoids just a few instructions, we should nevertheless make
use of generic code as much as possible.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
These can be made work using SrcImmByte, making sure the low 8 bits of
src.val get suitably zero extended upon consumption. SHLD and SHRD
require a little more adjustment: Their source operands get changed
away from SrcReg, handling the register access "manually" instead of
the insn byte fetching.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
Make all paths leading to the "push" label have the Mov flag set, and
ASSERT() that to be the case. For the opcode FF group the adjustment is
benign for the paths not leading to "push", as they all set dst.type to
OP_NONE
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
These immediates follow the standard patterns in all modes, so they're
better fetched by the generic source operand handling code.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
These immediates follow the standard patterns in all modes, so they're
better fetched by the generic source operand handling code.
To facilitate testing, instead of adding yet another of these pretty
convoluted individual test cases, simply introduce another blowfish run
with -mno-accumulate-outgoing-args (the additional -Dstatic is to
keep the compiler from converting the calling convention to
"regparm(3)", which I did observe it does).
To make this introduction of a new blowfish pass (and potential further
ones later one) have less impact on the readability of the final code,
abstract all such "binary blob" executions via a table to iterate
through.
The resulting native code execution adjustment also uncovered a lack of
clobbers on the asm() in the 64-bit case, which is being fixed at once.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
Vm_event_vcpu_pause() needs to use vcpu_pause_nosync() in order
for the current vCPU to not get stuck. A consequence of this is
that the custom vm_event response handlers will not always see
the real vCPU state in v->arch.user_regs. This patch makes sure
that the state is always synchronized in vm_event_resume, before
any handlers have been called. This problem especially affects
vm_event_set_registers().
Simply checking vm_event_pause_count to make sure the vCPU is
paused suffices since there's only one ring / consumer at a
time, and events are being processed one-by-one, so the
toolstack won't unpause the vCPU behind our backs.
Signed-off-by: Razvan Cojocaru <rcojocaru@bitdefender.com>
Acked-by: Tamas K Lengyel <tamas@tklengyel.com>
The undefined behaviour sanitiser shows that it really is NULL via the
pre_initcall path.
(XEN) ================================================================================
(XEN) UBSAN: Undefined behaviour in cpufreq.c:158:66
(XEN) member access within null pointer of type 'struct processor_pminfo'
(XEN) ----[ Xen-4.8-unstable x86_64 debug=y Not tainted ]----
<snip>
(XEN) [<ffff82d0801c4231>] cpufreq_add_cpu+0x161/0xdc0
(XEN) [<ffff82d0801c6610>] cpufreq.c#cpu_callback+0x20/0x30
(XEN) [<ffff82d0804eefad>] cpufreq.c#cpufreq_presmp_init+0x2d/0x50
(XEN) [<ffff82d0804c5942>] do_presmp_initcalls+0x22/0x30
(XEN) [<ffff82d08051852d>] __start_xen+0x378d/0x42f0
(XEN) [<ffff82d080100073>] __high_start+0x53/0x60
Fix two other occurances of the same buggy logic.
The processor_pminfo[] objects are only allocated as a result of
XENPF_set_processor_pminfo hypercalls, which means that this early cpu
callback will always hit the early NULL check, and is therefore pointless.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
The undefined behaviour sanitiser in Clang 3.8 identifies that these are all
misaigned when used in __start_xen().
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
That line doesn't reveal much information to ordinary users.
Change that to debug output.
Signed-off-by: Wei Liu <wei.liu2@citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
- drop the only left CONFIG_NUMA conditional (this is always true)
- drop struct node_data's node_id field (being always equal to the
node_data[] array index used)
- don't open code node_{start,end}_pfn() nor node_spanned_pages()
except when used as lvalues (those could be converted too, but this
seems a little awkward)
- no longer open code pfn_to_paddr() in an expression being modified
anyway
- make dump less verbose by logging actual vs intended node IDs only
when they don't match
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
When node zero has no memory, the DMA bit width will end up getting set
to 9, which is obviously not helpful to hold back a reasonable amount
of low enough memory for Dom0 to use for DMA purposes. Find the lowest
node with memory below 4Gb instead.
Introduce arch_get_dma_bitsize() to keep this arch-specific logic out
of common code.
Also adjust the original calculation: I think the subtraction of 1
should have been part of the flsl() argument rather than getting
applied to its result. And while previously the division by 4 was valid
to be done on the flsl() result, this now also needs to be converted,
as is should only be applied to the spanned pages value.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Julien Grall <julien.grall@arm.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
The mkelf32 executable was using an uninitialized stack buffer for
padding after the ehdr and phdr are written to the xen file, which
leads to non-deterministic bytes in the binary and prevented Xen
hypervisors from being reproducibly built.
Additionally, the file was then compressed with gzip -9 without the
-n | --no-name flag, which lead to the xen.gz file having
non-deterministric bytes (the timestamp) in the compressed file.
Signed-off-by: Trammell Hudson <trammell.hudson@twosigma.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
We need to check for older PMU MSR range when emulating MSR
accesses for PV guests.
Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
The checksums should be calculated using unsigned 32bit integers, as they are
intended to overflow and end at 0. Replace some other signed integers with
unsigned ones, to avoid mixed-sign comparisons.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Kevin Tian <kevin.tian@intel.com>
For d->shutdown_code, change the field to being unsigned and using an unsigned
sentinel. The sentinal needs to be distinguishable from any value
representable in a u8.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: George Dunlap <george.dunlap@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
c/s 2e426d6 "x86/traps: Drop use_error_code parameter from do_{,guest_}trap()"
introduced an assertion which covered the correctness of shifting 1u by an
input parameter.
While all other inputs provide a constants vector, the `int $N` handling path
from do_general_protection() passes any vector.
This path is triggered by XTF, which uses `int 0x20` to facilitate returning
to kernel mode after running specific tests in user mode.
No vectors above 32 have an error code, so adjust the logic to cope.
Reported-by: Wei Liu <wei.liu2@citrix.com>
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
We'd need to update other routines' definitions. However, acpi_config
is not really a const since new_vm_gid() wants to update
acpi_config.vm_gid_addr.
Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Initialize it in hvmloader, avoiding ACPI code's use of xenstore_read()
Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>