In its current shape, if Xen unshares a foreign gfn successfully while building
a foreign writable map, it is left with a reference to the old shared page in
the "target" var.
Instead, push unsharing request down on the initial get_page_from_gfn call,
which will DTRT.
This allows for greatly simplifying the unshare related condition handling,
removing ugly comments and s86_64 ifdef-ery.
Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Acked-by: Tim Deegan <tim@xen.org>
Committed-by: Tim Deegan <tim@xen.org>
Since the emulator now supports a few 256-bit memory operations, this
array needs to follow (and the comments should, too).
To limit growth, re-order the mmio_large_write_* fields so that the
two mmio_large_*_bytes fields end up adjacent to each other.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Keir Fraser <keir@xen.org>
There's no apparent reason not to permit this, and since we don't
support out-of-source-tree builds, the least overhead way of doing
multiple, differently configured (perhaps different architecture)
builds from a single source tree is to create symlinked build trees.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Causing a build failure when trying to use it:
xxx: error: expected ';' before ')' token
xxx: error: expected statement before ')' token
Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>
Committed-by: Ian Campbell <ian.campbell@citrix.com>
For some reason we were holding the lock over only the unmaps at the end of
the function, rather than for the whole walk.
We might want to be more clever in the future, but for now lets just lock for
the whole walk+create process.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Tim Deegan <tim@xen.org>
Committed-by: Ian Campbell <ian.campbell@citrix.com>
This needs to be done for all cpus. The allocations require smp_prepare_cpus
to be called a bit later on.
In a previous version of this patch these maps were being zeroed (instead of
setting the CPU itself in them). This in turn causes cpumask_first to return
NR_CPUS, which in turn was causing default_vcpu0_location to misbehave and
read off the end of its cnt array.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Tim Deegan <tim@xen.org>
Committed-by: Ian Campbell <ian.campbell@citrix.com>
XEN_DOMCTL_max_vcpus cannot reduce max_vcpus and therefore we can't create a
smaller guest.
The limit of 8 (due to GIC limits) should be expressed in MAX_VIRT_CPUS.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Committed-by: Ian Campbell <ian.campbell@citrix.com>
For most traps we can do this as soon as we have saved the necessary state.
For IRQs and FIQs we must wait until we have acked the interrupt with the GIC.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Committed-by: Ian Campbell <ian.campbell@citrix.com>
We align the stack before calling into C code but we weren't undoing this on
return.
Collapse continue_(non)idle_domain into continue_new_vcpu.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Committed-by: Ian Campbell <ian.campbell@citrix.com>
Include helpers for dumping hypervisor walks and guest p2m walks.
Useful for debug but not actually used in this patch.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Tim Deegan <tim@xen.org>
Committed-by: Ian Campbell <ian.campbell@citrix.com>
As was already pointed out months ago (see
http://lists.xen.org/archives/html/xen-devel/2012-02/msg00826.html),
gcc 4.7.x (imo validly) refuses to take both -mcpu=cortex-a15 and
-march=armv7-a due to conflicting feature sets causing amibiguity in
instruction selection. Since the former implies the latter, just use
the former (and drop the -march=).
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Fixes crashes with Windows guests when shadow-on-nested is used.
Signed-off-by: Christoph Egger <Christoph.Egger@amd.com>
Acked-by: Tim Deegan <tim@xen.org>
2205914617cb does its job in correcting the "wrong domain being
considered" issue introduced by 9d1fd58ff602. Unfortunately, when
dealing (again!) with the sedf scheduler, it is required for the
vCPUs of a domain to have been allocated and setup already (in
the hypervisor), when the first call to libxl_domain_sched_params_get()
happens, and that is not true.
This fixes that by avoiding calling that function at all, as we
only need to know which scheduler the domain is running under,
and that is provided by libxl__domain_scheduler() which is safe
to be called there.
While at it, also improve a bit the comments about the whole
sedf parameter validation and mangling process.
Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Committed-by: Ian Campbell <ian.campbell@citrix.com>
When attempting to use AMD's extension to access the extended PCI config
space, only the low byte of the register number was being passed to XSM.
Include the correct value of the register if this feature is enabled;
otherwise, bits 24-30 of port cf8 are reserved, so disallow the invalid
access.
Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Don't fail the permission check except when the MSR can't be read.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Keir Fraser <keir@xen.org>
Committed-by: Jan Beulich <jbeulich@suse.com>
Recent Dom0 kernels want to disable PCI MSI on all devices, yet doing
so on AMD IOMMUs (which get represented by a PCI device) disables part
of the functionality set up by the hypervisor.
Add a mechanism to mark certain PCI devices as having write protected
config spaces (both through port based [method 1] accesses and, for
x86-64, mmconfig), and use that for AMD's IOMMUs.
Note that due to ptwr_do_page_fault() being run first, there'll be a
MEM_LOG() issued for each such mmconfig based write attempt. If that's
undesirable, the order of the calls in fixup_page_fault() would need
to be swapped.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Tested-by: Wei Wang <wei.wang2@amd.com>
Acked-by: Keir Fraser <keir@xen.org>
This was previously done by xl itself however the domain was not
created at that point so there was no domid to check. This happened to
work on first boot because xl's global domid was initialised to zero
so we would (incorrectly) validate the new domain to be against
domain0. On reboot though we would try to use the old domain's id and
fail.
sched_params_valid is moved and gains a gc+domid parameters and
s/ctx/CTX/. The call is placed after
libxl__domain_build_info_setdefault in the create path, because
set_defaults doesn't have access to the domid and there are other
callers which don't even have a domid to give it.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Committed-by: Ian Campbell <ian.campbell@citrix.com>
These additions did not fulfill their purpose - they checked hypervisor
config space accesses instead of guest (Dom0) ones.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Keir Fraser <keir@xen.org>
For a multi-byte aligned read, this so far resulted in 0x00ff to be
put in the guest's register rather than 0xffff or 0xffffffff, which in
turn could confuse bus scanning functions (which, when reading vendor
and/or device IDs, expect to get back all zeroes or all ones).
As the value gets masked to the read width when merging back into the
full result, setting the initial value to all ones should not harm any
or the other cases.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Keir Fraser <keir@xen.org>
25468:9d1fd58ff602 was bogus in not letting a new domain being created
if its scheduling parameters --when running under the sedf scheduler--
were not fully specified, making creation fail like in this example
here below:
2012-06-16 07:37:47 Z executing ssh ... root@10.80.248.105 xl create /etc/xen/debian.guest.osstest.cfg
libxl: error: libxl.c:3619:sched_sedf_domain_set: setting domain sched sedf: Invalid argument
libxl: error: libxl_create.c:710:domcreate_bootloader_done: cannot (re-)build domain: -3
Parsing config from /etc/xen/debian.guest.osstest.cfg
This is due to the fact the values for period, slice, weight and
extratime should be consistent among each others, and if not all
are explicitly specified, someone has to make that happen. That
was right the purpose of the change in question, but it was failing
at achieving so.
This commit fixes things by forcing unspecified parameters to
sensible values, depending on the ones the user provided.
Signed-off-by: Dario Faggioli <dario.faggioli@citix.com>
Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
While putting together the workaround announced in
http://lists.xen.org/archives/html/xen-devel/2012-06/msg00709.html, I
found that mod_l1_entry(), upon encountering a set bit in
mmio_ro_ranges, would return 1 instead of 0 (the removal of the write
permission is supposed to be entirely transparent to the caller, even
more so to the calling guest).
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Keir Fraser <keir@xen.org>
Rather than deferring the detection of these to the point where they
get actually used (the fix for XSA-7, 25480:76eaf5966c05, causing a #GP
to be raised by IRET, which invokes the guest's [fragile] fail-safe
callback), don't even allow such to be set.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Keir Fraser <keir@xen.org>
When command to modify turbo mode (CPB on AMD processors) comes
in the actual change happens later, when P-state transition is
requested. There is no time limit on when this transition will
occur and therefore change in CPB state may take long time from
the moment when command to toggle it is issued.
This patch makes CPB mode change happen immediately when request
is made.
Signed-off-by: Boris Ostrovsky <boris.ostrovsky@amd.com>
Committed-by: Keir Fraser <keir@xen.org>
Do not clear asid cleanbit unconditionally. This shaves off 100 cycles
from the VMRUN instruction.
Signed-off-by: Christoph Egger <Christoph.Egger@amd.com>
Committed-by: Jan Beulich <jbeulich@suse.com>
Processors with this erratum are subject to a DoS attack by unprivileged
guest users.
This is XSA-9 / CVE-2012-2934.
Signed-off-by: Jan Beulich <JBeulich@suse.com>
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
Check for non-canonical guest RIP before attempting to execute sysret.
If sysret is executed with a non-canonical value in RCX, Intel CPUs
take the fault in ring0, but we will necessarily already have switched
to the the user's stack pointer.
This is a security vulnerability, XSA-7 / CVE-2012-0217.
Signed-off-by: Jan Beulich <JBeulich@suse.com>
Signed-off-by: Ian Campbell <Ian.Campbell@citrix.com>
Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Tested-by: Ian Campbell <Ian.Campbell@citrix.com>
Acked-by: Keir Fraser <keir.xen@gmail.com>
Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
We recently saw a machine that has the EBDA extending as low as
0x7c000, so that Xen fails to boot after relocating the trampoline.
To fix this, I removed BOOT_TRAMPOLINE and bootsym_phys completely.
Here are the parts:
1) the trampoline segment is set to 64k below the EBDA. head.S grows
the ability to relocate the trampoline segment
2) reloc.c is made position-independent. It allocates data below the
trampoline, whose address is passed in _eax.
3) cmdline.S is called before relocating, so all bootsym_phys there
become sym_phys.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
jb: - fall back to low memory size (instead of segment 0x7c00) if EBDA
value is out of range
- also add upper limit check on EBDA value
- fix and simplify inline assembly operands in reloc_mbi_struct()
- use lret instead of retf
- renamed early_stack to wakeup_stack, defined and used now only
in wakeup.S
- aligned reloc.bin's end of .text to 16 bytes, so that checking
__bss_start == end works reliably
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Committed-by: Keir Fraser <keir@xen.org>
Additionally, correct the text description to reflect what is being
done, and make use of fatal_trap() in preference to kexec_crash() in
case an unknown NMI occurs before a kdump kernel has been loaded.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Committed-by: Keir Fraser <keir@xen.org>
gdbsx got broken along the way. During domain pause, don't send
VIRQ_DEBUGGER to guest if gdbsx is active on that guest.
Signed-off-by: Mukesh Rathor <mukesh.rathor@oracle.com>
Committed-by: Keir Fraser <keir@xen.org>
NetBSD doesn't have a gntdev, so libvchan is unable to build due to
the lack of the header files gntalloc.h.
This is the error:
gcc -O1 -fno-omit-frame-pointer -m64 -g -fno-strict-aliasing
-std=gnu99 -Wall -Wstrict-prototypes -Wdeclaration-after-statement
-D__XEN_TOOLS__ -MMD -MF .init.o.d -fno-optimize-sibling-calls
-I../include -I.
-I/root/xen/xen-netbsd/tools/libvchan/../../tools/xenstore
-I/root/xen/xen-netbsd/tools/libvchan/../../tools/include
-I/root/xen/xen-netbsd/tools/libvchan/../../tools/libxc
-I/root/xen/xen-netbsd/tools/libvchan/../../tools/include -c -o init.o init.c
init.c:45:30: fatal error: xen/sys/gntalloc.h: No such file or directory
compilation terminated.
gmake[3]: *** [init.opic] Error 1
gmake[3]: *** Waiting for unfinished jobs....
init.c:45:30: fatal error: xen/sys/gntalloc.h: No such file or directory
compilation terminated.
Signed-off-by: Roger Pau Monne <roger.pau@citrix.com>
Acked-by: Christoph Egger <Christoph.Egger@amd.com>
Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
Andres Lagar-Cavilla
Jan Beulich
Dario Faggioli
Ian Campbell
Christoph Egger
Daniel De Graaf
Dario Faggioli
Boris Ostrovsky
Andrew Cooper
Mukesh Rathor
Olaf Hering
Anthony PERARD
Juergen Gross
Roger Pau Monne