Write/read FS/GS base instructions enable user level code to
read/write FS & GS segment base registers for thread local storage.
Signed-off-by: Yang, Wei <wei.y.yang@intel.com>
Under certain conditions, if an IO gets into an unexpected state,
hvmemul_do_io can return X86EMUL_UNHANDLEABLE. Unfortunately,
handle_pio() does not expect this state, and calls BUG() if it sees
it, crashing the host.
Other HVM io-related code crashes the guest in this case. This patch
makes handle_pio() do the same.
The crash was seen when executing crash_guest in dom0 to forcibly
crash the guest.
Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>
This patch exposes ERMS feature to HVM and PV guests.
The REP MOVSB/STOSB instruction can enhance fast strings attempts to
move as much of the data with larger size load/stores as possible.
Signed-off-by: Yang, Wei <wei.y.yang@intel.com>
Experimental evidence shows that Extended Interrupt Mode remains in
effect even after Interrupt Remapping is disabled in each DMAR Global
Command Register. A consiquence of this is that when we switch from
x2apic mode back to xapic mode, and disable interrupt remapping for
the kdump kernel, interrupts passing through the IO APICs are in
x2apic format as opposed xapic. This causes a triple fault in the
kexec kernel.
As EIM is explicitly set up each time Interrup Remapping is enabled,
it is safe for us to clobber this when taring down.
Also, change the header definition of IRTA_REG_EIME_SHIFT. It caused
verbose and error-prone code, and was only used in 1 place before. We
now have IRTA_EIME which is the specific bit in the register.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Xen does not store the boot local APIC state which leads to problems
when shutting down for a kexec jump. This patch records the boot
state so we can return to the boot state when kexecing.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Signed-off-by: Keir Fraser <keir@xen.org>
Acked-by: Jan Beulich <jbeulich@novell.com>
This is a rare case, but if the BIOS is set to uniprocessor, and Xen
is booted with 'lapic x2apic', Xen will switch into x2apic mode, which
will cause a protection fault when disabling the local APIC. This
leads to a general protection fault as this code is also in the fault
handler.
When x2apic mode is enabled, the only tranlsation which does
not result in a protection fault is to clear both the EN and EXTD
bits, which is safe to do in all cases, even if you are in xapic
mode rather than x2apic mode.
The linux code from which this is derrived is protected by an
if ( ! x2apic_mode ...) clause which is how they get away with it.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Jan Beulich <jbeulich@novell.com>
AMD Fam15h processors have a shared cache. It does not need=20
to be be flushed when entering C3 and doing so causes reduces
performance. Modify acpi_processor_power_init_bm_check to
prevent these processors from flushing when entering C3.
Signed-off-by: Mark Langsdorf <mark.langsdorf@amd.com>
This patch exposes DRNG feature to HVM guests.
The RDRAND instruction can provide software with sequences of
random numbers generated from white noise.
Signed-off-by: Yang, Wei <wei.y.yang@intel.com>
Should check for VIRTUAL_INTR_PENDING as we unconditionally make use
of it. Also check for CR8 exiting unconditionally on x86/64, as this
is of use to nestedvmx, and every 64-bit cpu should support it.
Signed-off-by: Eddie Dong <eddie.dong@intel.com>
Signed-off-by: Keir Fraser <keir@xen.org>
The machine_to_phys_mapping[] array needs updating during page
deallocation. If that page is allocated again, a call to
get_gpfn_from_mfn() will still return an old gfn from another guest.
This will cause trouble because this gfn number has no or different
meaning in the context of the current guest.
This happens when the entire guest ram is paged-out before
xen_vga_populate_vram() runs. Then XENMEM_populate_physmap is called
with gfn 0xff000. A new page is allocated with alloc_domheap_pages.
This new page does not have a gfn yet. However, in
guest_physmap_add_entry() the passed mfn maps still to an old gfn
(perhaps from another old guest). This old gfn is in paged-out state
in this guests context and has no mfn anymore. As a result, the
ASSERT() triggers because p2m_is_ram() is true for p2m_ram_paging*
types. If the machine_to_phys_mapping[] array is updated properly,
both loops in guest_physmap_add_entry() turn into no-ops for the new
page and the mfn/gfn mapping will be done at the end of the function.
If XENMEM_add_to_physmap is used with XENMAPSPACE_gmfn,
get_gpfn_from_mfn() will return an appearently valid gfn. As a
result, guest_physmap_remove_page() is called. The ASSERT in
p2m_remove_page triggers because the passed mfn does not match the old
mfn for the passed gfn.
Signed-off-by: Olaf Hering <olaf@aepfle.de>
Intel new CPU supports SMEP (Supervisor Mode Execution Protection). SMEP
prevents software operating with CPL < 3 (supervisor mode) from fetching
instructions from any linear address with a valid translation for which the U/S
flag (bit 2) is 1 in every paging-structure entry controlling the translation
for the linear address.
This patch adds SMEP support to HVM guest.
Signed-off-by: Yang Wei <wei.y.yang@intel.com>
Signed-off-by: Shan Haitao <haitao.shan@intel.com>
Signed-off-by: Li Xin <xin.li@intel.com>
Signed-off-by: Tim Deegan <Tim.Deegan@citrix.com>
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>
Intel new CPU supports SMEP (Supervisor Mode Execution
Protection). SMEP prevents software operating with CPL < 3 (supervisor
mode) from fetching instructions from any linear address with a valid
translation for which the U/S flag (bit 2) is 1 in every
paging-structure entry controlling the translation for the linear
address.
This patch enables SMEP in Xen to protect Xen hypervisor from
executing pv guest instructions, whose translation paging-structure
entries' U/S flags are all set.
Signed-off-by: Yang Wei <wei.y.yang@intel.com>
Signed-off-by: Shan Haitao <haitao.shan@intel.com>
Signed-off-by: Li Xin <xin.li@intel.com>
Signed-off-by: Keir Fraser <keir@xen.org>
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>
The new feature introduced in 23401:a44b12ee2fd3 was broken; it in
general always fails, at least if there are no hotplug scripts.
If there are no hooks, call_hooks ends up running this:
[ -x ".....*.hook" ] && . "..... *.hook"
This does not directly trigger set -e and sigerr. However, it is the
last command exected in call_hooks. So the return status of
call_hooks is an error, and thus a sigerr happens when call_hooks
returns.
The bug affects xl and xm. However xl does not detect failure of the
hotplug script.
Change the script to use if...then rather than &&, as the latter has
very confusing and undesirable semantics.
Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
This property corresponds to what is called "removable" in xenstore,
and is the conventional meaning of "removable": ie, the _media_ can be
removed even as the _device_ remains present.
"unpluggable" is a misleading name for this.
Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Committed-by: Ian Jackson <Ian.Jackson@eu.citrix.com>
This is not currently implemented. Applications setting it to
anything but NULL will cause an error. Code to set it from xl
configuration files will appear later in this series.
Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com>
Committed-by: Ian Jackson <Ian.Jackson@eu.citrix.com>
Yang, Wei
George Dunlap
Tim Deegan
Eddie Dong
Andrew Cooper
Keir Fraser
Mark Langsdorf
Ian Campbell
Christoph Egger
Ian Jackson