This patch adds the headers and helpers for the FreeBSD gntdev, used in order
to map grants from remote domains and to allocate grants on behalf of the
current domain.
Current code has been tested with the QEMU/Qdisk backend.
Signed-off-by: Akshay Jaggi <akshay1994.leo@gmail.com>
[ added dummy stub for osdep_gnttab_grant_copy ]
Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
Acked-by: Wei Liu <wei.liu2@citrix.com>
Move PAGE_* back to {linux,freebsd}.c due to breakage in stubdom build.
Signed-off-by: Wei Liu <wei.liu2@citrix.com>
We can switch ACPI from using fixmap to dynamic mapping as soon as
the system enters SYS_STATE_boot. This will allow us, for example,
to map MADT on systems with large number of processors where the
table might not fit into NUM_FIXMAP_ACPI_PAGES (currently set to 4).
To avoid having a window between system entering SYS_STATE_boot and
vmap area being initialized move vm_init() a little higher.
Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
This reduces the chance of misuse - calling it must in particular
always be accompanied by calling the corresponding ->complete() hook.
Constify its parameter at once.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Paul Durrant <paul.durrant@citrix.com>
The initial operation done on these paths may raise an exception (for
->read_io() that's possible only on the PV path, when the I/O port
access check has been deferred). We have to suppress put_rep_prefix()
updating rCX in that case. From an abstract perspective this also
applies to RETRY being returned.
Reported-by: Wei Liu <wei.liu2@citrix.com>
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Wei Liu <wei.liu2@citrix.com>
Tested-by: Wei Liu <wei.liu2@citrix.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
The parameter to compat_dm_op() is a pointer to an array of
compat_dm_op_buf_t's in guest RAM.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Commit 7478ebe160 ("xen: credit2: fix shutdown/suspend
when playing with cpupools"), while doing the right thing
for actual code, forgot to update the ASSERT()s accordingly,
in csched2_vcpu_migrate().
In fact, as stated there already, during shutdown/suspend,
we must allow a Credit2 vCPU to temporarily migrate to a
non Credit2 BSP, without any ASSERT() triggering.
Move them down, after the check for whether or not we are
shutting down, where the assumption that the pCPU must be
valid Credit2 ones, is valid.
Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>
For Credit2, in both the trace records, inside Xen,
and in their parsing, in xenalyze.
In fact, as it is quite a bit better, in order to
understand how much negative credits have gone for
a certain vCPU, to see an actual negative number,
as compared to a wrapped around unsigned!
Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>
Reviewed-by: George Dunlap <george.dunlap@citrix.com>
Scheduling information debug dump for Credit2 is hard
to read as it contains the same information repeated
multiple time in different ways.
In fact, in Credit2, CPUs are grouped in runqueus. Before
this change, for each CPU, we were printing the while
content of the runqueue, as shown below:
CPU[00] sibling=000003, core=0000ff
run: [32767.0] flags=0 cpu=0 credit=-1073741824 [w=0] load=0 (~0%)
1: [0.0] flags=0 cpu=2 credit=3860932 [w=256] load=262144 (~100%)
2: [0.1] flags=0 cpu=2 credit=3859906 [w=256] load=262144 (~100%)
CPU[01] sibling=000003, core=0000ff
run: [32767.1] flags=0 cpu=1 credit=-1073741824 [w=0] load=0 (~0%)
1: [0.0] flags=0 cpu=2 credit=2859840 [w=256] load=262144 (~100%)
2: [0.3] flags=0 cpu=2 credit=-17466062 [w=256] load=262144 (~100%)
CPU[02] sibling=00000c, core=0000ff
run: [0.0] flags=2 cpu=2 credit=1858628 [w=256] load=262144 (~100%)
1: [0.3] flags=0 cpu=2 credit=-17466062 [w=256] load=262144 (~100%)
2: [0.1] flags=0 cpu=2 credit=-23957055 [w=256] load=262144 (~100%)
CPU[03] sibling=00000c, core=0000ff
run: [32767.3] flags=0 cpu=3 credit=-1073741824 [w=0] load=0 (~0%)
1: [0.1] flags=0 cpu=2 credit=-3957055 [w=256] load=262144 (~100%)
2: [0.0] flags=0 cpu=2 credit=-6216254 [w=256] load=262144 (~100%)
CPU[04] sibling=000030, core=0000ff
run: [32767.4] flags=0 cpu=4 credit=-1073741824 [w=0] load=0 (~0%)
1: [0.1] flags=0 cpu=2 credit=3782667 [w=256] load=262144 (~100%)
2: [0.3] flags=0 cpu=2 credit=-16287483 [w=256] load=262144 (~100%)
As it can be seen, all the CPUs print the whole content
of the runqueue they belong to, at the time of their
sampling, and this is cumbersome and hard to interpret!
In new output format we print, for each CPU, only the vCPU
that is running there (if that's not the idle vCPU, in which
case, nothing is printed), while the runqueues content
is printed only once, in a dedicated section.
An example:
CPUs info:
CPU[02] runq=0, sibling=00000c, core=0000ff
run: [0.3] flags=2 cpu=2 credit=8054391 [w=256] load=262144 (~100%)
CPU[14] runq=1, sibling=00c000, core=00ff00
run: [0.4] flags=2 cpu=14 credit=8771420 [w=256] load=262144 (~100%)
... ... ... ... ... ... ... ... ...
Runqueue info:
runqueue 0:
0: [0.1] flags=0 cpu=2 credit=7869771 [w=256] load=262144 (~100%)
1: [0.0] flags=0 cpu=2 credit=7709649 [w=256] load=262144 (~100%)
runqueue 1:
0: [0.5] flags=0 cpu=14 credit=-1188 [w=256] load=262144 (~100%)
Note that there still is risk of inconsistency between
what is printed in the 'Runqueue info:' and in 'CPUs info:'
sections. That is unavoidable, as the relevant locks are
released and re-acquired, around each single operation.
At least, the inconsistency is less severe than before.
Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>
Reviewed-by: George Dunlap <george.dunlap@citrix.com>
Since the hardware domain is a trusted domain, we extend the
trust to include making final decisions on what attributes to
use when mapping memory regions.
For ACPI configured hardware domains, this patch relaxes the hardware
domains mapping attributes to p2m_mmio_direct_c. This will allow the
hardware domain to control the attributes via its S1 mappings.
Signed-off-by: Edgar E. Iglesias <edgar.iglesias@xilinx.com>
Acked-by: Julien Grall <julien.grall@arm.com>
Acked-by: Stefano Stabellini <sstabellini@kernel.org>
This reverts commit 1e75ed8b64.
The default attribute mapping for MMIO as been relaxed and now rely on
the hardware domain to set the correct memory attribute
Signed-off-by: Edgar E. Iglesias <edgar.iglesias@xilinx.com>
Acked-by: Stefano Stabellini <sstabellini@kernel.org>
Since the hardware domain is a trusted domain, we extend the
trust to include making final decisions on what attributes to
use when mapping memory regions.
For device-tree configured hardware domains, this patch relaxes
the hardware domains mapping attributes to p2m_mmio_direct_c.
This will allow the hardware domain to control the attributes
via its S1 mappings.
Signed-off-by: Edgar E. Iglesias <edgar.iglesias@xilinx.com>
Reviewed-by: Julien Grall <julien.grall@arm.com>
Acked-by: Stefano Stabellini <sstabellini@kernel.org>
When the toolstack modifies memory of a running ARM VM it may happen
that the underlying memory of a current vCPU PC is changed. Without
flushing the icache the vCPU may continue executing stale instructions.
Also expose the xc_domain_cacheflush through xenctrl.h.
Signed-off-by: Tamas K Lengyel <tamas.lengyel@zentific.com>
Acked-by: Wei Liu <wei.liu2@citrix.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
This patch relocates mem_access components that are currently mixed with p2m
code into separate files. This better aligns the code with similar subsystems,
such as mem_sharing and mem_paging, which are already in separate files. There
are no code-changes introduced, the patch is mechanical code movement.
On ARM we also relocate the static inline gfn_next_boundary function to p2m.h
as it is a function the mem_access code needs access to.
Signed-off-by: Tamas K Lengyel <tamas.lengyel@zentific.com>
Acked-by: Razvan Cojocaru <rcojocaru@bitdefender.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
Acked-by: George Dunlap <george.dunlap@citrix.com>
Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
The only caller of this function is get_page_from_gva which already takes
a vcpu pointer as input. Pass this along to make the function in-line with
its intended use-case.
Signed-off-by: Tamas K Lengyel <tamas.lengyel@zentific.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
c/s 524a98c2ac "public / x86: introduce __HYPERCALL_dm_op" gave flask
permisisons for a stubdomain to use dmops, but omitted the case of a device
model running in dom0.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Wei Liu <wei.liu2@citrix.com>
Tested-by: Paul Durrant <paul.durrant@citrix.com>
register_one_rmrr() already frees its parameter if errors are encountered.
Introduced by c/s 431685e8de and spotted by Coverity.
Coverity-ID: 1399607
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
The fail3 error path skips the va_end() call, which typically leaks memory for
64bit x86 code.
Introduced by c/s 524a98c2ac, spotted by Coverity.
Coverity-ID: 1399608
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Wei Liu <wei.liu2@citrix.com>
The information given in the xl man page for the mem-max command is
rather brief. Expand it in order to let the reader understand what it
is really doing.
As the related libxl function libxl_domain_setmaxmem() isn't much
clearer add a comment to it explaining the desired semantics.
Signed-off-by: Juergen Gross <jgross@suse.com>
Acked-by: Wei Liu <wei.liu2@citrix.com>
The change in commit 438c5fe4f0 introduced a regression for domains where
mem_acces is or was active. When relinquish_p2m_mapping attempts to clear
a page where the order is not 0 the following ASSERT is triggered:
ASSERT(!p2m->mem_access_enabled || page_order == 0);
This regression was unfortunately not caught during testing in preparation
for the 4.8 release.
In this patch we adjust the ASSERT to not trip when the domain
is being shutdown.
Ideally this fix would be part of Xen 4.8.1.
Signed-off-by: Tamas K Lengyel <tamas.lengyel@zentific.com>
Acked-by: Julien Grall <julien.grall@arm.com>
In 58cbc034 send_irq permission was removed but there was still
reference to it in policy file. Remove the stale reference.
And now we also need dm permission. Add that.
Signed-off-by: Wei Liu <wei.liu2@citrix.com>
Reviewed-by: Paul Durrant <paul.durrant@citrix.com>
xsm/build: Further build fixes following the DMop series
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Now the function can return nonzero value. Use that value as exit code
for the stub program. AFL might be able to use such information to
optimise fuzzing process.
Signed-off-by: Wei Liu <wei.liu2@citrix.com>
The documentation states that a value of '1' will cause unplug of
emulated IDE disks. This is not quite correct, as QEMU will also unplug
emulated SCSI disks at the same time.
Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
Reviewed-by: Wei Liu <wei.liu2@citrix.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
Recent additions to xlat.lst have apparently resulted in Python's
garbage collection getting in the way: I would guess that so far it
managed to re-use previously compiled regular expressions, but with the
higher number of them now can't anymore (at least with default
settings). Do the compilation explicitly. While at it, combine the two
lists, and avoid using re.subn() when re.sub() suffices.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
Callers of x86_emulate() generally define addr_size based on the code
segment. In vm86 mode, the code segment is set by the hardware to be
16-bits; but it is entirely possible to enable protected mode, set the
CS to 32-bits, and then disable protected mode. (This is commonly
called "unreal mode".)
But the instruction decoder only checks for protected mode when
addr_size == 16. So in unreal mode, hardware will throw a #UD for VEX
prefixes, but our instruction decoder will decode them, triggering an
ASSERT() further on in _get_fpu(). (With debug=n the emulator will
incorrectly emulate the instruction rather than throwing a #UD, but
this is only a bug, not a crash, so it's not a security issue.)
Teach the instruction decoder to check that we're in protected mode,
even if addr_size is 32.
Signed-off-by: George Dunlap <george.dunlap@citrix.com>
Split real mode and VM86 mode handling, as VM86 mode is strictly 16-bit
at all times. Re-base.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
Operand size defaults to 32 bits in that case, but would not have been
set that way in the absence of an operand size override.
Reported-by: Wei Liu <wei.liu2@citrix.com> (by AFL fuzzing)
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
All leaves in the extd union are handled in guest_cpuid() now, so remove
legacy handling.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Leaf 0x8000001c contains LWP information. edx contains hardware supported
features (and is clamped against the maximum), while ecx and ebx contain
various properties of the implementation. eax is entirely dynamic, depending
on xcr0 and MSR_LWP_CFG.
The call to guest_cpuid() in svm_update_lwp_cfg() can now be replaced by
reading the data straight out of the cpuid_policy block.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Xen advertises the IBS feature flag to guests on capable AMD hardware.
However, the PV path in Xen, and both the PV and HVM paths in libxc
deliberately clobber the IBS CPUID leaf.
Furthermore, Xen has nothing providing an implementation of the IBS MSRs, so
guests can't actually use the feature at all.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Leaves 8000000b-18 are reserved. Leaf 80000019 is 1G TLB information and leaf
0x8000001a is performance hints. These leaves have previously been hidden
from guests, but are perfectly safe to expose when appicable.
Update libxc to also expose these leaves.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Wei Liu <wei.liu2@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Leaf 0x8000000a contains SVM information. The feature choices are borrowed
straight from the libxc policy code.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
The entirety of edx is reserved.
Intel only defines the lower 16 bits of eax, although ebx is covered by the
featureset ABI, so left unclobbered.
AMD uses 24 bits in eax, although nothing thus far has ever exposed a non-zero
guest maxphysaddr to HVM guests. Its semantics are not clearly expressed, so
it is explicitly clobbered. ecx contains some reserved bits, and several
pieces of static topology information, which are left as the toolstack
chooses.
A side effect of the common recalculation of maxlinaddr is that 32bit PV
guests see a maximum linear address of 32, which is consistent with the hiding
of other long mode information from them.
Finally, the call to guest_cpuid() in mtrr_var_range_msr_set() (introduced in
c/s fff8160a) can be dropped, now that maxphysaddr can be read straight out of
the cpuid_policy block.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Leaf 0x80000005 contains L1 cache/TLB information, 0x80000006 L2 & L3
cache/TLB information, and 0x80000007 Power management information.
Intel reserves all of this information other than the L2 cache information,
and the ITSC bit from the power management leaf.
AMD passes all of the cache/TLB information through to the guest, while most
of of the power management information is explicitly clobbered by the
toolstack.
0x80000007 edx (containing ITSC) is covered by the featureset logic.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Leaves 0x80000002 through 0x80000004 are plain ASCII text, and are left
exactly as the toolstack chooses.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Doug Goldstein <cardoe@cardoe.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Intel reserve eax and ebx, while AMD duplicates eax from the low
family/model/stepping leaf. For AMD, ebx contains further brand/package
information which is left as the toolstack chooses (other than bits 27:16
which are reserved).
While moving the dynamic adjustments from the legacy path, simplify the shadow
PSE36 adjustment. PAE paging is a prerequisite for enabling long mode, making
the long mode check redundant; the case where it doesn't get short circuited
is the case where it is architecturally 0. Make the same adjustment to the
leaf 1 legacy path.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Intel now document leaf 2 as a plain leaf, with %al always containing the
value 0x01. Collect this leaf normally in calculate_raw_policy() and expose
it to guests. The leaf is reserved by AMD.
Intel leaves 3 and 9 (PSN and DCA respectively) are not exposed to guests at
all. They are reserved by AMD.
Leaves 8 and 0xc are reserved by both vendors.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
With accurate vendor information available, the shared bits can be sorted out
during recalculation, rather than at query time in the legacy cpuid path.
This means that:
* Duplication can be dropped from the automatically generated cpuid data.
* The toolstack need not worry about setting them appropriately.
* They can be dropped from the system maximum featuresets.
While editing gen-cpuid.py, reflow some comments which exceeded the expected
line length.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Doug Goldstein <cardoe@cardoe.com>
Acked-by: Wei Liu <wei.liu2@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
The calculations for p->extd.max_leaf are reworked to force a value of at
least 0x80000000, and to take the domains chosen vendor into account when
clamping maximum value.
The high short vendor information is clobbered or duplicated according to the
chosen vendor.
As a side effect of handing out an audited max_leaf value, the 0x8000001e case
can be dropped from pv_cpuid(), as it outside of the visible range.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Doug Goldstein <cardoe@cardoe.com>
Reviewed-by: Jan Beulich <JBeulich@suse.com>
Self-snoop describes a property of the CPU cache behaviour, which FreeBSD uses
to optimise its cache flushing algorithm.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Tested-by: Roger Pau Monné <roger.pau@citrix.com>
This is a basic program to call into the unified fuzzing function.
Hook it up into build system so that we can always build test it.
Signed-off-by: Wei Liu <wei.liu2@citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
The patch introduces a new performance counter that counts how many times we go
through the load balancing logic in Credit2.
Signed-off-by: Praveen Kumar <kpraveen.lkml@gmail.com>
Acked-by: Dario Faggioli <dario.faggioli@citrix.com>
Since injection works on a remote vCPU, and since there's no
enforcement of the subject vCPU being paused, there's a potential race
between the producing and consuming sides. Fix this by leveraging the
vector field as synchronization variable.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
[re-based]
Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
NOTE: This patch also modifies the types of the 'vector', 'type' and
'insn_len' arguments of xc_hvm_inject_trap() from uint32_t to
uint8_t. In practice the values passed were always truncated to
8 bits.
Suggested-by: Jan Beulich <jbeulich@suse.com>
Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Wei Liu <wei.liu2@citrix.com>
Acked-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
Roger Pau Monne
Boris Ostrovsky
Jan Beulich
Andrew Cooper
Dario Faggioli
Wei Liu
Edgar E. Iglesias
Tamas K Lengyel
Juergen Gross
Paul Durrant
Paul Lai
George Dunlap
Praveen Kumar