Currently VMCB's MSRPM can be updated to either intercept both reads and
writes to an MSR or not intercept neither. In some cases we may want to
be more selective and intercept one but not the other.
Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Reviewed-by: Dietmar Hahn <dietmar.hahn@ts.fujitsu.com>
With the need to allocate multiple contiguous IRTEs for multi-vector
MSI, the chance of failure here increases. While on the AMD side
there's no allocation of IRTEs at present at all (and hence no way for
this allocation to fail, which is going to change with a later patch in
this series), VT-d already ignores an eventual error here, which this
patch fixes.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: "Zhang, Xiantao" <xiantao.zhang@intel.com>
This adds the ability for a vTPM to constrain what localities a given
client domain can use based on its XSM label. For example:
locality=user_1:vm_r:domU_t=0,1,2 locality=user_1:vm_r:watcher_t=5
An arbitrary prefix can be matched by using a '*'.
Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
This changes the save format of the vtpm stubdom to include two copies
of the saved data: one active, and one inactive. When saving the state,
data is written to the inactive slot before updating the key and hash
saved with the TPM Manager, which determines the active slot when the
vTPM starts up.
Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
The vTPM protocol now contains a field allowing the locality of a
command to be specified; pass this to the TPM when processing a packet.
While the locality is not currently checked for validity, a binding
between locality and some distinguishing feature of the client domain
(such as the XSM label) will need to be defined in order to properly
support a multi-client vTPM.
Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Acked-by: Matthew Fioravante <matthew.fioravante@jhuapl.edu>
The vtpm2 ABI supports packets of up to 4088 bytes by default; expose
this property though the TPM's interface so clients do not attempt to
send larger packets.
Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Instead of only recording the UUID field, which may not be of interest
to all tpmback implementations, provide a user-settable opaque pointer
associated with the tpmback instance.
Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
The open/close callbacks in tpmback cannot be properly initalized in
order to catch the initial enumeration events because init_tpmback
clears the callbacks and then asynchronously starts the enumeration of
existing tpmback devices. Fix this by passing the callbacks to
init_tpmback so they can be installed before enumeration.
This also removes the unused callbacks for suspend and resume.
Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Allow the vtpm device to be disconnected and reconnected so that a
bootloader (like pv-grub) can submit measurements and return the vtpm
device to its initial state before booting the target kernel.
Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
This changes the vTPM shared page ABI from a copy of the Xen network
interface to a single-page interface that better reflects the expected
behavior of a TPM: only a single request packet can be sent at any given
time, and every packet sent generates a single response packet. This
protocol change should also increase efficiency as it avoids mapping and
unmapping grants when possible. The vtpm xenbus device now requires a
feature-protocol-v2 node in xenstore to avoid conflicts with existing
(xen-patched) kernels supporting the old interface.
While the contents of the shared page have been defined to allow packets
larger than a single page (actually 4088 bytes) by allowing the client
to add extra grant references, the mapping of these extra references has
not been implemented; a feature node in xenstore may be used in the
future to indicate full support for the multi-page protocol. Most uses
of the TPM should not require this feature.
Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Cc: Jan Beulich <JBeulich@suse.com>
xl list -l should produce readable output when built with yajl2 so
it is compatible with the xendomains script.
Signed-off-by: Michael Young <m.a.young@durham.ac.uk>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Now that the hotplug scripts have been fixed to remove hardcoded paths lets
try this again. From 26470:acaf29203cf9:
This is the defacto (or FHS mandated?) standard location for software
built from source, in order to avoid clashing with packaged software
which is installed under /usr/bin etc.
I think there is benefit in having Xen's install behave more like the
majority of other OSS software out there.
The major downside here is in the transition from 4.2 to 4.3 where
people who have built from source will innevitably discover breakage
because 4.3 no longer overwrites stuff in /usr like it used to so they
pickup old stale bits from /usr instead of new stuff from /usr/local.
Packages will use ./configure --prefix=/usr or whatever helper macro
their package manager gives them. I have confirmed that doing this
results in the same list of installed files as before this patch was
applied.
The hypervisor remains in /boot/ and there is no intention to move it.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Roger Pau Monné <roger.pau@citrix.com>
Poll() can support more file descriptors than select(). We've done this for
xenconsoled, now do this for cxenstored as well.
The code is taken from xenconsoled and modified to adapt to cxenstored.
Note that poll() semantic is a bit different from select(). In Linux, if a fd
is set in IN/OUT fd_set and error occurs inside select(), this fd is still
considered readable / writable, and it is set in the returned IN/OUT fd_set.
So in later handle_input / handle_output, the connection will eventually be
talloc_free'ed(). After switching to poll(), we should take care of any error
right away, making the code clearer.
Signed-off-by: Wei Liu <wei.liu2@citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
When NEWLIB_STAMPFILE is updated but gmp has already been extracted, the mv
command will incorrectly create a subdirectory instead of renaming. Remove the
old target before renaming to fix this.
Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Linux uses GICC_CTLR.EOImodeNS set to 0, which means both priority drop and
deactivate interrupt functionality are made when something is written in
GICC_EOIR.
As the ARM manual specifies: "having an active interrupt in the List registers
with a priority that is not set in the corresponding Active Priorities
register" when GICV_CTLR.EOImode (ie GICC_CTLR.EOImodeNS in the guest context)
result in unpredicable behavior, we need to save/restore GICH_APR.
Signed-off-by: Julien Grall <julien.grall@citrix.com>
Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Use xen-hotplugpath.sh (as NetBSD does) which allows PREFIX etc to change.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Roger Pau Monne <roger.pau@citrix.com>
Bug: xl lexical analyzer cannot parse keyword which has .(dot) character like vif.default.script
ref: 733b9c524d
Error log: /etc/xen/xl.conf:28: config parsing error near `.default.script="vif-bridge"': lexical error
Signed-off-by: Choonho Son <choonho.son@gmail.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Roger Pau Monne <roger.pau@citrix.com>
Also add a reference to tools/libxc/xenctrl.h, which is where
the underlying C functions are defined.
Signed-off-by: David Scott <dave.scott@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Remove the mention of the C function names from the .mli -- this is only
needed in the implementation .ml
Signed-off-by: David Scott <dave.scott@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
It's a common OCaml convention to add a 'type t' in a module to
represent the main "thing" that the module is about. We add an
opaque type t and to_int/of_int functions for those who really
need it, in particular:
1. to_int is needed for debug logging; and
2. both to_int and of_int are needed for anyone who communicates
a port number through xenstore.
Signed-off-by: David Scott <dave.scott@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
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// ]
Boris Ostrovsky
Jan Beulich
Daniel De Graaf
M A Young
Ian Campbell
Wei Liu
Tim Deegan
Julien Grall
Ian Jackson
Choonho Son
David Scott
Christoph Egger