Right now, this is broken because libxl__build_device_model_args_new
is used also for the qemu run for pv guests for qdisk devices, pvfb,
etc.
We can either make this option properly HVM-specific, or make it
generic.
In principle it is a reasonable request, to make the PV qemu
deprivileged (even though it is not likely to be implemented any time
soon). So make this option generic.
We retain the name "device model" even though it is arguably
inaccurate, because the xl docs already say, for example
For a PV guest a device-model is sometimes used to provide backends
for certain PV devices
The documentation patch here is pure code motion. For ease of review
we will fix up the docs, so the wording to be right for the new
context, in the next patch.
Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com>
Reported-by: Roger Pau Monné <roger.pau@citrix.com>
Acked-by: Wei Liu <wei.liu2@citrix.com>
---
v2: Change xl too, to avoid breaking the build.
Fix manpage pod syntax.
Move fuzz-emul.c function prototypes into a header. Also share the
definition of the input size (rather than hard-coding it in
fuzz-emul.c).
Signed-off-by: George Dunlap <george.dunlap@citrix.com>
Finding aggregate coverage for a set of test files means running each
afl-generated test case through the harness. At the moment, this is
done by re-executing afl-harness-cov with each input file. When a
large number of test cases have been generated, this can take a
significant amonut of time; a recent test with 30k total files
generated by 4 parallel fuzzers took over 7 minutes.
The vast majority of this time is taken up with 'exec', however.
Since the harness is already designed to loop over multiple inputs for
llvm "persistent mode", just allow it to take a large number of inputs
on the same when *not* running in llvm "persistent mode".. Then the
command can be efficiently executed like this:
ls */queue/id* | xargs $path/afl-harness-cov
For the above-mentioned test on 30k files, the time to generate
coverage data was reduced from 7 minutes to under 30 seconds.
Signed-off-by: George Dunlap <george.dunlap@citrix.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
...to generate a "normal" coverage-instrumented binary, suitable for
use with gcov or afl-cov.
This is slightly annoying because:
- Every object file needs to have been instrumented to work
effectively
- You generally want to have both an afl-instrumented binary and a
gcov-instrumented binary at the same time, but
- gcov instrumentation and afl instrumentation are mutually exclusive
So when making the `afl-cov` target, generate a second set of object
files and a second binary with the `-cov` suffix.
While we're here, remove the redundant x86-emulate.c dependency for
x86-emulate.o.
Signed-off-by: George Dunlap <george.dunlap@citrix.com>
Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
When generating coverage output, by default gcov generates output
filenames based only on the coverage file and the "leaf" source file,
not the full path. As a result, it uses the same name for
x86_emulate.c and x86_emulate/x86_emulate.c, generally overwriting the
second (which we actually are about) with the first (which is just a
wrapper).
Rename the user-space wrapper helpers to x86-emulate.[ch], so
that it generates separate files.
There is actually an option to gcov, `--preserve-paths`, which will
cause the full path name to be included in the filename, properly
distinguishing between the two. However, given that the user-space
wrapper doesn't actually do any emulation (and the poor state of gcov
documentation making it difficult to find the option in the first
place), it seems to make more sense to rename the file anyway.
Signed-off-by: George Dunlap <george.dunlap@citrix.com>
Acked-by: Wei Liu <wei.liu2@citrix.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
- Print the symbolic name rather than the number
- Explicitly state when data_read() fails due to EOI
Signed-off-by: George Dunlap <george.dunlap@citrix.com>
Reviewed-by: Wei Liu <wei.liu2@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Commit 849a1f10c9 was checked in inappropriately; review flagged up
that clearerr() was too big a hammer, as it would clear both the EOF
flag and stream errors.
Stream errors shouldn't be cleared; we only want the EOF and other
stream-related state reset. To do this, it is sufficient to fseek()
to zero.
Signed-off-by: George Dunlap <george.dunlap@citrix.com>
Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
This feature indicates that hypervisor is compatible with ARM
SMC calling convention. Previously hypervisor would inject an
undefined instruction exception if an invalid SMC function were
called or would crash a domain if an invalid HVC function
were invoked.
XENFEAT_ARM_SMCCC_supported feature means that it safe to invoke
SMC/HVC calls that are compatible with SMC calling convention.
Signed-off-by: Volodymyr Babchuk <volodymyr_babchuk@epam.com>
Acked-by: Julien Grall <julien.grall@arm.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
PSCI handling code had helper routine that checked calling convention.
It does not needed anymore, because:
- Generic handler checks that 64 bit calls can be made only by
64 bit guests.
- SMCCC requires that 64-bit handler should support both 32 and 64 bit
calls even if they originate from 64 bit caller.
This patch removes that extra check.
Signed-off-by: Volodymyr Babchuk <volodymyr_babchuk@epam.com>
Reviewed-by: Julien Grall <julien.grall@linaro.org>
smccc.h provides definitions to construct SMC call function number according
to SMCCC. We don't need multiple definitions for one thing, and definitions
in smccc.h are more generic than ones used in psci.h.
So psci.h will only provide function codes, while whole SMC function
identifier will be constructed using generic macros from smccc.h.
Function psci_mode_check() in vsmc.c will be removed in a next patch,
so there are no need to review it. I had to rework it, because
PSCI_0_2_64BIT definition is dropped now.
Signed-off-by: Volodymyr Babchuk <volodymyr_babchuk@epam.com>
Acked-by: Julien Grall <julien.grall@arm.com>
PSCI is part of HVC/SMC interface, so it should be handled in
appropriate place: `vsmc.c`. This patch moves PSCI handler
calls from `traps.c` to `vsmc.c`. Also it corrects coding
style of the PSCI handler functions.
Older PSCI 0.1 uses SMC function identifiers in range that is
reserved for existing APIs (ARM DEN 0028B, page 16), while newer
PSCI 0.2 and later is defined as "standard secure service" with its
own ranges (ARM DEN 0028B, page 18).
Signed-off-by: Volodymyr Babchuk <volodymyr_babchuk@epam.com>
Reviewed-by: Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com>
Reviewed-by: Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>
Acked-by: Julien Grall <julien.grall@arm.com>
Acked-by: Stefano Stabellini <sstabellini@kernel.org>
SMCCC (SMC Call Convention) describes how to handle both HVCs and SMCs.
SMCCC states that both HVC and SMC are valid conduits to call to different
firmware functions. Thus, for example, PSCI calls can be made both by
SMC or HVC. Also SMCCC defines function number coding for such calls.
Besides functional calls there are query calls, which allows underling
OS determine version, UUID and number of functions provided by service
provider.
This patch adds new file `vsmc.c`, which handles both generic SMCs
and HVC according to SMCCC. At this moment it implements only one
service: Standard Hypervisor Service.
At this time Standard Hypervisor Service only supports query calls,
so caller can ask about hypervisor UID and determine that it is XEN running.
This change allows more generic handling for SMCs and HVCs and it can
be easily extended to support new services and functions.
But, before SMC is forwarded to standard SMCCC handler, it can be routed
to a domain monitor, if one is installed.
Signed-off-by: Volodymyr Babchuk <volodymyr_babchuk@epam.com>
Reviewed-by: Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com>
Reviewed-by: Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>
Acked-by: Julien Grall <julien.grall@arm.com>
Acked-by: Stefano Stabellini <sstabellini@kernel.org>
Signed-off-by: Stefano Stabellini <sstabellini@kernel.org>
Add generic definitions used in ARM SMC call convention.
Those definitions was originally added to Linux kernel as
include/linux/arm-smccc.h by commit 98dd64f34f47
("ARM: 8478/2: arm/arm64: add arm-smccc")
I extended them and formatted according to XEN coding style. Some
of the macros were converted to inlined functions to ease parsing.
They can be used by both SMCCC clients (like PSCI) and by SMCCC
servers (like vPSCI or upcoming generic SMCCC handler).
Signed-off-by: Volodymyr Babchuk <volodymyr_babchuk@epam.com>
Acked-by: Julien Grall <julien.grall@arm.com>
Acked-by: Stefano Stabellini <sstabellini@kernel.org>
This patch defines HSR_XXC_IMM_MASK. It can be used to extract
immediate value for trapped HVC32, HVC64, SMC64, SVC32, SVC64
instructions, as described in the ARM ARM
(ARM DDI 0487B.a pages D7-2270, D7-2272).
Signed-off-by: Volodymyr Babchuk <volodymyr_babchuk@epam.com>
Acked-by: Julien Grall <julien.grall@arm.com>
Added type xen_uuid_t. This type represents UUID as an array of 16
bytes in big endian format.
Added macro XEN_DEFINE_UUID that constructs UUID in the usual way:
XEN_DEFINE_UUID(0x00112233, 0x4455, 0x6677, 0x8899,
0xaa, 0xbb, 0xcc, 0xdd, 0xee, 0xff)
will construct UUID 00112233-4455-6677-8899-aabbccddeeff presented as
{0x00, 0x11, 0x22, 0x33, 0x44, 0x55, 0x66, 0x77, 0x88,
0x99, 0xaa, 0xbb, 0xcc, 0xdd, 0xee, 0xff}
NB: We define a new structure here rather than re-using EFI_GUID.
EFI_GUID uses a Microsoft-style encoding which, among other things,
mixes little-endian and big-endian. The structure defined in this
patch, unlike EFI_GUID, is compatible with the Linux kernel and libuuid.
Signed-off-by: Volodymyr Babchuk <volodymyr_babchuk@epam.com>
Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Stefano Stabellini <sstabellini@kernel.org>
Signed-off-by: Stefano Stabellini <sstabellini@kernel.org>
Trapped SMC instruction can fail condition check on ARMv8 architecture
(ARM DDI 0487B.a page D7-2271). So we need to check if condition was meet.
Signed-off-by: Volodymyr Babchuk <volodymyr_babchuk@epam.com>
Reviewed-by: Julien Grall <julien.grall@arm.com>
There are standard functions set_user_reg() and get_user_reg(). We can
use them in PSCI_SET_RESULT()/PSCI_ARG() macros instead of relying on
CONFIG_ARM_64 definition.
Signed-off-by: Volodymyr Babchuk <volodymyr_babchuk@epam.com>
Reviewed-by: Julien Grall <julien.grall@arm.com>
According to SMCCC (ARM DEN 0028B, page 12), function id is
stored in least 32 bits of r0/x0 register:
The least significant 32-bits are used, and the most significant
32-bits are zero.
Signed-off-by: Volodymyr Babchuk <volodymyr_babchuk@epam.com>
Acked-by: Julien Grall <julien.grall@arm.com>
The function get_ipa_output_size checks whether the input size
configured by the guest is valid and will return it.
The check is done with the IPS already shifted against
TCR_EL1_IPS_48_BIT. However the constant has been defined with the
shift included, as a result the check is always false.
Fix it by doing the check on the non-shifted value.
This was introduced by commit 7d623b358a "arm/mem_access: Add long-descriptor
based gpt" introduced software page-table walk for stage-1.
Note that the IPS code is now surrounded with #ifdef CONFIG_ARM_64
because the Arm32 compiler will complain of shift bigger than the width
of the variable. This is fine as the code is executed for 64-bit domain only.
Coverity-ID: 1457707
Signed-off-by: Julien Grall <julien.grall@linaro.org>
Reviewed-by: Sergej Proskurin <proskurin@sec.in.tum.de>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
Signed-off-by: Stefano Stabellini <sstabellini@kernel.org>
Commit a0543df403 "xen/arm: page: Clean-up the definition of MAIRVAL"
combined the definition of MAIR0VAL and MAIR1VAL in MAIRVAL. Sadly, when
building in 32-bit environment, the assembler is unable to compute
64-bit constant and will ignore the 32-bit most-significants bits. This
will result of MAIR1 set 0.
Rather than fully reverting the offending commit, the code is reworked
to still avoid hardcoded values but split the definition in 2.
Lastly, a comment is added to avoid trying to blindly combine the both
definition again in the future.
Signed-off-by: Julien Grall <julien.grall@linaro.org>
Reviewed-by: Andre Przywara <andre.przywara@arm.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
Several logging messages cite "bad ref %#x", without identifying which domain
the ref belongs to. Add a domain back-pointer to struct grant_table to
improve the debugability.
While editing the messages, clean up some others:
* Remove extranious punctuation
* Use d%d rather than Dom%d
* Remove "gnttab_transfer:" prefixes, as it is included by the gdprintk()
* Reflow several messages to not be split across multiple lines
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
Release-acked-by: Julien Grall <julien.grall@linaro.org>
Return 0 to indicate success rather than whatever rc was previously set
to (-EINVAL).
Signed-off-by: Ross Lagerwall <ross.lagerwall@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
The whole value array is transferred into 'do_write_psr_msrs'. Then, we can
write all features values on the cos id into MSRs.
Because multiple features may co-exist, we need handle all features to write
values of them into a COS register with new COS ID. E.g:
1. L3 CAT and L2 CAT co-exist.
2. Dom1 and Dom2 share the same COS ID (2). The L3 CAT CBM of Dom1 is 0x1ff,
the L2 CAT CBM of Dom1 is 0x1f.
3. User wants to change L2 CBM of Dom1 to be 0xf. Because COS ID 2 is
used by Dom2 too, we have to pick a new COS ID 3. The values of Dom1 on
COS ID 3 are all default values as below:
---------
| COS 3 |
---------
L3 CAT | 0x7ff |
---------
L2 CAT | 0xff |
---------
4. After setting, the L3 CAT CBM value of Dom1 should be kept and the new L2
CAT CBM is set. So, the values on COS ID 3 should be below.
---------
| COS 3 |
---------
L3 CAT | 0x1ff |
---------
L2 CAT | 0xf |
---------
Note that the original -ENOSPC return, which is being transformed into
an ASSERT(), could have been an ASSERT() from the beginning.
Signed-off-by: Yi Sun <yi.y.sun@linux.intel.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
I failed to recognize the need to mirror the changes done by 7869e2bafe
("x86emul/fuzz: add rudimentary limit checking") into the earlier
written but later committed 2fe43d333f ("x86emul: support remaining AVX
insns"): Behavior here is the same as for multi-part reads or writes.
Reported-by: Andrew Cooper <andrew.cooper3@citrix.com>
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
An access which crosses a page boundary is performed atomically by x86
hardware, albeit with a severe performance penalty. An important corner case
is when a straddled access hits two pages which differ in whether a
translation exists, or in net access rights.
The use of hvm_copy*() in hvmemul_write() is problematic, because it performs
a translation then completes the partial write, before moving onto the next
translation.
If an individual emulated write straddles two pages, the first of which is
writable, and the second of which is not, the first half of the write will
complete before #PF is raised from the second half.
This results in guest state corruption as a side effect of emulation, which
has been observed to cause windows to crash while under introspection.
Introduce the hvmemul_{,un}map_linear_addr() helpers, which translate an
entire contents of a linear access, and vmap() the underlying frames to
provide a contiguous virtual mapping for the emulator to use. This is the
same mechanism as used by the shadow emulation code.
This will catch any translation issues and abort the emulation before any
modifications occur.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Signed-off-by: Alexandru Isaila <aisaila@bitdefender.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Paul Durrant <paul.durrant@citrix.com>
Ross reports that stdvga guests do not work, and cirrus guests are
slow, because qemu tries to do xc_domain_add_to_physmap. We will need
another dmop to fix this properly.
For now, document the problem.
(In the cirrus case, the vram remains mapped at the old guest-physical
addresses, while the guest runs. We are not sure whether this is a
correctness or security problem and we should advise against it.)
Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com>
Reported-by: Ross Lagerwall <ross.lagerwall@citrix.com>
CC: Ross Lagerwall <ross.lagerwall@citrix.com>
CC: Wei Liu <wei.liu2@citrix.com>
CC: Paul Durrant <Paul.Durrant@citrix.com>
Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com>
Acked-by: Wei Liu <wei.liu2@citrix.com>
This necessitates adding $(CFLAGS_xeninclude) to all the depending
libraries (which can be done via Rules.mk), so that the definition of
domid_t (in xen.h) can be found.
Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com>
Acked-by: Wei Liu <wei.liu2@citrix.com>
We are going to want versions of getpwuid, too. And maybe in the
future getgr*.
This is most sanely achieved with a macro, as otherwise the types are
a mess.
Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com>
Acked-by: Wei Liu <wei.liu2@citrix.com>
If the config specifies a user we use that. Otherwise:
When we are not restricting qemu, there is very little point running
it as a different user than root. Indeed, previously, creating the
"magic" users would cause qemu to become slightly dysfunctional (for
example, you can't insert a cd that the qemu user can't read).
So, in that case, default to running it as root.
Conversely, if restriction is requested, we must insist on running
qemu as a non-root user.
Sadly the admin is still required to create 2^16-epsilon users!
Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com>
Acked-by: Wei Liu <wei.liu2@citrix.com>
This functionality is still quite imperfect, but it will be useful in
certain restricted use cases.
Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com>
Acked-by: Wei Liu <wei.liu2@citrix.com>
Now we can also abolish the temporary local variable "fd" and simply
use h->fd.
This ordering is necessary to be able to call
xentoolcore__register_active_handle sensibly.
Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com>
Acked-by: Wei Liu <wei.liu2@citrix.com>
Replace the ad-hoc exit clauses with the error handling style where
- local variables contain either things to be freed, or sentinels
- all error exits go via an "err" label which frees everything
Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com>
Acked-by: Wei Liu <wei.liu2@citrix.com>
Ian Jackson
George Dunlap
Volodymyr Babchuk
Julien Grall
Andrew Cooper
Ross Lagerwall
Wei Liu
Yi Sun
Jan Beulich
Boris Ostrovsky