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>
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>
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>
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>
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>
Provide a copy of the standard TOSTRING macro in libxlu_internal.h,
for the benefit of patches later in this series.
Also, move TOSTRING to libxl_internal.h from a .c file for the
benefit of future other callers in libxl proper.
(These cannot be combined because libxlu cannot include
libxl_internal.h and libxl should not include libxlu_internal.h.)
Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>
Committed-by: Ian Jackson <Ian.Jackson@eu.citrix.com>
Copyright notices in libxlu_cfg_[ly].[ly] end up in the .[ch] files,
copied there by flex and bison. Regenerate those files (flex 2.5.35
and bison 2.3, from Debian lenny i386).
No manual edits in this patch.
Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com>
Committed-by: Ian Jackson <Ian.Jackson@eu.citrix.com>
The help text for xm create's --dry-run says "Dry run - prints the
resulting configuration in SXP but does not create the domain." so
update xl implementation to match. At least the xendomains initscript
relies on this (for better or worse).
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Tested-by: Carsten Schiers <carsten@schiers.de>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
Adds support for assigning a label to domains, obtaining and setting the
current enforcing mode, and loading a policy with xl command and libxl
header when the Flask XSM is in use. Adheres to the changes made by the
patch to remove exposure of libxenctrl/libxenstore headers via libxl.h.
Signed-Off-By: Machon Gregory <mbgrego@tycho.ncsc.mil>
Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
Some distros enable -D_FORTIFY_SOURCE=2 by default
(https://wiki.ubuntu.com/CompilerFlags) which adds the warn_unused_result
attribute to several functions including read(2) and write(2)
Although we don't really care about error reading or writing the libxl spawn fd
catch them anyway to keep this warning happy.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Tested-by: Olaf Hering <olaf@aepfle.de>
Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
Olaf Hering reports:
if ! cmp _libxl_paths.h.2.tmp _libxl_paths.h; then mv -f _libxl_paths.h.2.tmp _libxl_paths.h; fi
cmp: _libxl_paths.h: No such file or directory
Use "cmp -s" to silence the error. cmp returns 2 in this case and so the mv
does occur.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Tested-by: Olaf Hering <olaf@aepfle.de>
Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
* Remove Linux-private defns with no direct relation to CPUID
* Remove word offsets into Linux-defined cpu_caps array
* Hard tabs -> soft tabs
Signed-off-by: Keir Fraser <keir@xen.org>
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>
.. which will be removed once the auto-ballooning of guests
with PCI devices works. During testing of the patches which provide
a host E820 in a PV guest, certain inconsistencies were found with
guests. When launching a RHEL5 or SLES11 PV guest with 4GB and a PCI device,
the kernel would report 4GB, but have 1.5G "used". What happend was that
the P2M that fall within the E820 I/O holes would never be used and was just
wasted. The mechanism to go around this is to shrink the size of the guest
before launch (say memory=2048, maxmem=4096) and then balloon back to 4096M
after start. For PVOPS type kernels it would detect the E820 I/O holes and
deflate by the correct amount but would not inflate back to 4GB.
Manually inflating makes it work.
The fix in the future for guests where the memory amount flows over the
PCI hole, is to launch the guest with decreased amount right up to the cusp
of where the E820 PCI hole starts. Also increase the 'maxmem' by the delta
and then when the guest has launched, balloon up to the delta number.
This will require some careful surgery so for right now this parameter
will guard against unsuspecting users seeing their PV guests memory "vanish."
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Committed-by: Ian Jackson <ian.jackson.citrix.com>
Most machines after the RAM regions in the e802 have a couple of
E820_RESERVED, with E820_ACPI and E820_NVS. On some Intel machines, the
E820 looks like swiss cheese:
(XEN) Initial Xen-e820 RAM map:
(XEN) 0000000000000000 - 000000000009d000 (usable)
(XEN) 000000000009d000 - 00000000000a0000 (reserved)
(XEN) 00000000000e0000 - 0000000000100000 (reserved)
(XEN) 0000000000100000 - 000000009cf66000 (usable)
(XEN) 000000009cf66000 - 000000009d102000 (ACPI NVS)
(XEN) 000000009d102000 - 000000009f6bd000 (usable) <--
(XEN) 000000009f6bd000 - 000000009f6bf000 (reserved)
(XEN) 000000009f6bf000 - 000000009f714000 (usable) <--
(XEN) 000000009f714000 - 000000009f7bf000 (ACPI NVS)
(XEN) 000000009f7bf000 - 000000009f7e0000 (usable) <--
(XEN) 000000009f7e0000 - 000000009f7ff000 (ACPI data)
(XEN) 000000009f7ff000 - 000000009f800000 (usable) <--
(XEN) 000000009f800000 - 00000000a0000000 (reserved)
(XEN) 00000000a0000000 - 00000000b0000000 (reserved)
(XEN) 00000000fc000000 - 00000000fd000000 (reserved)
(XEN) 00000000ffe00000 - 0000000100000000 (reserved)
(XEN) 0000000100000000 - 0000000160000000 (usable)
Which means we have to pay attention to the E820_RAM that are
between the E820_[ACPI,NVS,RESERVED]. If we remove those
E820_RAM (b/c the amount of memory passed to the guest
is less that where those E820 regions reside) from the E820, the
Linux kernel interprets those "gaps" as PCI I/O space.
This is what we are currently doing.
This can be disastrous if we pass in an Intel IGD card which tries
to use the first available PCI I/O space - and ends up
using the MFNs which are actually RAM instead of being the
PCI I/O space.
To make this work, we convert all E820_RAM that are above
the 'target_kb' (those that overlap the 'target_kb'
are truncated appropriately) to be E820_UNUSABLE. We also limit this
alternation up to 4GB. This means that an E820 for a guest
>from this (target_kb=1024, maxmem=2048):
[ 0.000000] Set 405658 page(s) to 1-1 mapping.
[ 0.000000] BIOS-provided physical RAM map:
[ 0.000000] Xen: 0000000000000000 - 00000000000a0000 (usable)
[ 0.000000] Xen: 00000000000a0000 - 0000000000100000 (reserved)
[ 0.000000] Xen: 0000000000100000 - 0000000040000000 (usable)
[ 0.000000] Xen: 0000000040000000 - 000000009cf66000 (unusable)
[ 0.000000] Xen: 000000009cf66000 - 000000009d102000 (ACPI NVS)
[ 0.000000] Xen: 000000009f6bd000 - 000000009f6bf000 (reserved)
[ 0.000000] Xen: 000000009f714000 - 000000009f7bf000 (ACPI NVS)
[ 0.000000] Xen: 000000009f7e0000 - 000000009f7ff000 (ACPI data)
[ 0.000000] Xen: 000000009f800000 - 00000000b0000000 (reserved)
[ 0.000000] Xen: 00000000fc000000 - 00000000fd000000 (reserved)
[ 0.000000] Xen: 00000000fec00000 - 00000000fec01000 (reserved)
[ 0.000000] Xen: 00000000fee00000 - 00000000fee01000 (reserved)
[ 0.000000] Xen: 00000000ffe00000 - 0000000100000000 (reserved)
[ 0.000000] Xen: 0000000100000000 - 0000000140800000 (usable)
Will look as so:
[ 0.000000] Set 395880 page(s) to 1-1 mapping.
[ 0.000000] BIOS-provided physical RAM map:
[ 0.000000] Xen: 0000000000000000 - 00000000000a0000 (usable)
[ 0.000000] Xen: 00000000000a0000 - 0000000000100000 (reserved)
[ 0.000000] Xen: 0000000000100000 - 0000000040000000 (usable)
[ 0.000000] Xen: 0000000040000000 - 000000009cf66000 (unusable)
[ 0.000000] Xen: 000000009cf66000 - 000000009d102000 (ACPI NVS)
[ 0.000000] Xen: 000000009d102000 - 000000009f6bd000 (unusable)
[ 0.000000] Xen: 000000009f6bd000 - 000000009f6bf000 (reserved)
[ 0.000000] Xen: 000000009f6bf000 - 000000009f714000 (unusable)
[ 0.000000] Xen: 000000009f714000 - 000000009f7bf000 (ACPI NVS)
[ 0.000000] Xen: 000000009f7bf000 - 000000009f7e0000 (unusable)
[ 0.000000] Xen: 000000009f7e0000 - 000000009f7ff000 (ACPI data)
[ 0.000000] Xen: 000000009f7ff000 - 000000009f800000 (unusable)
[ 0.000000] Xen: 000000009f800000 - 00000000b0000000 (reserved)
[ 0.000000] Xen: 00000000fc000000 - 00000000fd000000 (reserved)
[ 0.000000] Xen: 00000000fec00000 - 00000000fec01000 (reserved)
[ 0.000000] Xen: 00000000fee00000 - 00000000fee01000 (reserved)
[ 0.000000] Xen: 00000000ffe00000 - 0000000100000000 (reserved)
[ 0.000000] Xen: 0000000100000000 - 0000000140800000 (usable)
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Committed-by: Ian Jackson <ian.jackson.citrix.com>
The code that populates E820 is unconditionally triggered by the guest
configuration having "pci=['<BDF>,..']", being a PV guest, and if
b_info->u.pv.e820_host is set.
The code do_domain_create calls the libxl__e820_alloc when
it notices that the guest is PV, has at least one PCI devices, and has
the e820_host flag set.
libxl__e820_alloc calls the xc_get_machine_memory_map to retrieve the systems
E820. Then the E820 is sanitized to weed out E820 entries below 16MB, and as
well remove any E820_RAM or E820_UNUSED regions as the guest does not need to
know about them. The guest only needs the E820_ACPI, E820_NVS, E820_RESERVED to
get an idea of where the PCI I/O space is. Mostly.. The Linux kernel assumes that any
gap in the E820 is considered PCI I/O space which means that if we pass
in the guest 2GB, and the E820_ACPI, and its friend start at 3GB, the
gap between 2GB and 3GB will be considered as PCI I/O space. To guard against
that we also create an E820_UNUSABLE between the region of 'target_kb'
(called ram_end in the code) up to the first E820_[ACPI,NVS,RESERVED] region.
Lastly, the xc_domain_set_memory_map is called to install the new E820.
When tested with another PV guest (NetBSD 5.1) the modified E820 gave
it no trouble. The code has also been tested with older "classic" Xen Linux
and with the newer "pvops" with success (SLES11, RHEL5, Ubuntu Lucid,
Debian Squeeze, 2.6.37, 2.6.38, 2.6.39).
Memory that is slack or for balloon (so 'maxmem' in guest configuration)
is put behind the machine E820. Which in most cases is after the 4GB.
The reason for doing the fetching of the E820 using the hypercall in
the toolstack (instead of the guest doing it) is that when a guest
would do a hypercall to 'XENMEM_machine_memory_map' it would
retrieve an E820 with I/O range caps added in. Meaning that the
region after 4GB up to end of possible memory would be marked as unusable
and the kernel would not have any space to allocate a balloon
region.
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Committed-by: Ian Jackson <ian.jackson.citrix.com>
Yang, Wei
Tim Deegan
Ian Campbell
Christoph Egger
Keir Fraser
Ian Jackson
Yang Zhang
Machon Gregory
Konrad Rzeszutek Wilk
George Dunlap