Currently, ARM32 and ARM64 has different SError exception handlers.
These handlers include lots of code to check SError handle options
and code to distinguish guest-generated SErrors from hypervisor
SErrors.
The new helpers: do_trap_guest_serror and do_trap_hyp_serror are
wrappers of __do_trap_serror with constant guest/hyp parameters.
__do_trap_serror moves the option checking code and SError checking
code from assembly to C source. This will make the code become more
readable and avoid placing check code in too many places.
These two helpers only handle the following 3 types of SErrors:
1) Guest-generated SError and had been delivered in EL1 and then
been forwarded to EL2.
2) Guest-generated SError but hadn't been delivered in EL1 before
trapping to EL2. This SError would be caught in EL2 as soon as
we just unmasked the PSTATE.A bit.
3) Hypervisor generated native SError, that would be a bug.
In the new helpers, we have used the function "inject_vabt_exception"
which was disabled by "#if 0" before. Now, we can remove the "#if 0"
to make this function to be available.
Signed-off-by: Wei Chen <Wei.Chen@arm.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
We want to move part of SErrors checking code from hyp_error assembly code
to a function. This new function will use this macro to distinguish the
guest SErrors from hypervisor SErrors. So we have to move this macro to
common header.
The VABORT_GEN_BY_GUEST macro uses the symbols abort_guest_exit_start
and abort_guest_exit_end. After we move this macro to a common header,
we need to make sure that the two symbols are visible to other source
files. Currently, they are declared .global in arm32/entry.S, but not
arm64/entry.S. Fix that.
Signed-off-by: Wei Chen <Wei.Chen@arm.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
We have provided an option to administrator to determine how to
handle the SErrors. In order to skip the check of pending SError,
in conventional way, we have to read the option every time before
we try to check the pending SError. This will add overhead to check
the option at every trap.
The ARM32 supports the alternative patching feature. We can use an
ALTERNATIVE to avoid checking option at every trap. We added a new
cpufeature named "SKIP_SYNCHRONIZE_SERROR_ENTRY_EXIT". This feature
will be enabled when the option is not diverse.
Signed-off-by: Wei Chen <Wei.Chen@arm.com>
Reviewed-by: Julien Grall <julien.grall@arm.com>
We have provided an option to administrator to determine how to
handle the SErrors. In order to skip the check of pending SError,
in conventional way, we have to read the option every time before
we try to check the pending SError. This will add overhead to check
the option at every trap.
The ARM64 supports the alternative patching feature. We can use an
ALTERNATIVE to avoid checking option at every trap. We added a new
cpufeature named "SKIP_SYNCHRONIZE_SERROR_ENTRY_EXIT". This feature
will be enabled when the option is not diverse.
Signed-off-by: Wei Chen <Wei.Chen@arm.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
In the later patches of this series, we want to use the alternative
patching framework to avoid synchronizing serror_op in every entries
and exits. So we define a new cpu feature "SKIP_SYNCHRONIZE_SERROR_ENTRY_EXIT"
for serror_op. When serror_op is not equal to SERROR_DIVERSE, this
feature will be set to cpu_hwcaps.
Currently, the default serror_op is SERROR_DIVERSE, if we want to
change the serror_op value we have to place the serror parameter
in command line. It seems no problem to update cpu_hwcaps directly
in the serror parameter parsing function.
While the default option will be diverse today, this may change in the
future. So we introduce this initcall to guarantee the cpu_hwcaps can be
updated no matter the serror parameter is placed in the command line
or not.
Signed-off-by: Wei Chen <Wei.Chen@arm.com>
Acked-by: Julien Grall <julien.grall@arm.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
In order to distinguish guest-generated SErrors from hypervisor-generated
SErrors we have to place SError checking code in every EL1 <-> EL2 paths.
That will cause overhead on entries and exits due to dsb/isb.
However, not all platforms want to categorize SErrors. For example, a host
that is running with trusted guests. The administrator can confirm that
all guests that are running on the host will not trigger such SErrors. In
this use-case, we should provide some options to administrators to avoid
categorizing SErrors and then reduce the overhead of dsb/isb.
We provided the following 3 options to administrators to determine how
the hypervisors handle SErrors:
* `diverse`:
The hypervisor will distinguish guest SErrors from hypervisor SErrors.
The guest generated SErrors will be forwarded to guests, the hypervisor
generated SErrors will cause the whole system to crash.
It requires:
1. dsb/isb on all EL1 -> EL2 trap entries to categorize SErrors
correctly.
2. dsb/isb on EL2 -> EL1 return paths to prevent slipping hypervisor
SErrors to guests.
3. dsb/isb in context switch to isolate SErrors between 2 vCPUs.
* `forward`:
The hypervisor will not distinguish guest SErrors from hypervisor
SErrors. All SErrors will be forwarded to guests, except the SErrors
generated when the idle vCPU is running. The idle domain doesn't have
the ability to handle SErrors, so we have to crash the whole system when
we get SErros with the idle vCPU. This option will avoid most overhead
of the dsb/isb, except the dsb/isb in context switch which is used to
isolate the SErrors between 2 vCPUs.
* `panic`:
The hypervisor will not distinguish guest SErrors from hypervisor SErrors.
All SErrors will crash the whole system. This option will avoid all
overhead of the dsb/isb pairs.
Signed-off-by: Wei Chen <Wei.Chen@arm.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
When guest triggers async aborts, in most platform, such aborts
will be routed to hypervisor. But we don't want the hypervisor
to handle such aborts, so we have to route such aborts back to
the guest.
This helper is using the HCR_EL2.VSE (HCR.VA for aarch32) bit to
route such aborts back to the guest. After updating HCR_EL2.VSE bit
in vCPU context, we write the value to HCR_EL2 immediately. In this
case we don't need to move the restoration of HCR_EL2 to other place,
and it worked regardless of whether we get preempted.
If the guest PC had been advanced by SVC/HVC/SMC instructions before
we caught the SError in hypervisor, we have to adjust the guest PC to
exact address while the SError generated.
About HSR_EC_SVC32/64, even thought we don't trap SVC32/64 today,
we would like them to be handled here. This would be useful when
VM introspection will gain support of SVC32/64 trapping.
After updating HCR_EL2.VSE bit of vCPU HCR_EL2, write the value
to HCR_EL2 immediately. In this case we don't need to move the
restoration of HCR_EL2 to leave_hypervisor_tail, and it worked
regardless of whether we get preempted.
This helper will be used by the later patches in this series, we
use #if 0 to disable it in this patch temporarily to remove the
warning message of unused function from compiler.
Signed-off-by: Wei Chen <Wei.Chen@arm.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
Reviewed-by: Julien Grall <julien.grall@arm.com>
The HCR_EL2.VSE (HCR.VA for aarch32) bit can be used to generate a
virtual abort to guest. The HCR_EL2.VSE bit has a peculiar feature
of getting cleared when the guest has taken the abort (this is the
only bit that behaves as such in HCR_EL2 register).
This means that if we set the HCR_EL2.VSE bit to signal such an abort,
we must preserve it in the guest context until it disappears from
HCR_EL2, and at which point it must be cleared from the context. This
is achieved by reading back from HCR_EL2 until the guest takes the
fault.
If we preserved a pending VSE in guest context, we have to restore
it to HCR_EL2 when context switch to this guest. This is achieved
by writing saved HCR_EL2 value in guest context back to HCR_EL2
register before return to guest. This had been done by the patch
of "Restore HCR_EL2 register".
Signed-off-by: Wei Chen <Wei.Chen@arm.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
The HCR_EL2 flags for 64-bit and 32-bit domains are different. But
when we initialized the HCR_EL2 for vcpu0 of Dom0 and all vcpus of
DomU in vcpu_initialise, we didn't know the domain's address size
information. We had to use compatible flags to initialize HCR_EL2,
and set HCR_RW for 64-bit domain or clear HCR_RW for 32-bit domain
at every context switch.
But, after we added the HCR_EL2 to vcpu's context, this behaviour
seems a little fussy. We can update the HCR_RW bit in vcpu's context
as soon as we get the domain's address size to avoid setting/clearing
HCR_RW at every context switch.
Signed-off-by: Wei Chen <Wei.Chen@arm.com>
Acked-by: Julien Grall <julien.grall@arm.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
Different domains may have different HCR_EL2 flags. For example, the
64-bit domain needs HCR_RW flag but the 32-bit does not need it. So
we give each domain a default HCR_EL2 value and save it in the vCPU's
context.
HCR_EL2 register has only one bit can be updated automatically without
explicit write (HCR_VSE). But we haven't used this bit currently, so
we can consider that the HCR_EL2 register will not be modified while
the guest is running. So save the HCR_EL2 while guest exiting to
hypervisor is not neccessary. We just have to restore this register for
each vCPU while context switching.
The p2m_restore_state which will be invoked in context switch progress
has included the writing of HCR_EL2 already. It updates the HCR_EL2.RW
bit to tell the hardware how to interpret the stage-1 page table as the
encodings are different between AArch64 and AArch32. We can reuse this
write to restore the HCR_EL2 for each vCPU. Of course, the value of each
vCPU's HCR_EL2 should be adjusted to have proper HCR_EL2.RW bit in this
function. In the later patch of this series, we will set the HCR_EL2.RW
for each vCPU while the domain is creating.
Signed-off-by: wei chen <Wei.Chen@arm.com>
Reviewed-by: Julien Grall <julien.grall@arm.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
We want to add HCR_EL2 register to Xen context switch. And each copy
of HCR_EL2 in vcpu structure will be initialized with the same set
of trap flags as the HCR_EL2 register. We introduce a helper here to
represent these flags to be reused easily.
Signed-off-by: Wei Chen <Wei.Chen@arm.com>
Reviewed-by: Julien Grall <julien.grall@arm.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
Xen will do exception syndrome check while some types of exception
take place in EL2. The syndrome check code read the ESR_EL2 register
directly, but in some situation this register maybe overridden by
nested exception.
For example, if we re-enable IRQ before reading ESR_EL2 which means
Xen may enter in IRQ exception mode and return the processor with
clobbered ESR_EL2 (See ARM ARM DDI 0487A.j D7.2.25)
In this case the guest exception syndrome has been overridden, we will
check the syndrome for guest sync exception with an incorrect ESR_EL2
value. So we want to save ESR_EL2 to cpu_user_regs as soon as the
exception takes place in EL2 to avoid using an incorrect syndrome value.
In order to save ESR_EL2, we added a 32-bit member hsr to cpu_user_regs.
But while saving registers in trap entry, we use stp to save ELR and
CPSR at the same time through 64-bit general registers. If we keep this
code, the hsr will be overridden by upper 32-bit of CPSR. So adjust the
code to use str to save ELR in a separate instruction and use stp to
save CPSR and HSR at the same time through 32-bit general registers.
This change affects the registers restore in trap exit, we can't use the
ldp to restore ELR and CPSR from stack at the same time. We have to use
ldr to restore them separately.
Signed-off-by: Wei Chen <Wei.Chen@arm.com>
Reviewed-by: Julien Grall <julien.grall@arm.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
* 'staging' of git://xenbits.xen.org/people/konradwilk/xen:
Introduce the pvcalls header
Introduce the Xen 9pfs transport header
xen: introduce a C99 headers check
ring.h: introduce macros to handle monodirectional rings with multiple req sizes
tmem: Parse UUIDs correctly.
tmem: Fix tmem-shared-auth 'auth' values
tmem: By default to join an shared pool it must be authorized.
xen/libxc: Move TMEM_AUTH to XEN_SYSCTL_TMEM_OP_SET_AUTH
xen/libcx/tmem: Replace TMEM_RESTORE_NEW with XEN_SYSCTL_TMEM_OP_SET_POOLS
displif: add ABI for para-virtual display
GCC7 complains about a possible overflow/truncation in xenlockprof.
xenlockprof.c: In function ‘main’:
xenlockprof.c:100:53: error: ‘%s’ directive writing up to 39 bytes into a
region of size between 17 and 37 [-Werror=format-overflow=]
sprintf(name, "unknown type(%d) %d lock %s", data[j].type,
^~
xenlockprof.c:100:13: note: ‘sprintf’ output between 24 and 83 bytes
into a destination of size 60
sprintf(name, "unknown type(%d) %d lock %s", data[j].type,
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
data[j].idx, data[j].name);
~~~~~~~~~~~~~~~~~~~~~~~~~~
This increases the size of name to 100. Not the most scalable solution,
but certainly the "cheapest", as it doesn't add dependencies for
asprintf.
Signed-off-by: Seraphime Kirkovski <kirkseraph@gmail.com>
Acked-by: Wei Liu <wei.liu2@citrix.com>
The base address, id and number of pins of the vIO APICs exposed to PVHv2 Dom0
is the same as the values found on bare metal.
Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Add support for multiple vIO APICs on the same domain, thus turning
d->arch.hvm_domain.vioapic into an array of vIO APIC control structures.
Note that this functionality is not exposed to unprivileged guests, and will
only be used by PVHv2 Dom0.
Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
We shouldn't hand MFN info back from increase-reservation for
translated domains, just like we don't for populate-physmap and
memory-exchange. For full symmetry also check for a NULL guest handle
in populate_physmap() (but note this makes no sense in
memory_exchange(), as there the array is also an input).
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
Released-acked-by: Julien Grall <julien.grall@arm.com>
There's no point in continuing if in the end we'll return -EFAULT
anyway. It also seems wrong to report a chunk for which at least one
write-back failed as successfully exchanged (albeit the indication of
an error is also not fully correct, as the exchange happened in that
case at least partially - retrieving the GFN to assign the memory to
and/or handing back the information on the replacement memory didn't
work). In any case limiting the amount of damage done to the guest
can't be all that bad an idea.
Reported-by: Jann Horn <jannh@google.com>
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
Released-acked-by: Julien Grall <julien.grall@arm.com>
Define the ring and request and response structs according to the
specification. Use the new DEFINE_XEN_FLEX_RING macro.
Add the header to the C99 check.
Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Signed-off-by: Stefano Stabellini <stefano@aporeto.com>
CC: JBeulich@suse.com
Define the ring according to the protocol specification, using the new
DEFINE_XEN_FLEX_RING_AND_INTF macro.
Add the header to the C99 check.
Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Signed-off-by: Stefano Stabellini <stefano@aporeto.com>
CC: JBeulich@suse.com
Introduce a C99 headers check, for non-ANSI compliant headers: 9pfs.h
and pvcalls.h.
In addition to the usual -include stdint.h, also add -include string.h
to the C99 check to get the declaration of memcpy and size_t.
For the same reason, also add -include cstring to the C++ check when
necessary.
Signed-off-by: Stefano Stabellini <stefano@aporeto.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
CC: JBeulich@suse.com
This patch introduces macros, structs and functions to handle rings in
the format described by docs/misc/pvcalls.markdown and
docs/misc/9pfs.markdown. The index page (struct __name##_data_intf)
contains the indexes and the grant refs to setup two rings.
Indexes page
+----------------------+
|@0 $NAME_data_intf: |
|@76: ring_order = 1 |
|@80: ref[0]+ |
|@84: ref[1]+ |
| | |
| | |
+----------------------+
|
v (data ring)
+-------+-----------+
| @0->4095: in |
| ref[0] |
|-------------------|
| @4096->8191: out |
| ref[1] |
+-------------------+
$NAME_read_packet and $NAME_write_packet are provided to read or write
any data struct from/to the ring. In pvcalls, they are unused. In xen
9pfs, they are used to read or write the 9pfs header. In other protocols
they could be used to read/write the whole request structure. See
docs/misc/9pfs.markdown:Ring Usage to learn how to check how much data
is on the ring, and how to handle notifications.
There is a ring_size parameter to most functions so that protocols using
these macros don't have to have a statically defined ring order at build
time. In pvcalls for example, each new ring could have a different
order.
These macros don't help you share the indexes page or the event channels
needed for notifications. You can do that with other out of band
mechanisms, such as xenstore or another ring.
It is not possible to use a macro to define another macro with a
variable name. For this reason, this patch introduces static inline
functions instead, that are not C89 compliant. Additionally, the macro
defines a struct with a variable sized array, which is also not C89
compliant.
Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Signed-off-by: Stefano Stabellini <stefano@aporeto.com>
CC: JBeulich@suse.com
A simple
xl tmem-shared-auth -u 00000000-0000-000A-0000-000000000001 -A 0 0
resulted in uuid_low = 1 (correct) and uuid_high = 0 (umm?).
The issue was that for hex values above 'A' (or 'a') we forgot
to add 10.
Acked-by: Wei Liu <wei.liu2@citrix.com>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
The hypervisor code (tmemc_shared_pool_auth) since the inception
would consider auth values of:
0 - to disable authentication!
1 - to enable authentication for the given UUID.
The docs have it the other way around, so lets fix it.
Acked-by: Wei Liu <wei.liu2@citrix.com>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Having an off by default option allowing guests to join
_any_ shared pool is not very secure.
Lets eliminate tmem_shared_auth bootup option (which
was disabled by default) and have the code force this by default.
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
which surprisingly (or maybe not) looks like
XEN_SYSCTL_TMEM_OP_SET_POOLS.
This hypercall came about, as explained in docs/misc/tmem-internals.html:
When tmem was first proposed to the linux kernel mailing list
(LKML), there was concern expressed about security of shared ephemeral
pools. The initial tmem implementation only
required a client to provide a 128-bit UUID to identify a shared pool, and the
linux-side tmem implementation obtained this UUID from the superblock of the
shared filesystem (in ocfs2). It was
pointed out on LKML that the UUID was essentially a security key and any
malicious domain that guessed it would have access to any data from the shared
filesystem that found its way into tmem.
..
As a result, a Xen boot option -- tmem_shared_auth; -- was
added. The option defaults to disabled,
but when it is enabled, management tools must explicitly authenticate (or may
explicitly deny) shared pool access to any client.
On Xen, this is done with the xm tmem-shared-auth command.
"
However the implementation has some rather large holes:
a) The hypercall was accessed from any guest.
b) If the ->domain id value is 0xFFFF then one can toggle the
tmem_global.shared_auth knob on/off. That with a)
made it pretty bad.
c) If one toggles the tmem_global.shared_auth off, then the
'tmem_shared_auth=1' bootup parameter is ignored and
one can join any shared pool (if UUID is known)!
d) If the 'tmem_shared_auth=1' and tmem_global.shared_auth is
set to 1, then one can only join an shared pool if the
UUID has been set by 'xl tmem-shared-auth'. Otherwise
the joining of a pool fails and a non-shared pool is
created (without errors to guest). Not exactly sure if
the shared pool creation at that point should error out
or not.
e) If a guest is migrated, the policy values (which UUID
can be shared, whether tmem_global.shared_auth is set, etc)
are completely ignored.
This patch only fixes a) and only allows the hypercall to
be called by the control domain. Subsequent patches will
fix the remaining issues.
We also have to call client_create as the guest at this
point may not have done any tmem hypercalls - and hence
the '->tmem' from 'struct domain' is still NULL. Us calling
client_create fixes this.
Acked-by: Wei Liu <wei.liu2@citrix.com> [libxc changes]
Reviewed-by: Jan Beulich <jbeulich@suse.com> [hypervisor changes]
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
This used to be done under TMEM_RESTORE_NEW which was an hypercall
accessible by the guest. However there are couple of reasons
not to do it:
- No checking of domid on TMEM_RESTORE_NEW which meant that
any guest could create TMEM pools for other guests.
- The guest can already create pools using TMEM_NEW_POOL
(which is limited to guest doing the hypercall)
- This functionality is only needed during migration - there
is no need for the guest to have this functionality.
However to move this we also have to allocate the 'struct domain'
->tmem pointer. It is by default set to NULL and would be initialized
via the guest do_tmem() hypercalls. Presumarily that was the
initial reason that TMEM_RESTORE_NEW was in the guest accessible
hypercalls.
Acked-by: Wei Liu <wei.liu2@citrix.com> [libxc change]
Reviewed-by: Jan Beulich <jbeulich@suse.com> [hypervisor changes]
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
This is the ABI for the two halves of a para-virtualized
display driver.
This protocol aims to provide a unified protocol which fits more
sophisticated use-cases than a framebuffer device can handle. At the
moment basic functionality is supported with the intention to extend:
o multiple dynamically allocated/destroyed framebuffers
o buffers of arbitrary sizes
o better configuration options including multiple display support
Note: existing fbif can be used together with displif running at the
same time, e.g. on Linux one provides framebuffer and another DRM/KMS
Future extensions to the existing protocol may include:
o allow display/connector cloning
o allow allocating objects other than display buffers
o add planes/overlays support
o support scaling
o support rotation
Note, that this protocol doesn't use ring macros for
bi-directional exchange (PV calls/9pfs) bacause:
o it statically defines the use of a single page
for the ring buffer
o it uses direct memory access to ring's contents
w/o memory copying
o re-uses the same idea that kbdif/fbif use
which for this use-case seems to be appropriate
==================================================
Rationale for introducing this protocol instead of
using the existing fbif:
==================================================
1. In/out event sizes
o fbif - 40 octets
o displif - 40 octets
This is only the initial version of the displif protocol
which means that there could be requests which will not fit
(WRT introducing some GPU related functionality
later on). In that case we cannot alter fbif sizes as we need to
be backward compatible an will be forced to handle those
apart of fbif.
2. Shared page
Displif doesn't use anything like struct xenfb_page, but
DEFINE_RING_TYPES(xen_displif, struct xendispl_req, struct
xendispl_resp) which is a better and more common way.
Output events use a shared page which only has in_cons and in_prod
and all the rest is used for incoming events. Here struct xenfb_page
could probably be used as is despite the fact that it only has a half
of a page for incoming events which is only 50 events. (consider
something like 60Hz display)
3. Amount of changes.
fbif only provides XENFB_TYPE_UPDATE and XENFB_TYPE_RESIZE
events, so it looks like it is easier to get fb support into displif
than vice versa. displif at the moment has 6 requests and 1 event,
multiple connector support, etc.
Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Signed-off-by: Oleksandr Grytsov <oleksandr_grytsov@epam.com>
Signed-off-by: Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com>
Add ABI for the two halves of a para-virtualized
sound driver to communicate with each other.
The ABI allows implementing audio playback and capture as
well as volume control and possibility to mute/unmute
audio sources.
Note: depending on the use-case backend can expose more sound
cards and PCM devices/streams than the underlying HW physically
has by employing SW mixers, configuring virtual sound streams,
channels etc. Thus, allowing fine tunned configurations per
frontend.
Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Signed-off-by: Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com>
Signed-off-by: Oleksandr Grytsov <oleksandr_grytsov@epam.com>
Signed-off-by: Oleksandr Dmytryshyn <oleksandr.dmytryshyn@globallogic.com>
Signed-off-by: Iurii Konovalenko <iurii.konovalenko@globallogic.com>
Currently in xc_interface_open, xch->fmem is not initialized
and in some rare case the code fails before ever assigning a value
to it.
I got this in master:
$ sudo ./xl/xl run
xencall: error: Could not obtain handle on privileged command interface: No such file or directory
Segmentation fault
This initializes the whole xch_buff to 0.
Signed-off-by: Seraphime Kirkovski <kirkseraph@gmail.com>
Acked-by: Wei Liu <wei.liu2@citrix.com>
The use of guest_handle_okay() here (as introduced by the XSA-29 fix)
is insufficient here, guest_handle_subrange_okay() needs to be used
instead.
Note that the uses are okay in
- XENMEM_add_to_physmap_batch handling due to the size field being only
16 bits wide,
- livepatch_list() due to the limit of 1024 enforced on the
number-of-entries input (leaving aside the fact that this can be
called by a privileged domain only anyway),
- compat mode handling due to counts there being limited to 32 bits,
- everywhere else due to guest arrays being accessed sequentially from
index zero.
This is CVE-2017-7228 / XSA-212.
Reported-by: Jann Horn <jannh@google.com>
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
Although it's still always set to VIOAPIC_NUM_PINS (48).
Add a new field to the hvm_ioapic struct to contain the number of pins (number
of IO redirection table entries) and turn the redirection table into a variable
sized array.
Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Rearrange the fields of hvm_irq so that gsi_assert_count can be converted into
a variable size array and add a new field to account the number of GSIs.
Due to this changes the irq member in the hvm_domain struct also needs to
become a pointer set at runtime.
Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Rename it to NR_HVM_DOMU_IRQS, and get it's value from the size of the DomU vIO
APIC redirection table.
Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
When kexec_do_unload calls kexec_swap_images to get the old kexec_image to
free, it passes NULL for the new kexec_image pointer. The new slot wasn't being
cleared in such a case, leading to a stale pointer being left behind in the
kexec_image array and Xen panics in subsequent load/unload operations.
Signed-off-by: Bhavesh Davda <bhavesh.davda@oracle.com>
Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
So that the function can be called from other files without adding prototypes
to each of them.
Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
Introduce a macro to get a pointer to the hvm_irq for a HVM domain. No
functional change.
Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
Reviewed-by: Kevin Tian <kevin.tian@intel.com> [VT-d]
Acked-by: Jan Beulich <jbeulich@suse.com>
This is required in order to have a variable number of vIO APIC pins, instead
of the current fixed value (48). Note that this patch only expands the fields
of the hvm_vioapic struct, without actually introducing any new fields or
functionality.
The reason to expand the hvm_vioapic structure instead of the hvm_hw_vioapic
one is that the variable number of pins functionality is only going to be used
by the hardware domain, so no modifications are needed to the save format.
Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
parse_vwfi runs after init_traps on cpu0, potentially resulting in the
wrong HCR_EL2 for it. Secondary cpus boot after parse_vwfi, so in their
case init_traps will write the correct set of flags to HCR_EL2.
For cpu0, fix the issue by changing HCR_EL2 setting from a new
presmp_initcall.
Signed-off-by: Stefano Stabellini <sstabellini@kernel.org>
Reviewed-by: Julien Grall <julien.grall@arm.com>
When booting using ACPI, not all MMIOs can be discovered by parsing the
static tables or the UEFI memory map. A lot of them will be described in
the DSDT. However, Xen does not have an AML parser which requires us to
find a different approach.
During the first discussions on supporting ACPI (see design doc [1]), it
was decided to rely on the hardware domain to make a request to the
hypervisor to map the MMIO region in stage-2 page table before accessing
it. This approach works fine if the OS has limited hooks to modify the
page tables.
In the case of Linux kernel, notifiers have been added to map
the MMIO regions when adding a new AMBA/platform device. Whilst this is
covering most of the MMIOs, some of them (e.g OpRegion, ECAM...) are not
related to a specific device or the driver is not using the
AMBA/platform API. So more hooks would need to be added in the code.
Various approaches have been discussed (see [2]), one of them was to
create stage-2 mappings seamlessly in Xen upon hardware memory faults.
This approach was first ruled out because it relies on the hardware
domain to probe the region before any use. So this would not work when
DMA'ing to another device's MMIO region when the device is protected by
an SMMU. It has been pointed out that this is a limited use case compare
to DMA'ing between MMIO and RAM.
This patch implements this approach. All MMIOs region will be mapped in
stage-2 using p2m_mmio_direct_c (i.e normal memory outer and inner
write-back cacheable). The stage-1 page table will be in control of the
memory attribute. This is fine because the hardware domain is a trusted
domain.
Note that MMIO will only be mapped on a data abort fault. It is assumed
that it will not be possible to execute code from MMIO
(p2m_mmio_direct_c will forbid that).
As mentioned above, this solution will cover most of the cases. If a
platform requires to do DMA'ing to another device's MMIO region without
any access performed by the OS. Then it will be expected to have
specific platform code in the hypervisor to map the MMIO at boot time or
the OS to use the existing hypercalls (i.e XENMEM_add_to_add_physmap{,_batch})
before any access.
[1] https://lists.xen.org/archives/html/xen-devel/2015-11/msg00488.html
[2] https://marc.info/?l=linux-arm-kernel&m=148469169210500&w=2
Signed-off-by: Julien Grall <julien.grall@arm.com>
Tested-by: Shanker Donthineni <shankerd@codeaurora.org>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
If ocaml.m4 didn't find ocamlopt, disable all the ocaml builds.
Currently our Makefiles do not work properly when the native code
compiler (`ocamlopt') is not available. In principle this should be
fixed to fall back to bytecode, but this is not a task for this stage
of the Xen 4.9 release.
Without this change, we cannot build on systems with only ocamlc.
That includes Debian jessie ARM64, as used on the new ARM64 hardware
in the Xen Project CI test lab.
When the Makefiles are fixed, this commit should be reverted.
Committers: Please rerun autogen.sh.
CC: Julien Grall <julien.grall@arm.com>
CC: Christian Lindig <christian.lindig@citrix.com>
CC: Jonathan Ludlam <Jonathan.Ludlam@citrix.com>
CC: David Scott <dave@recoil.org>
CC: Wei Liu <wei.liu2@citrix.com>
Tested-by: Ian Jackson <Ian.Jackson@eu.citrix.com>
Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com>
Acked-by: Wei Liu <wei.liu2@citrix.com>
Remove all unused functions from tdb.c. This will reduce code size of
xenstored and - more important - of xenstore stubdom.
tdb.c hasn't been updated to a newer version since its introduction in
2005. Any backport of bug fixes or update to a new version will need
major work, so there is no real downside to remove not needed code.
Signed-off-by: Juergen Gross <jgross@suse.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Wei Liu <wei.liu2@citrix.com>
The handling of transactions in xenstored is rather clumsy today:
- Each transaction in progress is keeping a local copy of the complete
xenstore data base
- A transaction will fail as soon as any node is being modified outside
the transaction
This is leading to a very bad behavior in case of a large xenstore.
Memory consumption of xenstored is much higher than necessary and with
many domains up transactions failures will be more and more common.
Instead of keeping a complete copy of the data base for each
transaction store the transaction data in the same data base as the
normal xenstore entries prepended with the transaction in the single
nodes either read or modified. At the end of the transaction walk
through all nodes accessed and check for conflicting modifications.
In case no conflicts are found write all modified nodes to the data
base without transaction identifier.
Following tests have been performed:
- create/destroy of various domains, including HVM with ioemu-stubdom
(xenstored and xenstore-stubdom)
- multiple concurrent runs of xs-test over several minutes
(xenstored and xenstore-stubdom)
- test for memory leaks of xenstored by dumping talloc reports before
and after the tests
Signed-off-by: Juergen Gross <jgross@suse.com>
Reviewed-by: Wei Liu <wei.liu2@citrix.com>
Instead of setting errno and returning true or false return the error
value directly.
In order to ensure all call sites have been changed according to the
modification rename the functions to xs_*.
Signed-off-by: Juergen Gross <jgross@suse.com>
Reviewed-by: Wei Liu <wei.liu2@citrix.com>
This patch is based on the implementation of ARM64, it introduces
alternative runtime patching to ARM32. This allows to patch assembly
instruction at runtime to either fix hardware bugs or optimize for
certain hardware features on ARM32 platform.
Xen hypervisor is using ARM execution state only on ARM32 platform,
Thumb is not used. So, the Thumb only branch instructions (CBZ, CBNZ,
TBB and TBH) are not considered in alternatives.
The left ARM32 branch instructions are BX, BLX, BL and B. The
instruction BX is taking a register in parameter, so we don't need to
rewrite it. The instructions BLX, BL and B are using the similar
encoding for the offset and will avoid specific case when extracting
and updating the offset.
In this patch, we include alternative.h header file to livepatch.c
directly for ARM32 compilation issues. When the alternative patching
config is enabled, the livepatch.c will use the alternative functions.
In this case, we should include the alternative header file to this
file. But for ARM64, it does not include this header file directly.
It includes this header file indirectly through:
sched.h->domain.h->page.h->alternative.h.
But, unfortunately, the page.h of ARM32 doesn't include alternative.h,
and we don't have the reason to include it to ARM32 page.h now. So we
have to include the alternative.h directly in livepatch.c.
Signed-off-by: Wei Chen <Wei.Chen@arm.com>
Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Reviewed-by: Julien Grall <julien.grall@arm.com>
MEM_LOG() is just a thin wrapper around gdprintk(), obscuring some of the
common information. Inline it, and take the opportunity to correct some of
the printked information.
Some corrections, each where appropriate:
* Correction of pfn/mfn terms and consistent use of PRI_pfn/mfn
* s!I/O!MMIO!
* Consistently represent domains using d%d notation
* Use 0x prefix for otherwise unqualified hex numbers
* Remove "ptwr_emulate:" prefix, as the embedded __func__ is already clear
* Provide more useful slot information
* Delete some not-very-helpful lines entirely
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Wei Liu <wei.liu2@citrix.com>
Release-acked-by: Julien Grall <julien.grall@arm.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
ACPICA commit 9f7c3e148f440049615e2791d73b292f65692d7e
The most recent version of the IORT specification adds in a definition
for a subtable to describe SMMUv3 devices; there is already a subtable
for SMMUv1/v2 devices.
Add in the definition of the subtable, add in the code to compile it,
and add in a template for it.
Link: https://github.com/acpica/acpica/commit/9f7c3e14
Signed-off-by: Al Stone <ahs3@redhat.com>
Signed-off-by: Bob Moore <robert.moore@intel.com>
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
[Linux commit 4ac78baf88d85c49883fcc87d31198ebe408e54d]
Signed-off-by: Sameer Goel <sgoel@codeaurora.org>
Acked-by: Jan Beulich <jbeulich@suse.com>
ACPICA commit 5de82757aef5d6163e37064033aacbce193abbca
This patch adds support for IORT (IO Remapping Table) in iasl.
Note that some field names are modified to shrink their length or the
decompiled IORT ASL will contain fields with ugly ":" alignment.
The IORT contains field definitions around "Memory Access Properties". This
patch also adds support to encode/decode it using inline table.
This patch doesn't add inline table support for the SMMU interrupt fields
due to a limitation in current ACPICA data table support. Lv Zheng.
Link: https://github.com/acpica/acpica/commit/5de82757
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
Signed-off-by: Bob Moore <robert.moore@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
[Linux commit 874f6a723e56d0da9e481629b17482bcd3801ecf]
Signed-off-by: Sameer Goel <sgoel@codeaurora.org>
Acked-by: Jan Beulich <jbeulich@suse.com>
Wei Chen
Konrad Rzeszutek Wilk
Seraphime Kirkovski
Roger Pau Monné
Jan Beulich
Juergen Gross
Stefano Stabellini
Oleksandr Andrushchenko
Bhavesh Davda
Julien Grall
Ian Jackson
Andrew Cooper
Al Stone
Lv Zheng