Executing UD2 (invalid opcode) triggers a triple fault which signals
reboot to the toolstack, rather than crash.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Signed-off-by: Keir Fraser <keir@xen.org>
This patch adds next levels bit into bit 9 - bit 11 of p2m entries and
adds r/w permission bits into bit 61- bit 62 of p2m entries.
Signed-off-by: Wei Wang <wei.wang2@amd.com>
Acked-by: Tim Deegan <Tim.Deegan@citrix.com>
Committed-by: Tim Deegan <Tim.Deegan@citrix.com>
AMD IOMMU hardware uses bit 9 - bit 11 to encode lower page levels. p2m
type bits in p2m flags has to be shifted from bit 9 to bit 12. Also,
bit 52 to bit 60 cannot be non-zero for iommu pde. So, the definition of
p2m_ram_rw has to be swapped with p2m_invalid.
Signed-off-by: Wei Wang <wei.wang2@amd.com>
Acked-by: Tim Deegan <Tim.Deegan@citrix.com>
Committed-by: Tim Deegan <Tim.Deegan@citrix.com>
The calculated number of per-cpu trace pages is stored in t_info and
shared with tools like xentrace. Since its an u16 the value may
overflow because the current check is based on u32. Using the u16
means each cpu could in theory use up to 256MB as trace
buffer. However such a large allocation will currently fail on x86 due
to the MAX_ORDER limit. Check both max theoretical number of pages
per cpu and max number of pages reachable by struct t_buf->prod/cons
variables with requested number of pages.
Signed-off-by: Olaf Hering <olaf@aepfle.de>
Acked-by: George Dunlap <george.dunlap@eu.citrix.com>
Newer SVM implementations (Bulldozer) copy up to 15 bytes from the
instruction stream into the VMCB when a #PF or #NPF exception is
intercepted. This patch makes use of this information if available.
This saves us from a) traversing the guest's page tables, b) mapping
the guest's memory and c) copy the instructions from there into the
hypervisor's address space.
This speeds up #NPF intercepts quite a lot and avoids cache and TLB
trashing.
Signed-off-by: Andre Przywara <andre.przywara@amd.com>
Signed-off-by: Keir Fraser <keir@xen.org>
Newer SVM implementations (Bulldozer) give the desired address on
a INVLPG intercept explicitly in the EXITINFO1 field of the VMCB.
Use this address to avoid a costly instruction fetch and decode
cycle.
Signed-off-by: Andre Przywara <andre.przywara@amd.com>
Newer SVM implementations (Bulldozer) now give the used general
purpose register on a MOV-CR intercept explictly. This avoids
fetching and decoding the instruction from guest's memory and speeds
up some Windows guest, which exercise CR8 quite often.
Signed-off-by: Andre Przywara <andre.przywara@amd.com>
Signed-off-by: Keir Fraser <keir@xen.org>
Chapter 15.33 of recent APM Vol.2 manuals describe some additions
to SVM called DecodeAssist. Add the newly added fields to the VMCB
structure and name the associated CPUID bit.
Signed-off-by: Andre Przywara <andre.przywara@amd.com>
Currently the handling of CR accesses intercepts is done much
differently in SVM and VMX. For future usage move the VMX part
into the generic HVM path and use the exported functions.
Signed-off-by: Andre Przywara <andre.przywara@amd.com>
Signed-off-by: Keir Fraser <keir@xen.org>
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>
This means suppressing the uses in time_calibration_tsc_rendezvous(),
cstate_restore_tsc(), and synchronize_tsc_slave(), and fixes a boot
hang of Linux Dom0 when loading processor.ko on such systems that
have support for C states above C1.
Signed-off-by: Jan Beulich <jbeulich@novell.com>
Signed-off-by: Keir Fraser <keir@xen.org>
During creation of the PV domain we allocate the E820 structure to
have the amount of E820 entries on the machine, plus the number three.
This will allow the tool stack to fill the E820 with more than three
entries. Specifically the use cases is , where the toolstack retrieves
the E820, sanitizes it, and then sets it for the PV guest (for PCI
passthrough), this dynamic number of E820 is just right.
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Signed-off-by: Keir Fraser <keir@xen.org>
Since its only user is in ACPI parsing code, the extra overhead of
initializing to 0 is not worth fighting over.
Signed-off-by: Tim Deegan <Tim.Deegan@citrix.com>
This is an attempt to properly fix the hypervisor crash previously
described in
http://marc.info/?l=xen-devel&m=128396289707362&w=2
In looking into this issue, I think the proper fix is to move the
xsm_mmu_* and xsm_update_va_mapping hook calls later in the callers,
after more validation has been performed and the page_info struct is
readily available, and pass the page_info to the hooks. This patch
moves the xsm_mmu_normal_update, xsm_mmu_machphys_update and
xsm_update_va_mapping hook calls accordingly, and updates their
interfaces and hook function implementations. This appears to resolve
the crashes for me.
Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov>
Allow the toolstack to select the BIOS to use via a xenstore key.
Defaults to "rombios" for compatibility with toolstacks which do not
write the key (e.g. xend).
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
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>
Although happen to live at the same physical address their lifespans
do not overlap. The scratch and hypercall spaces are used only within
hvmloader and the same area is reused as a heap within ROMBIOS. But
each is free to make its own decisions about where to place things.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Keir Fraser <keir@xen.org>
Instead of hardcoding in a header.
Reduces the cross talk between ROMBIOS and hvmloader.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Keir Fraser <keir@xen.org>
Instead of hardcoding in a header.
Reduces the cross talk between ROMBIOS and hvmloader.
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>
Currently rombios and hvmloader are rather intertwined. Separate the
ROMBIOS configuration options out into a ROMBIOS provided file so that
the dependency can become strictly from hvmloader to rombios.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Keir Fraser <keir@xen.org>
c/s 22275: "tools: cleanup domain save switch_qemu_logdirty callback"
introduced a whole bunch of error code fixups. In the process, it also
ended up treating the success return code (0) from
switch_qemu_logdirty as an error and vice versa.
Signed-off-by: Shriram Rajagopalan <rshriram@cs.ubc.ca>
Some device could generate bogus interrupts if an IO-APIC RTE and an
iommu interrupt remapping entry are not consistent during 2 adjacent
64bits IO-APIC RTE updates. For example, if the 2nd operation updates
destination bits in RTE for SATA device and unmask it, in some case,
SATA device will assert ioapic pin to generate interrupt immediately
using new destination but iommu could still translate it into the old
destination, then dom0 would be confused. To fix that, we sync up
interrupt remapping entry with IO-APIC IRE on every 32 bits operation
and forward IOAPIC RTE updates after interrupt.
Signed-off-by: Wei Wang <wei.wang2@amd.com>
Acked-by: Jan Beulich <jbeulich@novell.com>
They are a pointless level of abstraction beneath nestedhvm_* variants
of the same operations, which all callers should be using.
At the same time, nestedhvm_vcpu_initialise() does not need to call
destroy if initialisation fails. That is the vendor-specific init
function's job (clearing up its own state on failure).
Signed-off-by: Keir Fraser <keir@xen.org>
Tim Deegan
Keir Fraser
Wei Wang
Olaf Hering
Andre Przywara
Christoph Egger
Stephen Smalley
Ian Campbell
Shriram Rajagopalan
Jan Beulich
Jim Fehlig