When updating the timeslice of the credit scheduler protect the
scheduler's private data by it's lock. Today a possible race could
result only in some weird scheduling decisions during one timeslice,
but further adjustments will need the lock anyway.
Signed-off-by: Juergen Gross <jgross@suse.com>
Reviewed-by: Dario Faggioli <dario.faggioli@citrix.com>
c/s 428607a "x86: shrink 'struct domain', was already PAGE_SIZE" introduced a
use-after-free error during domain destruction, because of the order in which
timers are torn down.
(XEN) Xen call trace:
(XEN) [<ffff82d08013344e>] spinlock.c#check_lock+0x1e/0x40
(XEN) [<ffff82d08013349b>] _spin_lock+0x11/0x52
(XEN) [<ffff82d0801e8076>] vpt.c#pt_lock+0x24/0x40
(XEN) [<ffff82d0801e88f4>] destroy_periodic_time+0x18/0x81
(XEN) [<ffff82d0801e1089>] rtc_deinit+0x53/0x78
(XEN) [<ffff82d0801d1e5a>] hvm_domain_destroy+0x52/0x69
(XEN) [<ffff82d08016a758>] arch_domain_destroy+0x1a/0x98
(XEN) [<ffff82d080107cd5>] domain.c#complete_domain_destroy+0x6f/0x182
(XEN) [<ffff82d080126a19>] rcupdate.c#rcu_process_callbacks+0x144/0x1a6
(XEN) [<ffff82d080132c52>] softirq.c#__do_softirq+0x82/0x8d
(XEN) [<ffff82d080132caa>] do_softirq+0x13/0x15
(XEN) [<ffff82d080248ae1>] entry.o#process_softirqs+0x21/0x30
(XEN)
(XEN)
(XEN) ****************************************
(XEN) Panic on CPU 3:
(XEN) GENERAL PROTECTION FAULT
(XEN) [error_code=0000]
(XEN) ****************************************
Defer the freeing of d->arch.hvm_domain.pl_time until all timers have been
destroyed.
For safety, NULL out the pointers after freeing them, in an attempt to make
mistakes more obvious in the future.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Since the NMI handler can now recognize watchdog NMIs, make
check_nmi_watchdog() only check for at least two watchdog NMIs. This
prevents false negatives caused by other processors (which may be
being power managed by the BIOS) running at reduced clock frequencies.
We check for more than one NMI since there are apparently systems
where the NMI works only once.
This will also slightly speed up boot times since we only wait the
full 10 ticks if the NMI watchdog on one or more CPUs is not working.
Signed-off-by: David Vrabel <david.vrabel@citrix.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
c/s 0f1cb96e "x86 hvm: Allow cross-vendor migration" caused HVM domains to
unconditionally intercept #UD exceptions. While cross-vendor migration is
cool as a demo, it is extremely niche.
Intercepting #UD allows userspace code in a multi-vcpu guest to execute
arbitrary instructions in the x86 emulator by having one thread execute a ud2a
instruction, and having a second thread rewrite the instruction before the
emulator performs an instruction fetch.
XSAs 105, 106 and 110 are all examples where guest userspace can use bugs in
the x86 emulator to compromise security of the domain, either by privilege
escalation or causing a crash.
c/s 2d67a7a4 "x86: synchronize PCI config space access decoding"
introduced (amongst other things) a per-domain vendor, based on the guests
cpuid policy.
Use the per-guest vendor to enable #UD interception only when a domain is
configured for a vendor different to the current hardware. (#UD interception
is also enabled if hvm_fep is specified on the Xen command line. This is a
debug-only option whose entire purpose is for testing the x86 emulator.)
As a result, the overwhelming majority of usecases now have #UD interception
disabled, removing an attack surface for malicious guest userspace.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Kevin Tian <kevin.tian@intel.com>
Most updates to the exception bitmaps set or clear an individual bits.
However, entering or exiting emulated real mode unilaterally clobbers it,
leaving the exit code to recalculate what it should have been. This is error
prone, and indeed currently fails to recalculate the TRAP_no_device intercept
appropriately.
Instead of overwriting exception_bitmap when entering emulated real mode, move
the override into vmx_update_exception_bitmap() and leave exception_bitmap
unmodified.
This means that recalculation is unnecessary, and that the use of
vmx_fpu_leave() and vmx_update_debug_state() while in emulated real mode
doesn't result in TRAP_no_device and TRAP_int3 being un-intercepted.
This is only a functional change on hardware lacking unrestricted guest
support.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Kevin Tian <kevin.tian@intel.com>
The X86 domain structure already occupied PAGE_SIZE (4096).
Looking @ the memory layout of the structure, we could see that
overall most was occupied by (used the pahole tool on domain.o):
* sizeof(domain.arch) = sizeof(arch_domain) = 3328 bytes.
* sizeof(domain.arch.hvm_domain) = 2224 bytes.
* sizeof(domain.arch.hvm_domain.pl_time) = 1088 bytes.
This patch attempts to free some space, by making the pl_time
field in hvm_domain dynamically allocated.
We xzalloc/xfree it @ hvm_domain_initialise/hvm_domain_destroy.
After this change, the domain structure shrunk w/ 1152 bytes (>1K!).
Signed-off-by: Corneliu ZUZU <czuzu@bitdefender.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
The first Mb handling is not necessary and the attribute of __vmap() is
different for ARM. Factor the first Mb handling only for x86 and define
a mapping attribute for each architecture.
Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
With the addition of ARM64 that does not have a traditional BIOS to
scan, add a config option which is selected on x86 (ia64 doesn't need
it either, it is EFI/UEFI based system) to do the traditional BIOS
scanning for tables.
Signed-off-by: Graeme Gregory <graeme.gregory@linaro.org>
Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
[Linux commit 8a1664be0b922dd6afd60eca96a992ef5ec22c40]
[Include <xen/kconfig.h> in osl.c so that it could use IS_ENABLED]
Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
Reviewed-by: Doug Goldstein <cardoe@cardoe.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
To support using CONFIG_ options in C/CPP expressions, import kconfig.h
from the Linux v4.3 tag (commit id
6a13feb9c82803e2b815eca72fa7a9f5561d7861).
Only import IS_ENABLED for Xen since Xen doesn't support loadable
modules.
Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
Reviewed-by: Doug Goldstein <cardoe@cardoe.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
XRSTORS unconditionally faults when xcomp_bv has bit 63 clear. Instead
of just fixing this issue, overhaul the fault recovery code, which -
one of the many mistakes made when xstate support got introduced - was
blindly mirroring that accompanying FXRSTOR, neglecting the fact that
XRSTOR{,S} aren't all-or-nothing instructions. The new code, first of
all, does all the recovery actions in C, simplifying the inline
assembly used. And it does its work in a multi-stage fashion: Upon
first seeing a fault, state fixups get applied strictly based on what
architecturally may cause #GP. When seeing another fault despite the
fixups done, state gets fully reset. A third fault would then lead to
crashing the domain (instead of hanging the hypervisor in an infinite
loop of recurring faults).
Reported-by: Harmandeep Kaur <write.harmandeep@gmail.com>
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
The packed attribute was pointlessly used here - there are no
misaligned fields, and hence even if the attribute took effect, it
would at best lead to the compiler generating worse code.
At the same time specify the required alignment of the fpu_sse sub-
structure, such that the various typeof() uses on that field obtain
pointers to properly aligned memory (knowledge which a compiler may
want to make use of).
Also add suitable build-time checks.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
We must not clear the compaction bit when using XSAVES/XRSTORS. And
we need to guarantee that xcomp_bv never has any bits clear which
are set in xstate_bv (which requires partly undoing commit 83ae0bb226
["x86/xsave: simplify xcomp_bv initialization"]). Split initialization
of xcomp_bv from the other FPU/SSE/AVX related state setup in
arch_set_info_guest() and hvm_load_cpu_ctxt().
Reported-by: Harmandeep Kaur <write.harmandeep@gmail.com>
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
This patch pauses the domain for all writes through the 'ad'
pointer in monitor_domctl(), defers a domain_unpause() call until
after the CRs are updated for the MONITOR_EVENT_WRITE_CTRLREG
case, and makes sure that the domain is paused for both vm_event
enable and disable cases in vm_event_domctl().
Thanks go to Andrew Cooper for his review and suggestions.
Signed-off-by: Razvan Cojocaru <rcojocaru@bitdefender.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Tamas K Lengyel <tamas@tklengyel.com>
The discussion in [1] lead to an agreement of the missing pieces in PVH
(or HVM without a device-model) in order to progress with it's
implementation.
One of the missing pieces is a new boot ABI, that replaces the PV boot
ABI. The aim of this new boot ABI is to remove the limitations of the
PV boot ABI, that are no longer present when using auto-translated
guests. The new boot protocol should allow to use the same entry point
for both 32bit and 64bit guests, and let the guest choose it's bitness
and paging mode at run time without the domain builder knowing in
advance.
This patch introduces a new document called hvmlite.markdown, with the
intention of merging it into pvh.markdown once the HVMlite implementation
has feature parity with PVH and the old PVH ABI is replaced with the
HVMlite one.
[1] http://lists.xen.org/archives/html/xen-devel/2015-06/msg00258.html
Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reduce the size of struct lock_debug so increases in other lock
structures don't increase the size of struct domain too much.
Signed-off-by: Jennifer Herbert <jennifer.herbert@citrix.com>
Signed-off-by: David Vrabel <david.vrabel@citrix.com>
atomic_compareandswap() used atomic_t as the new, old and returned
values which is less convenient than using just int.
Signed-off-by: David Vrabel <david.vrabel@citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
runstate_guest handles need to be reset to prevent update_runstate_area()
corrupting guest's memory after we resume the guest.
Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com>
It is currently possible to leave a monitor flag enabled even
after vm_event_cleanup_domain() has been called, potentially
leading to a crash in hvm_msr_write_intercept() and hvm_set_crX()
(when v->arch.vm_event has become NULL, but the corresponding
corresponding v->domain->arch.monitor flag is non-zero).
This patch zeroes out arch.monitor in vm_event_cleanup_domain().
Signed-off-by: Razvan Cojocaru <rcojocaru@bitdefender.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Tamas K Lengyel <tamas@tklengyel.com>
Currently in ioreq server, guest write-protected ram pages are
tracked in the same rangeset with device mmio resources. Yet
unlike device mmio, which can be in big chunks, the guest write-
protected pages may be discrete ranges with 4K bytes each. This
patch uses a seperate rangeset for the guest ram pages.
To differentiate the ioreq type between the write-protected memory
ranges and the mmio ranges when selecting an ioreq server, the p2m
type is retrieved by calling get_page_from_gfn(). And we do not
need to worry about the p2m type change during the ioreq selection
process.
Note: Previously, a new hypercall or subop was suggested to map
write-protected pages into ioreq server. However, it turned out
handler of this new hypercall would be almost the same with the
existing pair - HVMOP_[un]map_io_range_to_ioreq_server, and there's
already a type parameter in this hypercall. So no new hypercall
defined, only a new type is introduced.
Signed-off-by: Shuai Ruan <shuai.ruan@linux.intel.com>
Signed-off-by: Yu Zhang <yu.c.zhang@linux.intel.com>
Acked-by: Wei Liu <wei.liu2@citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Reviewed-by: Kevin Tian <kevin.tian@intel.com>
Reviewed-by: Paul Durrant <paul.durrant@citrix.com>
This consolidates some of the different variables used for the ARM
builds. This change was prompted by the Kconfig changes but looking back
in time the CONFIG_ARM_{32,64} variables existed before Kconfig so this
should just be a generic cleanup.
Signed-off-by: Doug Goldstein <cardoe@cardoe.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
[ ijc -- switch from ifdef X to ifeq (X,y) in one place as discussed ]
Coverity CID 1343309
Make GC_FREE reachable in all cases in libxl_get_scheduler() by
eliminating the error-path return and instead storing the error code in
the returned variable.
To make this semantically consistent, change the return type of
libxl_get_scheduler() from libxl_scheduler to int, and make a note of
the interpretation of the return value in libxl.h. N.B. This change
does not change the API in a way that affects functionality.
The libxl_scheduler enum is consistent with the sched_id return value
of xc_sched_id and this must continue to be true.
Suggested-by: Ian Campbell <ian.campbell@citrix.com>
Signed-off-by: Chester Lin <czylin@uwaterloo.ca>
Reviewed-by: Dario Faggioli <dario.faggioli@citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
To more closely follow the guidelines in CODING_STYLE, store the result
of xc_sched_id() in the local variable r, and the check the result of
the call in a separate statement. Change the type of the output
parameter given to xc_sched_id() from libxl_scheduler to int to match
the libxc interface.
Additionally, change the error log statement to more accurately reflect
the failure. This is the only functional change introduced by this
patch.
Suggested-by: Ian Campbell <ian.campbell@citrix.com>
Signed-off-by: Chester Lin <czylin@uwaterloo.ca>
Reviewed-by: Dario Faggioli <dario.faggioli@citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
gcc-6 complains:
xenalyze.c:4132:9: error: 'cr3_compare_total' defined but not used [-Werror=unused-function]
int cr3_compare_total(const void *_a, const void *_b) {
^~~~~~~~~~~~~~~~~
I believe it is correct.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Reviewed-by: George Dunlap <george.dunlap@citrix.com>
gcc-6 adds -Wmisleading-indentation which found these issues.
xenalyze.c: In function 'weighted_percentile':
xenalyze.c:2136:18: error: statement is indented as if it were guarded by... [-Werror=misleading-indentation]
L=I; L_weight = I_weight;
^~~~~~~~
xenalyze.c:2135:9: note: ...this 'if' clause, but it is not
if(J_weight<K_weight)
^~
xenalyze.c:2138:18: error: statement is indented as if it were guarded by... [-Werror=misleading-indentation]
R=J; R_weight = J_weight;
^~~~~~~~
xenalyze.c:2137:9: note: ...this 'if' clause, but it is not
if(K_weight<I_weight)
^~
xenalyze.c: In function 'self_weighted_percentile':
xenalyze.c:2215:18: error: statement is indented as if it were guarded by... [-Werror=misleading-indentation]
L=I; L_weight = I_weight;
^~~~~~~~
xenalyze.c:2214:9: note: ...this 'if' clause, but it is not
if(J_weight<K_weight)
^~
xenalyze.c:2217:18: error: statement is indented as if it were guarded by... [-Werror=misleading-indentation]
R=J; R_weight = J_weight;
^~~~~~~~
xenalyze.c:2216:9: note: ...this 'if' clause, but it is not
if(K_weight<I_weight)
^~
I've modified according to what I think the intention is, i.e. added braces
rather than moving the line in question out a level.
I have only build tested the result.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Reviewed-by: George Dunlap <george.dunlap@citrix.com>
My patch b2700877 "move and amend multicast control documentation"
clarified use of the multicast control protocol between frontend and
backend. However, it transpires that the restrictions that documentation
placed on the "request-multicast-control" flag make it hard for a
frontend to enable 'all multicast' promiscuous mode, in that to do so
would require the frontend and backend to disconnect and re-connect.
This patch adds a new "feature-dynamic-multicast-control" flag to allow
a backend to advertise that it will watch "request-multicast-control" hence
allowing it to be meaningfully modified by the frontend at any time rather
than only when the frontend and backend are disconnected.
Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
Cc: Ian Campbell <ian.campbell@citrix.com>
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Cc: Jan Beulich <jbeulich@suse.com>
Cc: Keir Fraser <keir@xen.org>
Cc: Tim Deegan <tim@xen.org>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Wei Liu <wei.liu2@citrix.com>
Similar to the previous xentoollog case this is not allowed. Switch to
a forward decl of the struct and use of it in the APIs.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
This is used only for xc_evtchn_alloc_unbound and the legacy/compat
versions of the old interfaces and avoids redefining the typedef. The
evtchn_port_or_error_t name is now used only be libxenevtchn.
None of the callers of xc_evtchn_alloc_unbound use the type
themselves.
NB xc_evtchn_alloc_unbound differs from xc_evtchn_bind_unbound_port
and the underlying xenevtchn_bind_unbound_port in that it allows the
specification of the local domain rather than assuming self. This is
only useful during domain build.
Reported-by: Olaf Hering <olaf@aepfle.de>
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
When splitting out various functionality from libxc into tools/libs/*
I attempted to make it possible to avoid callers being unnecessarily
exposed to the xentoollog interface by providing a typedef of the
xentoollog_logger handle in each of the headers.
However such typedefs are not allowed in C, instead it is necessary to
forward declare the struct and then use the struct xentoollog_logger
variant in the prototypes.
It appears that older gcc (e.g. 4.4) complains about this issue while
newer ones (e.g. 4.9) are more tolerant unless -pedantic-errors is
used, this was a deliberate change
https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=ce3765bf44e49ef0568a1ad4a0b7f807591d6412
As well as tools/libs/* it is also now necessary to give libvchan the
same treatment, since it previously inhereted the typedef via one of
tools/libs/*.
Reported-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
"tools/libs/*: Use O_CLOEXEC on Linux and FreeBSD" left some dead code
in the FreeBSD case, which breaks the build on that platform.
Also fix a typo "uint_32".
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Wei Liu <wei.liu2@citrix.com>
We build most of tools using Werror and there seems to be no
deliberate reason for this to be an exception.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Olaf Hering <olaf@aepfle.de>
Acked-by: Tim Deegan <tim@xen.org>
This:
kdd-xen.c: In function 'kdd_access_physical_page':
kdd-xen.c:508:9: warning: implicit declaration of function 'xc_map_foreign_range' [-Wimplicit-function-declaration]
map = xc_map_foreign_range(g->xc_handle,
^
kdd-xen.c:508:13: warning: assignment makes pointer from integer without a cast
map = xc_map_foreign_range(g->xc_handle,
^
was caused by the refactoring of this functionality into
libxenforeignmemory.
Reported by: Olaf Hering <olaf@aepfle.de>
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Tim Deegan <tim@xen.org>
Tested-by: Olaf Hering <olaf@aepfle.de>
Debian bug 812166[0] reported this build failure due to
Wmisleading-indentation with gcc-6:
non-fatal.c: In function 'init_nonfatal_mce_checker':
non-fatal.c:103:2: error: statement is indented as if it were guarded by... [-Werror=misleading-indentation]
switch (c->x86_vendor) {
^~~~~~
non-fatal.c:97:5: note: ...this 'if' clause, but it is not
if ( __get_cpu_var(poll_bankmask) == NULL )
^~
I was unable to reproduce (xen builds cleanly for me with "6.0.0 20160117
(experimental) [trunk revision 232481]") but looking at the code the issue
above is clearly real.
Correctly reindent the if statement.
This file uses Linux coding style (infact the use of Xen style for
this line is the root cause of the wanring) so use tabs and while
there remove the whitespace inside the if as Linux does.
[0] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=812166
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
This fixes the fallout from the HVMlite series, that removed the emulated
PIT from PV(H) guests. Also, this patch forces the hardware domain to
always have an emulated PIT, regardless of whether the toolstack specified
one or not.
Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
The per domain p2m read lock suffers from significant contention when
performance multi-queue block or network IO due to the parallel
grant map/unmaps/copies occuring on the DomU's p2m.
On multi-socket systems, the contention results in the locked compare swap
operation failing frequently which results in a tight loop of retries of the
compare swap operation. As the coherency fabric can only support a specific
rate of compare swap operations for a particular data location then taking
the read lock itself becomes a bottleneck for p2m operations.
Percpu rwlock p2m performance with the same configuration is approximately
64 gbit/s vs the 48 gbit/s with grant table percpu rwlocks only.
Oprofile was used to determine the initial overhead of the read-write locks
and to confirm the overhead was dramatically reduced by the percpu rwlocks.
Note: altp2m users will not achieve a gain if they take an altp2m read lock
simultaneously with the main p2m lock.
Signed-off-by: Malcolm Crossley <malcolm.crossley@citrix.com>
Reviewed-by: George Dunlap <george.dunlap@citrix.com>
The per domain grant table read lock suffers from significant contention when
performance multi-queue block or network IO due to the parallel
grant map/unmaps/copies occurring on the DomU's grant table.
On multi-socket systems, the contention results in the locked compare swap
operation failing frequently which results in a tight loop of retries of the
compare swap operation. As the coherency fabric can only support a specific
rate of compare swap operations for a particular data location then taking
the read lock itself becomes a bottleneck for grant operations.
Standard rwlock performance of a single VIF VM-VM transfer with 16 queues
configured was limited to approximately 15 gbit/s on a 2 socket Haswell-EP
host.
Percpu rwlock performance with the same configuration is approximately
48 gbit/s.
Oprofile was used to determine the initial overhead of the read-write locks
and to confirm the overhead was dramatically reduced by the percpu rwlocks.
Signed-off-by: Malcolm Crossley <malcolm.crossley@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Per-cpu read-write locks allow for the fast path read case to have
low overhead by only setting/clearing a per-cpu variable for using
the read lock. The per-cpu read fast path also avoids locked
compare swap operations which can be particularly slow on coherent
multi-socket systems, particularly if there is heavy usage of the
read lock itself.
The per-cpu reader-writer lock uses a local variable to control
the read lock fast path. This allows a writer to disable the fast
path and ensures the readers switch to using the underlying
read-write lock implementation instead of the per-cpu variable.
Once the writer has taken the write lock and disabled the fast path,
it must poll the per-cpu variable for all CPU's which have entered
the critical section for the specific read-write lock the writer is
attempting to take. This design allows for a single per-cpu variable
to be used for read/write locks belonging to seperate data structures.
If a two or more different per-cpu read lock(s) are taken
simultaneously then the per-cpu data structure is not used and the
implementation takes the read lock of the underlying read-write lock,
this behaviour is equivalent to the slow path in terms of performance.
The per-cpu rwlock is not recursion safe for taking the per-cpu
read lock because there is no recursion count variable, this is
functionally equivalent to standard spin locks.
Slow path readers which are unblocked, set the per-cpu variable and
drop the read lock. This simplifies the implementation and allows
for fairness in the underlying read-write lock to be taken
advantage of.
There is more overhead on the per-cpu write lock path due to checking
each CPUs fast path per-cpu variable but this overhead is likely be
hidden by the required delay of waiting for readers to exit the
critical section. The loop is optimised to only iterate over
the per-cpu data of active readers of the rwlock. The cpumask_t for
tracking the active readers is stored in a single per-cpu data
location and thus the write lock is not pre-emption safe. Therefore
the per-cpu write lock can only be used with interrupts disabled.
Signed-off-by: Malcolm Crossley <malcolm.crossley@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: George Dunlap <george.dunlap@citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
This means adding -L for libxen{evtchn,gnttab,foreignmemory} so that
it can link them directly (rather than using the libxenctrl compat
layer exposed via -rpath-link). Also add -I for libxenforeignmemory.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Wei Liu <wei.liu2@citrix.com>
In some cases this replaces an FD_CLOEXEC dance, in others it is new.
Linux has had O_CLOEXEC since 2.6.23 (October 2007), so we can rely on
it from Xen 4.7 I think. Some libc headers may still lack the
definition, so we take care of that if need be by defining to 0 (on
the premise that such an old glibc might barf on O_CLOEXEC even if the
kernel may or may not be so old).
All stable versions of FreeBSD support O_CLOEXEC (10.2, 9.3 and 8.4),
and we assume the libc there does too.
Remove various comments about having to take responsibility for this
(since really it is just hygiene, politeness, not a requirement) and
the reasons for using O_CLOEXEC seem pretty straightforward.
Backends for other OSes are untouched.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Roger Pau Monné <roger.pau@citrix.com>
Acked-by: Wei Liu <wei.liu2@citrix.com>
Cc: Roger.Pau@citrix.com
Cc: jbeulich@suse.com
Much like for gnttab and foreignmemory xencall hypercall buffers need
care.
Evtchn is a bit simpler (no magic mappings) but may not work from
parent + child simultaneously, document "parent only" since it is
consistent with the others.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Wei Liu <wei.liu2@citrix.com>
This avoids a potential issue with a fork after allocation but before
madvise.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Wei Liu <wei.liu2@citrix.com>
These are already arch specific, so just use the appropriate
interfaces (as determined by looking at the xc_memalign backend).
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Wei Liu <wei.liu2@citrix.com>
This behaviour has been confirmed by inspection on:
- Linux
- NetBSD & FreeBSD (NB: hcall->retval is the hypercall return value
only for values >= 0. For negative values the underlying privcmd
driver translates the value from Xen to {Net,Free}BSD errno space
and returns it as the result of the ioctl, which becomes
ret=-1/errno=EFOO in userspace)
- MiniOS (which takes care of errno in this library)
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Wei Liu <wei.liu2@citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Roger Pau Monné <roger.pau@citrix.com>
Cc: Roger Pau Monné <roger.pau@citrix.com>
In particular around error handling, behaviour on fork and the unmap
notification mechanism.
Behaviour of xengnttab_map_*grant_refs and xengntshr_share_pages on
partial failure has been confirmed/inferred (by inspection) on Linux
and Mini-os (the only two known implementations. Likewise the
behaviour of the notification mechanism has been confirmed/inferred
(by inspection) of the Linux implementation (currently the only
implementation) and libvchan (primary known user).
These updates are not folded into "tools: Refactor
/dev/xen/gnt{dev,shr} wrappers into libxengnttab." to try and reduce
the amount of non-movement changes in that patch.
While I'm not convinced by javadoc/doxygen cause the existing comments
which appear to use that syntax to have the appropriate /** marker.
Also fix a typo in a code comment.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Reviewed-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Acked-by: Wei Liu <wei.liu2@citrix.com>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>
These were wrong in the context of libxc before this code was
extracted, clean them up.
Also add some emacs magic blocks
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Wei Liu <wei.liu2@citrix.com>
Juergen Gross
Andrew Cooper
David Vrabel
Corneliu ZUZU
Razvan Cojocaru
Shannon Zhao
Graeme Gregory
Jan Beulich
Roger Pau Monné
Jennifer Herbert
Vitaly Kuznetsov
Shuai Ruan
Doug Goldstein
Chester Lin
Ian Campbell
Paul Durrant
Malcolm Crossley