This saves a VMENTRY and a VMEXIT since we no longer retry the
ioport read on backing DM not handling a given ioreq.
There are 2 case about "no ioreq server exists for this I/O":
1) No ioreq servers (PVH case)
2) No ioreq servers for this I/O (non PVH case)
The routine hvm_has_dm() used to check for the empty list, the PVH
case (#1).
By changing from hvm_has_dm() to hvm_select_ioreq_server() both
cases are considered. Doing it this way allows
hvm_send_assist_req() to only have 2 possible return values.
The key part of skipping the retry is to do "rc = X86EMUL_OKAY"
which is what the error path on the call to hvm_has_dm() does in
hvmemul_do_io() (the only call on hvm_has_dm()).
Since this case is no longer handled in hvm_send_assist_req(), move
the call to hvm_complete_assist_req() into hvmemul_do_io().
As part of this change, do the work of hvm_complete_assist_req() in
the PVH case. Acting more like real hardware looks to be better.
Adding "rc = X86EMUL_OKAY" in the failing case of
hvm_send_assist_req() would break what was done in commit
bac0999325 and commit
f20f3c8ece. We are currently doing
the succeeding case of hvm_send_assist_req() and retying the I/O.
Since hvm_select_ioreq_server() has already been called, switch to
using hvm_send_assist_req_to_ioreq_server().
Since there is no longer any calls to hvm_send_assist_req(), drop
that routine and rename hvm_send_assist_req_to_ioreq_server() to
hvm_send_assist_req.
Since hvm_send_assist_req() is an extern, add an ASSERT() on s.
Signed-off-by: Don Slutz <dslutz@verizon.com>
Reviewed-by: Paul Durrant <paul.durrant@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
c/s 7dd3b06ff "vmx: fix handling of NMI VMEXIT" fixed one issue but
inadvertently introduced a regression when it came to the NMI shootdown. The
shootdown code worked by patching vector 2 in each IDT, but the introduced
direct call to do_nmi() bypassed this.
Instead of patching each IDT, take a different approach by updating the
existing dispatch table. This allows for the removal of the remote IDT
patching and the removal of the nmi_crash() entry point.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
and use it in preference to the direct call to do_nmi() in vmx.c
The value 'TRAP_last_reserved' was only used where 'TRAP_nr' would be more
appropriate, so is replaced.
No functional change
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
It is unclear why this got done for PV only originally.
While at it, limit this statistics collection to debug or performance
counter enabled builds.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
...when they are added back into the guest physmap, when an ioreq
server is disabled. If this is not done then the pages are missed
during migration, causing ioreq server creation to fail on the remote end.
This problem only manifests if the ioreq server is non-default because in
the default case the pages are never removed from the guest physmap.
Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
In the case where a stub domain is providing emulation for an HVM
guest, there is no interlock in the toolstack to make sure that
the stub domain is up and running before the guest is unpaused.
Prior to the introduction of ioreq servers this was not a problem,
since there was only ever one emulator so ioreqs were simply
created anyway and the vcpu remained blocked until the stub domain
started and picked up the ioreq.
Since ioreq servers allow for multiple emulators for a single guest
it's not possible to know a priori which emulator will handle a
particular ioreq, so emulators must attach to a guest before the
guest runs.
This patch works around the lack of interlock in the toolstack for
stub domains by keeping the domain paused until at least one ioreq
server is created and enabled, which in practice means the stub
domain is indeed up and running.
Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
In libxl_ctx_free:
1. Move the GC_INIT earlier, so that we can:
2. Take the lock around most of the work. This is technically
unnecessary since calling any other libxl entrypoint on a ctx being
passed to libxl_ctx_free risks undefined behaviour. But, taking
the lock allows us to much more usually spot this.
3. Increment osevent_in_hook by 1000. If we are reentered after
destroy, this will trip some of our entrypoints' asserts. It also
means that if we crash for some other reason relating to reentering
a destroyed ctx, the cause will be more obviously visible by
examining ctx->osevent_in_hook (assuming that the memory previously
used for the ctx hasn't been reused and overwritten).
4. Free the lock again. (pthread_mutex_destroy requires that the
mutex be unlocked.)
With this patch, I find that an occasional race previously reported
as:
libvirtd: libxl_internal.h:3265: libxl__ctx_unlock: Assertion `!r' failed.
is now reported as:
libvirtd: libxl_event.c:1236: libxl_osevent_occurred_fd: Assertion `!libxl__gc_owner(gc)->osevent_in_hook' failed.
Examining the call trace with gdb shows this:
(gdb) bt
#0 0xb773f424 in __kernel_vsyscall ()
#1 0xb7022871 in raise () from /lib/i386-linux-gnu/i686/nosegneg/libc.so.6
#2 0xb7025d62 in abort () from /lib/i386-linux-gnu/i686/nosegneg/libc.so.6
#3 0xb701b958 in __assert_fail () from /lib/i386-linux-gnu/i686/nosegneg/libc.so.6
#4 0xb6f00390 in libxl_osevent_occurred_fd (ctx=0xb84813a8, for_libxl=0xb84d6848, fd=31, events_ign=0, revents_ign=1) at libxl_event.c:1236
#5 0xb1b70464 in libxlDomainObjFDEventCallback () from /usr/local/lib/libvirt/connection-driver/libvirt_driver_libxl.so
#6 0xb72163b1 in virEventPollDispatchHandles () from /usr/local/lib/libvirt.so.0
#7 0xb7216be5 in virEventPollRunOnce () from /usr/local/lib/libvirt.so.0
#8 0xb7214a7e in virEventRunDefaultImpl () from /usr/local/lib/libvirt.so.0
#9 0xb77c7b98 in virNetServerRun ()
#10 0xb7771c63 in main ()
(gdb) print ctx->osevent_in_hook
$2 = 1000
(gdb)
which IMO demonstrates that libxl_osevent_occurred_fd is being called
on a destroyed ctx.
This is probably a symptom of the bug in libvirt fixed by these
patches:
https://www.redhat.com/archives/libvir-list/2015-February/msg00024.html
Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com>
CC: Ian Campbell <ian.campbell@citrix.com>
CC: Wei Liu <wei.liu2@citrix.com>
CC: Jim Fehlig <jfehlig@suse.com>
Acked-by: Wei Liu <wei.liu2@citrix.com>
libxl__ao_inprogress needs to check (like
libxl__ao_complete_check_progress_reports) that there are no
oustanding progress callbacks.
Otherwise it might happen that we would destroy the ao while another
thread has an outstanding callback its egc report queue. The other
thread would then, in its egc_run_callbacks, touch the destroyed ao.
Instead, when this happens in libxl__ao_inprogress, simply run round
the event loop again. The thread which eventually makes the callback
will spot our poller in the ao, and notify the poller, waking us up.
This fixes an assertion failure race seen with libvirt:
libvirtd: libxl_event.c:1792: libxl__ao_complete_check_progress_reports: Assertion `ao->in_initiator' failed.
or (after "Add an assert to egc_run_callbacks")
libvirtd: libxl_event.c:1338: egc_run_callbacks: Assertion `aop->ao->magic == 0xA0FACE00ul' failed.
Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com>
CC: Ian Campbell <ian.campbell@citrix.com>
CC: Wei Liu <wei.liu2@citrix.com>
CC: Jim Fehlig <jfehlig@suse.com>
Acked-by: Wei Liu <wei.liu2@citrix.com>
Break out the test in libxl__ao_complete_check_progress_reports, into
ao_work_outstanding, which reports false if either (i) the ao is still
ongoing or (ii) there is a progress report (perhaps on a different
thread's callback queue) which has yet to be reported to the
application.
No functional change.
Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com>
CC: Ian Campbell <ian.campbell@citrix.com>
CC: Wei Liu <wei.liu2@citrix.com>
CC: Jim Fehlig <jfehlig@suse.com>
Acked-by: Wei Liu <wei.liu2@citrix.com>
Check that the ao is still live when we are about to running some of
its callbacks.
This reveals an existing bug in libxl which is exercised by libvirt,
converting
libvirtd: libxl_event.c:1792: libxl__ao_complete_check_progress_reports: Assertion `ao->in_initiator' failed.
into
libvirtd: libxl_event.c:1338: egc_run_callbacks: Assertion `aop->ao->magic == 0xA0FACE00ul' failed.
Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com>
CC: Ian Campbell <ian.campbell@citrix.com>
CC: Wei Liu <wei.liu2@citrix.com>
CC: Jim Fehlig <jfehlig@suse.com>
Acked-by: Wei Liu <wei.liu2@citrix.com>
Some systems have python-config include -D_FORTIFY_SOURCE in the
CFLAGS. But -D_FORTIFY_SOURCE does not (currently) work with -O0, and
-O0 is enabled in debug builds (since 1166ecf781). As a result, on
those systems, debug builds fail.
Work around this problem as follows:
* In configure, detect -D_FORTIFY_SOURCE in $(python-config --cflags)
* If detected, set the new autoconf substitution and make variable
PY_NOOPT_CFLAGS to -O1.
* In tools/Rules.mk, where we add -O0, also add PY_NOOPT_CFLAGS
(which will override the -O0 with -O1 if required).
Overriding the -O0 is better than disabling Fortify because the
latter might have an adverse security impact. A user who wants to
disable optimisation completely even for Python and also disable
Fortify can set the environment variable
EXTRA_CFLAGS_XEN_TOOLS='-U_FORTIFY_SOURCE -O0'
Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com>
Reported-by: Jan Beulich <JBeulich@suse.com>
Signed-off-by: Jan Beulich <jbeulich@suse.com>
CC: Jan Beulich <JBeulich@suse.com>
CC: Ian Campbell <Ian.Campbell@citrix.com>
CC: Euan Harris <euan.harris@citrix.com>
CC: Wei Liu <wei.liu2@citrix.com>
CC: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Tested-by: Don Slutz <dslutz@verizon.com>
When a guest change it's MTRR MSRs, ajusting EPT table and flushing
cache are needed only when guest has IOMMU device, using need_iommu(d)
can minimize the impact to guest with device assigned, since a guest
may be hot plugged with a device thus there may be dirty cache lines
before need_iommu(d) becoming true, force the p2m_memory_type_changed
and flush_all when the first device is assigned to guest to amend this
issue.
Signed-off-by: Liang Li <liang.z.li@intel.com>
Signed-off-by: Yang Zhang <yang.z.zhang@intel.com>
Acked-by: Kevin Tian <kevin.tian@intel.com>
Both vchan_wr() and stdout_wr() should be defined with a non-empty
argument list (i.e. void). Additionally both of them as well as usage()
should be static to make clear that no other code is referencing them.
Further, statements should follow declarations.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Wei Liu <wei.liu2@citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
During domain startup, all required memory ballooning must complete
within a maximum window of 33 seconds (3 retries, 11 seconds of delay).
If not, domain creation is aborted with a 'failed to free memory' error.
In order to accommodate large domains or slower hardware (which require
substantially longer to balloon memory) the free memory process should
continue retrying if the amount of free memory is increasing on each
iteration of the loop.
Signed-off-by: Mike Latimer <mlatimer@suse.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Starting from rump kernel changeset 91d5623 ("Renaming platform macros,
app-tools and autoconf target string"), __RUMPUSER_XEN__ and __RUMPAPP__
are deleted. We are supposed to use __RUMPRUN__ instead.
We still keep __RUMPUSER_XEN__ for now in order to make xen-unstable
pass osstest push gate. I will remove __RUMPUSER_XEN__ later.
Related discussion:
http://thread.gmane.org/gmane.comp.rumpkernel.user/739
Signed-off-by: Wei Liu <wei.liu2@citrix.com>
Cc: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
The resource behind an event channel is domain centric rather than vcpu
centric.
This change allows mem_event_disable() to avoid arbitrarily referencing
d->vcpu[0] just to pass the domain.
No functional change.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
A few cosmetic adjustments.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
As this requires growing struct page_info from 32 to 48 bytes as well
as shrinking the always accessible direct mapped memory range from 5Tb
to 3.5Tb, this isn't being introduced as a general or default enabled
feature.
A side effect of the change to x86's mm.h is that asm/mm.h may no
longer be included directly. Hence in the few places where this was done,
xen/mm.h is being substituted (indirectly in the hvm/mtrr.h case).
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Tim Deegan <tim@xen.org>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
Comparing its result against NULL is unsafe when page lists use normal
list entries for linking together - page_list_empty() needs to be used
instead.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Tim Deegan <tim@xen.org>
Considering the complexity of the code, it seems to be a reasonable
thing to allow people to disable that code entirely even outside the
immediate need for this by the next patch.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Tim Deegan <tim@xen.org>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
Multi-page shadows are linked together using the 'list' field. When
those shadows are in the pinned list, the list fragments are spliced
into the pinned list; otherwise they have no associated list head.
Rework the code that handles these fragments to use the page_list
interface rather than manipulating the fields directly. This makes
the code cleaner, and allows the 'list' field to be either the
compact pdx form or a normal list_entry.
Signed-off-by: Tim Deegan <tim@xen.org>
Tested-by: Andrew Cooper <andrew.cooper3@citrix.com>
Introduce sh_terminate_list() and make it use LIST_POISON*.
Move helper array of shadow_size() into common.c.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Tim Deegan <tim@xen.org>
Don't have the hypervisor update APIC_LVTPC when _it_ thinks the vector
should be updated. Instead, handle guest's APIC_LVTPC accesses and write what
the guest explicitly wanted (but only when VPMU is enabled).
This is updated version of commit 8097616fbd that was reverted by
cc3404093c. Unlike the previous version, we don't update APIC_LVTPC
when VPMU is disabled to avoid interfering with NMI watchdog (which
runs only when VPMU is off).
Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Acked-by: Kevin Tian <kevin.tian@intel.com>
NMI watchdog sets APIC_LVTPC register to generate an NMI when PMU counter
overflow occurs. This may be overwritten by VPMU code later, effectively
turning off the watchdog.
We should disable VPMU when NMI watchdog is running.
Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
Use the class to differentiate between host and nested p2m's, and
potentially other classes in the future.
Fix p2m class checks that implicitly assume nested and host are
the only two classes that will ever exist.
Signed-off-by: Ed White <edmund.h.white@intel.com>
Acked-by: Tim Deegan <tim@xen.org>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
Linux is in the process of converting their seconds representation to
64 bits, so in order to support it consistently we should follow suit
(which at some point in quite a few years we'd have to do anyway). To
represent this in struct shared_info we leverage a 32-bit hole in
x86-64's and arm's variant of the structure; for x86-32 guests the only
(reasonable) choice we have is to put the extension in struct
arch_shared_info.
A note on the conditional suppressing the xen_wc_sec_hi helper macro
definition in the ix86 case for hypervisor and tools: Neither of the
two actually need this, and its presence causes the tools to fail to
build (due to the inclusion of both the x86-64 and x86-32 variants of
the header).
As a secondary change, x86's do_platform_op() gets a pointless
initializer as well as a pointless assignment of that same variable
dropped.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Tim Deegan <tim@xen.org>
Acked-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
The Ocaml stub to retrieve the hypervisor console ring had a few problems.
* A single 32k buffer would truncate a large console ring.
* The buffer was static and not under the protection of the Ocaml GC lock so
could be clobbered by concurrent accesses.
* Embedded NUL characters would cause caml_copy_string() (which is strlen()
based) to truncate the buffer.
The function is rewritten from scratch, using the same algorithm as the python
stubs, but uses the protection of the Ocaml GC lock to maintain a static
running total of the ring size, to avoid redundant realloc()ing in future
calls.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
CC: Dave Scott <dave.scott@eu.citrix.com>
CC: Ian Campbell <Ian.Campbell@citrix.com>
CC: Ian Jackson <Ian.Jackson@eu.citrix.com>
CC: Wei Liu <wei.liu2@citrix.com>
Acked-by: David Scott <dave.scott@citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
When commit 6865e52b78, "PCI multi-seg: adjust domctl interface",
is introduced, we missed to sync that head file.
Signed-off-by: Tiejun Chen <tiejun.chen@intel.com>
Acked-by: Wei Liu <wei.liu2@citrix.com>
c/s 5b5c40c0d1 "libxc: introduce a per architecture scratch pfn for temporary
grant mapping" accidentally an issue whereby there were two paths out of
xc_core_arch_get_scratch_gpfn() which returned 0, but only one of which
assigned a value to the gpfn parameter.
xc_domain_maximum_gpfn() can validly return 0, at which point gpfn 1 is a
valid scratch page to use.
In addition, widen rc before adding 1 and possibly overflowing.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
CC: Julien Grall <julien.grall@linaro.org>
CC: Jan Beulich <JBeulich@suse.com>
CC: Ian Campbell <Ian.Campbell@citrix.com>
CC: Ian Jackson <Ian.Jackson@eu.citrix.com>
CC: Wei Liu <wei.liu2@citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
If the new target is relative to the current target, do not remove
videoram again: it has already been removed from the current target.
Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
printk is not rated-limited by default. Therefore a malicious guest may
be able to flood the Xen console.
If we use gdprintk, unecessary information will be printed such as the
filename and the line. Instead use XENLOG_G_ERR combine with %pv.
This is XSA-118.
Signed-off-by: Julien Grall <julien.grall@linaro.org>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
printk by default is not rate-limited by default. Therefore a malicious guest
may be able to flood the Xen console.
If we use gdprintk, unnecessary information will be printed such as the
filename and the line. Instead use XENLOG_G_{ERR,DEBUG} combine with %pv.
Also remove the vGICv3 prefix which is not neccessary and update some
message which were wrong.
This is XSA-118.
Signed-off-by: Julien Grall <julien.grall@linaro.org>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
The commit f6c9698 " x86: allow reading MSR_IA32_TSC with XENPF_resource_op"
introduced a built regression on ARM platform.
random.c:8:28: error: expected =, ,, ;, asm or __attribute__ before boot_random
unsigned int __read_mostly boot_random;
^
The define __read_mostly is defined in asm/cache.h which is included by
other headers on x86 but not on ARM. Include xen/cache.h to fix the
build.
Signed-off-by: Julien Grall <julien.grall@linaro.org>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
private.h defining them I can't see why they couldn't be used here to
make the code easier to read.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Tim Deegan <tim@xen.org>
It so far having been ~1 made most of the code preceding the call
pointless, but I assume this wasn't meant to be that way. Also replace
the remaining hard coded ~1 with an expression documenting the
intention a little better.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Adjust again to use SHF_page_type_mask, at Jan's suggestion.
Signed-off-by: Tim Deegan <tim@xen.org>
To make obvious that such statics are safe to use, they should be
const. In some of the cases, they wouldn't even need to be static, but
keep them so upon the maintainer's request.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Tim Deegan <tim@xen.org>
While presumably of primary use to ARM64 (once the code gets
generalized), we should still support this more modern variant,
allowing for the actual DMI data to reside in memory above 4Gb.
While based on draft version 3.0.0d, it is assumed that the final
version of the specification will not render this implementation
invalid (not the least because Linux 3.19 already makes the same
assumption).
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
Don Slutz