I hereby volunteer myself to maintain the OCaml tools (/tools/ocaml)
in particular:
* the OCaml bindings
* the OCaml xenstored
Signed-off-by: David Scott <dave.scott@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
This is also defined in sys/ptrace.h on arm64 which breaks the tools build due
to multiple definitions. I expect this is really a bug in the kernel and/or
glibc but we don't really need this symbol in the public headers, at least not
right now, so move it into include/asm instead.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
I'm not mad keen on propagating these sorts of asm atomic operations throughout
our code base. Other options would be:
- use libatomic-ops, http://www.hpl.hp.com/research/linux/atomic_ops/, although
this doesn't seem to be as widespread as I would like (not in RHEL5 for
example)
- use a pthread lock. This is probably the simplest/best option but I wasn't
able to figure out the locking hierarchy of this code
So I've copped out and just copied the appropriate inlines here.
I also nuked some stray ia64 support and fixed a coment in the arm32 version
while I was here.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
tools/python and tools/pygrub are already skipped in tools/Makefile when
cross-compiling, so no point in checking for the prerequisites either.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
arm64 only has the eventfd2 system call and using the libc wrapper when
available hides this from us. eventfd() has been in libc since glibc 2.8.
This code is already Linux specific.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
getconf is not cross-compile friendly since it reports the features of the host
and not the target. There doesn't appear to be a $triplet-getconf.
AC_SYS_LARGEFILE arranges for #defines to appear in config.h however Xen's
build system expects these to be part of C{PP}FLAGS. Since I'm not confident
that everything in Xen includes config.h I instead arrange for the result of
running AC_SYS_LARGERFILE to end up in CFLAGS.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
scale_delta(), which is being called by that function, doesn't cope
with that.
Also print a warning message, so hopefully we can eventually figure why
occasionally a negative value results from the calculation in the first
place.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Keir Fraser <keir@xen.org>
As well as using x<N> rather than r<N> registers for passing arguments/results
as mandate the use of x16 as the hypercall number.
Add some pedantry about struct alignment layout referencing the ARM Procedure
Calling Standard to avoid confusion with the previous "OABI" convention. While
at it also mandate that hypercall argument structs are always little endian.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Make the "CPU<n> booted" message fit in with the surrounding logging.
Log which CPU is taking an unexpected trap.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
On ARM the evtchn upcall is done by using a local PPI interrupt. However the
guest will clear the evtchn_upcall_pending bit before it EOIs that PPI (which
happens late). This means vgic_vcpu_inject_irq (called via
vcpu_mark_events_pending) sees the PPI as in flight and ends up not reinjecting
it, if this happens after the guest has finished its event channel processing
loop but before the EOI then we have lost the upcall.
To fix this we need to check if an evtchn upcall is pending when returning to
the guest and if so reinject the PPI.
We therefore also need to call gic_restore_pending_irqs on the exit to guest
path in order to pickup any newly inject IRQ and propagate it into a free LR.
This doesn't currently support bumping a lower priority interrupt out of the
LRs in order to inject a new higher priority interrupt. We don't yet implement
interrupt prioritisation (and guests don't use it either) so this will do for
now.
Since gic_restore_pending_irqs is now called in the return to guest path it is
called with interrupts disabled and accordingly must use the
irqsave/irqrestore spinlock primitives.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
In particular be sure to initisalise HCR_EL2 on secondary processors.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
[ ijc -- adjusted due to unapplied "trap guest WFI" by s/HCR_TWI// ]
The major aspect being the removal of the overload of the MSI entry's
mask_base field for MSI purposes - a proper union is being installed
instead, tracking both the config space position needed and the number
of vectors used (which is going to be 1 until the actual multi-vector
MSI patches arrive).
It also corrects misleading information from debug key 'M': When
msi_get_mask_bit() returns a negative value, there's no mask bit, and
hence output shouldn't give the impression there is.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Do not unmask the emulated phys_timer when the related Xen timer
expires.
Do not inject the phys_timer interrupt if it is masked.
Do not let the user set CNTx_CTL_PENDING directly.
Set CNTx_CTL_PENDING when the phys_timer expires and clear it when the
phys_timer is disabled or the compare value is changed.
Define offset and cval as uint64_t given that they can't be negative and
they are used as uint64_t arguments.
Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
This is intentionally adding code not well formatted (so it stands out)
and expected to be reverted as soon as the problem with the timer wraps
has been spotted.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Looking at map_domain_page_global, there doesn't seem to be any locking
preventing two CPUs from populating a page of global-map l1es at the
same time.
Signed-off-by: Tim Deegan <tim@xen.org>
Allow the "usbdevice" key to accept a list of USB devices, and pass
them in using the new usbdevice_list domain build element.
For backwards compatibility, still accept singleton values.
Also update the xl.cfg manpage, adding information about how to pass
through host devices.
as applied:
- Fix trailing whitespace and wrap some lines in xl_cmdimpl.c -iwj
v2:
- Add some verbiage to make it clear that "usb" is for emulated devices
- Reference qemu manual for more usbdevice options
Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
This patch allows an HVM domain to be created with multiple USB
devices.
Since the previous interface only allowed the passing of a single
device, this requires us to add a new element to the hvm struct of
libxl_domain_build_info -- usbdevice_list. For API compatibility, the
old element, usbdevice, remains.
If hvm.usbdevice_list is set, each device listed will cause an extra
"-usbdevice [foo]" to be appended to the qemu command line.
Callers may set either hvm.usbdevice or hvm.usbdevice_list, but not
both; libxl will throw an error if both are set.
In order to allow users of libxl to write software compatible with
older versions of libxl, also define LIBXL_HAVE_BUILDINFO_USBDEVICE_LIST.
If this is defined, callers may use either hvm.usbdevice or
hvm.usbdevice_list; otherwise, only hvm.usbdevice will be available.
as applied:
- Fix whitespace errors -iwj
v3:
- Duplicate functionality in both "new" and "old", since we're not
unifying the two anymore.
v2:
- Throw an error if both usbdevice and usbdevice_list are set
- Update and clarify definition based on feedback
- Previous patches means this works for both traditional and upstream
Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
In xl.conf, autoballoon="auto" will do the right thing for most
people. Make it the default (instead of "on").
Signed-off-by: David Vrabel <david.vrabel@citrix.com>
Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
autoballoon=1 is not recommened if dom0_mem was used to reduce the
amount of dom0 memory. Instead of requiring users to change xl.conf
if they do this, extend the autoballoon option with a new choice:
"auto".
With autoballoon="auto", autoballooning will be disabled if dom0_mem
was used on the Xen command line.
For consistency, accept "on" and "off" as valid autoballoon options (1
and 0 are still accepted).
The default remains "on" for now.
Signed-off-by: David Vrabel <david.vrabel@citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
This was missed by c/s 23936:cdb34816a40a which renamed xl -> xenlight
[ 23936:cdb34816a40a is 7ceaa0c744 in git -iwj ]
Reported-by: alien@rmail.be
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
This patch extends the printout of the VPCU infos of the keyhandler 'q'.
If vPMU is enabled is on the VCPU and active lines are printed like
(when running HVM openSuSE-12.3 with 'perf top');
(XEN) vPMU running
(XEN) general_0: 0x000000ffffff3ae1 ctrl: 0x000000000053003c
(XEN) fixed_1: 0x000000ff90799188 ctrl: 0xb
This means general counter 0 and fixed counter 1 are running with showing
their contents and the contents of their configuration msr.
Signed-off-by: Dietmar Hahn <dietmar.hahn@ts.fujitsu.com>
Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Acked-by: Jun Nakajima <jun.nakajima@intel.com>
This patch renames core2_counters to core2_fix_counters for better
understanding the code and subtitutes 2 numerals with defines in fixed counter
handling.
Signed-off-by: Dietmar Hahn <dietmar.hahn@ts.fujitsu.com>
Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Acked-by: Jun Nakajima <jun.nakajima@intel.com>
remus: init sch_plug module based on kernel version
sch_plug module, for network buffering, is available as part of linux
kernel (from 3.4 onwards), as opposed to an out-of-tree module.
The netlink message format to talk to the in-kernel module is different from
that of the old version. So, before initializing the Plug Qdisc, check
the kernel version and use the appropriate message format.
Also change the names of the constants to reflect the format used by the mainline
module [CHECKPOINT -> BUFFER , RELEASE -> RELEASE_ONE ].
Signed-off-by: Shriram Rajagopalan <rshriram@cs.ubc.ca>
Otherwise a dangling pointer can be left, which would cause subsequent
memory corruption as soon as the space got re-allocated for some other
purpose.
This is CVE-2013-1920 / XSA-47.
Reported-by: Wei Liu <wei.liu2@citrix.com>
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Tim Deegan <tim@xen.org>
Xenheap pages will always have an extra typecount, taken in
share_xen_page_with_guest(), which doesn't come from a shadow PTE.
Adjust the warning in sh_remove_all_mappings() to account for it.
Reported-by: Andrew Cooper <andrew.cooper3@citrix.com>
Signed-off-by: Tim Deegan <tim@xen.org>
Tested-by: Andrew Cooper <andrew.cooper3@citrix.com>
commit e7dda8ec9f
VMX: disable SMEP feature when guest is in non-paging mode
disabled the SMEP bit if a guest VCPU was using HAP and was not
in paging mode. However I could observe VCPUs getting stuck in
the trampoline after the following patch in the Linux kernel
changed the way CR4 gets set up:
x86, realmode: read cr4 and EFER from kernel for 64-bit trampoline
The change will set CR4 from already set flags which includes the
SMEP bit. On bare metal this does not matter as the CPU is in non-
paging mode at that time. But Xen seems to use the emulated non-
paging mode regardless of HAP (I verified that on the guests I was
seeing the issue, HAP was not used).
Therefor it seems right to unset the SMEP bit for a VCPU that is
not in paging-mode, regardless of its HAP usage.
Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
Acked-by: Keir Fraser <keir@xen.org>
Acked-by: Dongxiao Xu <dongxiao.xu@intel.com>
When in SYS_STATE_suspend, and going through the cpu_disable_scheduler
path, save a copy of the current cpu affinity, and mark a flag to
restore it later.
Later, in the resume process, when enabling nonboot cpus restore these
affinities.
Signed-off-by: Ben Guthro <benjamin.guthro@citrix.com>
Acked-by: George Dunlap <george.dunlap@eu.citrix.com>
Acked-by: Keir Fraser <keir@xen.org>
Since the main loop in the function includes legacy vectors, and since
vector_irq[] gets set up for legacy vectors regardless of whether those
get handled through the IO-APIC, it must not do anything on this vector
range. In fact, we should never get past the move_cleanup_count check
for IRQs not handled through the IO-APIC. Adding a respective assertion
woulkd make those iterations more expensive (due to the lock acquire).
For such an assertion to not have false positives we however ought to
suppress setting up IRQ2 as an 8259A interrupt (which wasn't correct
anyway), which is being done here despite the assertion not actually
getting added.
Furthermore, there's no point iterating over the vectors past
LAST_HIPRIORITY_VECTOR, so terminate the loop accordingly.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Keir Fraser <keir@xen.org>
This keeps the behaviour of strobing the IRQ line every time any RTC
interrupt source is raised. I rather suspect (based on the behaviour
of the MC146818A RTC) that we ought to be suppressing all subsequent
interrupts whenever RTC_IRQF is set, but this way avoids making
guest-visible changes.
Signed-off-by: Tim Deegan <tim@xen.org>
Acked-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Keir Fraser <keir@xen.org>
When the RTC periodic timer gets restarted, align it to the VM's boot
time, not to whatever time it is now. Otherwise every read of REG_C
will restart the current period
Signed-off-by: Tim Deegan <tim@xen.org>
Acked-by: Keir Fraser <keir@xen.org>
Acked-by: Jan Beulich <jbeulich@suse.com>
Among other things, arch_domain_create() sets the shadow(/hap/p2m)
memory allocation, which must happen after vcpus are assigned (or the
shadow op will fail) but before memory is allocated (or we might run
out of p2m memory).
libxl__build_pre(), which already sets similar things like maxmem,
semes like a reasonable spot for it. That needed a bit of plumbing to
get the right datastructure from the caller.
As a side-effect, the return code from libxl__arch_domain_create() is
no longer ignored.
This bug was analysed in:
From: "Jan Beulich" <JBeulich@xxxxxxxx>
"Re: [Xen-devel] [xen-unstable test] 16788: regressions - FAIL"
Date: Mon, 04 Mar 2013 16:34:53 +0000
http://lists.xen.org/archives/html/xen-devel/2013-03/msg00191.html
Reported-by: Jan Beulich <JBeulich@suse.com>
Signed-off-by: Tim Deegan <tim@xen.org>
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: Ian Campbell <ian.campbell@citrix.com>
The following patch:
tools: Retry blktap2 tapdisk message on interrupt.
Addressed a long standing regression with the blktap2 control
plane. An interruption of the select system call would
prematurely terminate the message sequence needed to properly
shutdown a blktap2 tapdisk instance.
Ian Jackson correctly noted that the read and write systems calls
responsible for receiving and sending the control messages could
also return EINTR resulting in similar effects. While this
regression was not noted in field testing this patch adds support
to re-start the calls to provide a technically complete
implementation of control plane management in the presence of
signals.
Signed-off-by: Dr. Greg Wettstein <xen@wind.enjellic.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
In particular, on broadcast/multicast INIT/SIPI, we handle all target
APICs at once in a single invocation of the init/sipi tasklet. This
avoids needing to return an X86EMUL_RETRY error code to the caller,
which was being ignored by all except x86_emulate().
The original bug, and the general approach in this fix, pointed out by
Intel (yang.z.zhang@intel.com).
Signed-off-by: Keir Fraser <keir@xen.org>
With the recent two fixes to ERST handling, this should no longer be
necessary.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Tested-by: Andrew Cooper <andrew.cooper3@citrix.com>
Ian Campbell
David Scott
Jan Beulich
Christoph Egger
Stefano Stabellini
Tim Deegan
George Dunlap
David Vrabel
Andrew Cooper
Dietmar Hahn
Shriram Rajagopalan
Stefan Bader
Ben Guthro
Keir Fraser
Ian Jackson
Dr. Greg Wettstein