xen/arm: Add handling of extended regions for Dom0
The extended region (safe range) is a region of guest physical
address space which is unused and could be safely used to create
grant/foreign mappings instead of wasting real RAM pages from
the domain memory for establishing these mappings.
The extended regions are chosen at the domain creation time and
advertised to it via "reg" property under hypervisor node in
the guest device-tree. As region 0 is reserved for grant table
space (always present), the indexes for extended regions are 1...N.
If extended regions could not be allocated for some reason,
Xen doesn't fail and behaves as usual, so only inserts region 0.
Please note the following limitations:
- The extended region feature is only supported for 64-bit domain
currently.
- The ACPI case is not covered.
***
As Dom0 is direct mapped domain on Arm (e.g. MFN == GFN)
the algorithm to choose extended regions for it is different
in comparison with the algorithm for non-direct mapped DomU.
What is more, that extended regions should be chosen differently
whether IOMMU is enabled or not.
Provide RAM not assigned to Dom0 if IOMMU is disabled or memory
holes found in host device-tree if otherwise. Make sure that
extended regions are 2MB-aligned and located within maximum possible
addressable physical memory range. The minimum size of extended
region is 64MB. The maximum number of extended regions is 128,
which is an artificial limit to minimize code changes (we reuse
struct meminfo to describe extended regions, so there are an array
field for 128 elements).
It worth mentioning that unallocated memory solution (when the IOMMU
is disabled) will work safely until Dom0 is able to allocate memory
outside of the original range.
Also introduce command line option to be able to globally enable or
disable support for extended regions for Dom0 (enabled by default).
Introduce the xen,uefi-cfg-load DT property of /chosen
node for ARM whose presence decide whether to force
the load of the UEFI Xen configuration file.
The logic is that if any multiboot,module is found in
the DT, then the xen,uefi-cfg-load property is used to see
if the UEFI Xen configuration file is needed.
Modify a comment in efi_arch_use_config_file, removing
the part that states "dom0 required" because it's not
true anymore with this commit.
Juergen Gross [Fri, 1 Oct 2021 13:11:03 +0000 (15:11 +0200)]
include/public: add possible status values to usbif.h
The interface definition of PV USB devices is lacking the specification
of possible values of the status field in a response. Those are
negative errno values as used in Linux, so they might differ in other
OS's. Specify them via appropriate defines.
Anthony PERARD [Thu, 30 Sep 2021 16:17:19 +0000 (17:17 +0100)]
automation: switch GitLab x86 smoke test to use PV 64bit binary
Xen is now built without CONFIG_PV32 by default and thus test jobs
"qemu-smoke-x86-64-gcc" and "qemu-smoke-x86-64-clang" fails because
they are using XTF's "test-pv32pae-example" which is an hello word
32bit PV guest.
As we are looking for whether Xen boot or not with a quick smoke test,
just use 64bit tests instead.
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com> Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
Import the Linux helper of_get_pci_domain_nr. This function will try to
obtain the host bridge domain number by finding a property called
"linux,pci-domain" of the given device node.
Import the Linux helper of_property_read_variable_u32_array. This
function find and read an array of 32 bit integers from a property,
with bounds on the minimum and maximum array size.
xen/pci: Refactor MSI code that implements MSI functionality within XEN
On Arm, the initial plan is to only support GICv3 ITS which doesn't
require us to manage the MSIs because the HW will protect against
spoofing. Move the code under CONFIG_HAS_PCI_MSI flag to gate the code
for ARM.
No functional change intended.
Signed-off-by: Rahul Singh <rahul.singh@arm.com> Reviewed-by: Daniel P. Smith <dpsmith@apertussolutions.com> Reviewed-by: Bertrand Marquis <bertrand.marquis@arm.com> Reviewed-by: Stefano Stabellini <sstabellini@kernel.org> Acked-by: Jan Beulich <jbeulich@suse.com>
Anthony PERARD [Thu, 9 Sep 2021 14:33:06 +0000 (15:33 +0100)]
build: add --full to version.sh to guess $(XEN_FULLVERSION)
Running $(MAKE) like that in a $(shell ) while parsing the Makefile
doesn't work reliably. In some case, make will complain with
"jobserver unavailable: using -j1. Add '+' to parent make rule.".
Also, it isn't possible to distinguish between the output produced by
the target "xenversion" and `make`'s own output.
Instead of running make, this patch "improve" `version.sh` to try to
guess the output of `make xenversion`.
In order to have version.sh works in more scenario, it will use
XEN_EXTRAVERSION and XEN_VENDORVERSION from the environment when
present. As for the cases were those two variables are overridden by a
make command line arguments, we export them when invoking version.sh
via a new $(XEN_FULLVERSION) macro.
That should hopefully get us to having ./version.sh returning the same
value that `make xenversion` would.
This fix GitLab CI's build job "debian-unstable-gcc-arm64".
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com> Reviewed-by: Daniel P. Smith <dpsmith@apertussolutions.com> Reviewed-by: Ian Jackson <iwj@xenproject.org>
Jan Beulich [Wed, 29 Sep 2021 09:57:22 +0000 (11:57 +0200)]
x86/PVH: actually show Dom0's stacks from debug key '0'
show_guest_stack() does nothing for HVM. Introduce a HVM-specific
dumping function, paralleling the 64- and 32-bit PV ones. We don't know
the real stack size, so only dump up to the next page boundary.
Rather than adding a vcpu parameter to hvm_copy_from_guest_linear(),
introduce hvm_copy_from_vcpu_linear() which - for now at least - in
return won't need a "pfinfo" parameter.
Signed-off-by: Jan Beulich <jbeulich@suse.com> Reviewed-by: Roger Pau Monné <roger.pau@citrix.com>
Jan Beulich [Wed, 29 Sep 2021 09:56:18 +0000 (11:56 +0200)]
x86/HVM: convert hvm_virtual_to_linear_addr() to be remote-capable
While all present callers want to act on "current", stack dumping for
HVM vCPU-s will require the function to be able to act on a remote vCPU.
To avoid touching all present callers, convert the existing function to
an inline wrapper around the extend new one.
Signed-off-by: Jan Beulich <jbeulich@suse.com> Reviewed-by: Roger Pau Monné <roger.pau@citrix.com>
Jan Beulich [Tue, 28 Sep 2021 14:03:38 +0000 (16:03 +0200)]
x86/PVH: actually show Dom0's register state from debug key '0'
vcpu_show_registers() didn't do anything for HVM so far. Note though
that some extra hackery is needed for VMX - see the code comment.
Note further that the show_guest_stack() invocation is left alone here:
While strictly speaking guest_kernel_mode() should be predicated by a
PV / !HVM check, show_guest_stack() itself will bail immediately for
HVM.
While there and despite not being PVH-specific, take the opportunity and
filter offline vCPU-s: There's not really any register state associated
with them, so avoid spamming the log with useless information while
still leaving an indication of the fact.
Signed-off-by: Jan Beulich <jbeulich@suse.com> Reviewed-by: Roger Pau Monné <roger.pau@citrix.com>
xen/arm: optee: Fix arm_smccc_smc's a0 for OPTEE_SMC_DISABLE_SHM_CACHE
Fix a possible copy-paste error in arm_smccc_smc's first argument (a0)
for OPTEE_SMC_DISABLE_SHM_CACHE case.
This error causes Linux > v5.14-rc5 (b5c10dd04b7418793517e3286cde5c04759a86de
optee: Clear stale cache entries during initialization) to stuck
repeatedly issuing OPTEE_SMC_DISABLE_SHM_CACHE call and waiting for
the result to be OPTEE_SMC_RETURN_ENOTAVAIL which will never happen.
In case abi-dumper is available the stubdom builds will fail due to a
false dependency on dynamic loadable libraries. Fix that.
Fixes: d7c9f7a7a3959913b4 ("tools/libs: Write out an ABI analysis when abi-dumper is available") Signed-off-by: Juergen Gross <jgross@suse.com> Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
Kevin Stefanov [Wed, 15 Sep 2021 14:30:00 +0000 (15:30 +0100)]
tools/libxl: Correctly align the ACPI tables
The memory allocator currently calculates alignment in libxl's virtual
address space, rather than guest physical address space. This results
in the FACS being commonly misaligned.
Furthermore, the allocator has several other bugs.
The opencoded align-up calculation is currently susceptible to a bug
that occurs in the corner case that the buffer is already aligned to
begin with. In that case, an align-sized memory hole is introduced.
The while loop is dead logic because its effects are entirely and
unconditionally overwritten immediately after it.
Rework the memory allocator to align in guest physical address space
instead of libxl's virtual memory and improve the calculation, drop
errant extra page in allocated buffer for ACPI tables, and give some
of the variables better names/types.
Fixes: 14c0d328da2b ("libxl/acpi: Build ACPI tables for HVMlite guests") Signed-off-by: Kevin Stefanov <kevin.stefanov@citrix.com> Reviewed-by: Jan Beulich <jbeulich@suse.com> Acked-by: Ian Jackson <iwj@xenproject.org>
x86: initialize memnodemapsize while faking NUMA node
When system turns NUMA off or system lacks of NUMA support,
Xen will fake a NUMA node to make system works as a single
node NUMA system.
In this case the memory node map doesn't need to be allocated
from boot pages, it will use the _memnodemap directly. But
memnodemapsize hasn't been set. Xen should assert in phys_to_nid.
Because x86 was using an empty macro "VIRTUAL_BUG_ON" to replace
ASSERT, this bug will not be triggered on x86.
Actually, Xen will only use 1 slot of memnodemap in this case.
So we set memnodemap[0] to 0 and memnodemapsize to 1 in this
patch to fix it.
Signed-off-by: Wei Chen <wei.chen@arm.com> Acked-by: Jan Beulich <jbeulich@suse.com>
Jan Beulich [Fri, 24 Sep 2021 09:00:30 +0000 (11:00 +0200)]
common: guest_physmap_add_page()'s return value needs checking
The function may fail; it is not correct to indicate "success" in this
case up the call stack. Mark the function must-check to prove all
cases have been caught (and no new ones will get introduced).
Signed-off-by: Jan Beulich <jbeulich@suse.com> Reviewed-by: Roger Pau Monné <roger.pau@citrix.com> Acked-by: Ian Jackson <iwj@xenproject.org> Acked-by: Stefano Stabellini <sstabellini@kernel.org>
Jan Beulich [Wed, 22 Sep 2021 14:19:21 +0000 (16:19 +0200)]
x86: drop a bogus SHARED_M2P() check from PV Dom0 building code
If anything, a check covering a wider range of invalid M2P entries ought
to be used (e.g. VALID_M2P()). But since everything is fully under Xen's
control at this stage, simply remove the BUG_ON().
Signed-off-by: Jan Beulich <jbeulich@suse.com> Acked-by: Roger Pau Monné <roger.pau@citrix.com>
Commit 540a637c3410780b519fc055f432afe271f642f8 defines a new
helper mark_page_free to extract common codes, while it accidently
breaks the local variable "tainted".
This patch fix it by letting mark_page_free() return bool of whether the
page is offlined and rename local variable "tainted" to "pg_offlined".
Tamas K Lengyel [Wed, 22 Sep 2021 14:17:54 +0000 (16:17 +0200)]
x86/mem_sharing: don't lock parent during fork reset
During fork reset operation the parent domain doesn't need to be gathered using
rcu_lock_live_remote_domain_by_id, the fork already has the parent pointer.
Signed-off-by: Tamas K Lengyel <tamas.lengyel@intel.com> Reviewed-by: Jan Beulich <jbeulich@suse.com>
Jan Beulich [Wed, 22 Sep 2021 14:17:04 +0000 (16:17 +0200)]
AMD/IOMMU: add "ivmd=" command line option
Just like VT-d's "rmrr=" it can be used to cover for firmware omissions.
Since systems surfacing IVMDs seem to be rare, it is also meant to allow
testing of the involved code.
Only the IVMD flavors actually understood by the IVMD parsing logic can
be generated, and for this initial implementation there's also no way to
control the flags field - unity r/w mappings are assumed.
Signed-off-by: Jan Beulich <jbeulich@suse.com> Reviewed-by: Paul Durrant <paul@xen.org>
Jan Beulich [Wed, 22 Sep 2021 14:16:28 +0000 (16:16 +0200)]
AMD/IOMMU: provide function backing XENMEM_reserved_device_memory_map
Just like for VT-d, exclusion / unity map ranges would better be
reflected in e.g. the guest's E820 map. The reporting infrastructure
was put in place still pretty tailored to VT-d's needs; extend
get_reserved_device_memory() to allow vendor specific code to probe
whether a particular (seg,bus,dev,func) tuple would get its data
actually recorded. I admit the de-duplication of entries is quite
limited for now, but considering our trouble to find a system
surfacing _any_ IVMD this is likely not a critical issue for this
initial implementation.
Signed-off-by: Jan Beulich <jbeulich@suse.com> Reviewed-by: Paul Durrant <paul@xen.org>
Jan Beulich [Wed, 22 Sep 2021 14:15:29 +0000 (16:15 +0200)]
AMD/IOMMU: also insert IVMD ranges into Dom0's page tables
So far only one region would be taken care of, if it can be placed in
the exclusion range registers of the IOMMU. Take care of further ranges
as well. Seeing that we've been doing fine without this, make both
insertion and removal best effort only.
Signed-off-by: Jan Beulich <jbeulich@suse.com> Reviewed-by: Paul Durrant <paul@xen.org>
Jan Beulich [Wed, 22 Sep 2021 14:14:19 +0000 (16:14 +0200)]
AMD/IOMMU: check / convert IVMD ranges for being / to be reserved
While the specification doesn't say so, just like for VT-d's RMRRs no
good can come from these ranges being e.g. conventional RAM or entirely
unmarked and hence usable for placing e.g. PCI device BARs. Check
whether they are, and put in some limited effort to convert to reserved.
(More advanced logic can be added if actual problems are found with this
simplistic variant.)
Signed-off-by: Jan Beulich <jbeulich@suse.com> Reviewed-by: Paul Durrant <paul@xen.org>
Andrew Cooper [Mon, 20 Sep 2021 14:02:32 +0000 (15:02 +0100)]
x86/pv: Move x86/trace.c to x86/pv/trace.c
This entire file is pv-only, and not excluded from the build by
CONFIG_TRACEBUFFER. Move it into the pv/ directory, build it conditionally,
and drop unused includes.
Also move the contents of asm/trace.h to asm/pv/trace.h to avoid the functions
being declared across the entire hypervisor.
One caller in fixup_page_fault() is effectively PV only, but is not subject to
dead code elimination. Add an additional IS_ENABLED(CONFIG_PV) to keep the
build happy.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> Reviewed-by: Jan Beulich <jbeulich@suse.com>
Andrew Cooper [Fri, 17 Sep 2021 23:32:12 +0000 (00:32 +0100)]
x86/hvm: Remove duplicate calls caused by tracing
1) vpic_ack_pending_irq() calls vlapic_accept_pic_intr() twice, once in the
TRACE_2D() instantiation and once "for real". Make the call only once.
2) vlapic_accept_pic_intr() similarly calls __vlapic_accept_pic_intr() twice,
although this is more complicated to disentangle.
v cannot be NULL because it has already been dereferenced in the function,
causing the ternary expression to always call __vlapic_accept_pic_intr().
However, the return expression of the function takes care to skip the call
if this vCPU isn't the PIC target. As __vlapic_accept_pic_intr() is far
from trivial, make the TRACE_2D() semantics match the return semantics by
only calling __vlapic_accept_pic_intr() when the vCPU is the PIC target.
3) hpet_set_timer() duplicates calls to hpet_tick_to_ns(). Pull the logic out
which simplifies both the TRACE and create_periodic_time() calls.
4) lapic_rearm() makes multiple calls to vlapic_lvtt_period(). Pull it out
into a local variable.
vlapic_accept_pic_intr() is called on every VMEntry, so this is a reduction in
VMEntry complexity across the board.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> Reviewed-by: Jan Beulich <jbeulich@suse.com>
Andrew Cooper [Wed, 15 Sep 2021 16:04:00 +0000 (17:04 +0100)]
x86/hvm: Reduce stack usage from HVMTRACE_ND()
It is pointless to write all 6 entries and only consume the useful subset.
bloat-o-meter shows quite how obscene the overhead is in vmx_vmexit_handler(),
weighing in at 12% of the function arranging unread zeroes on the stack, and
8% for svm_vmexit_handler().
Adjust all users of HVMTRACE_ND(), using TRC_PAR_LONG() where appropriate
instead of opencoding it.
The 0 case needs a little help. All object in C must have a unique address
and _d is passed by pointer. Explicitly permit the optimiser to drop the
array.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> Reviewed-by: Jan Beulich <jbeulich@suse.com>
Jan Beulich [Mon, 20 Sep 2021 08:24:27 +0000 (10:24 +0200)]
VT-d: consider hidden devices when unmapping
Whether to clear an IOMMU's bit in the domain's bitmap should depend on
all devices the domain can control. For the hardware domain this
includes hidden devices, which are associated with DomXEN.
While touching related logic
- convert the "current device" exclusion check to a simple pointer
comparison,
- convert "found" to "bool",
- adjust style and correct a typo in an existing comment.
Signed-off-by: Jan Beulich <jbeulich@suse.com> Reviewed-by: Kevin Tian <kevin.tian@intel.com>
Jan Beulich [Mon, 20 Sep 2021 08:23:08 +0000 (10:23 +0200)]
page-alloc: further adjust assign_page{,s}()
The on-commit editing of 5260e8fb93f0 ("xen: re-define assign_pages and
introduce a new function assign_page") didn't go quite far enough: A
local variable and a function argument also would have wanted adjusting.
modify acquire_domstatic_pages to take an unsigned int size parameter
acquire_domstatic_pages currently takes an unsigned long nr_mfns
parameter, but actually it cannot handle anything larger than an
unsigned int nr_mfns. That's because acquire_domstatic_pages is based on
assign_pages which also takes an unsigned int nr parameter.
So modify the nr_mfns parameter of acquire_domstatic_pages to be
unsigned int.
There is only one caller in
xen/arch/arm/domain_build.c:allocate_static_memory. Check that the value
to be passed to acquire_domstatic_pages is no larger than UINT_MAX. If
it is, print an error and goto fail.
Sanitize CTR_EL0 value between cores and taint Xen if incompatible
values are found.
In the case of different i-cache types, the sanitize ctr_el0 will have a
sanitize value but this is currently not used or exposed to guest which
are seeing the original ctr_el0 value.
Use the opportunity to rename CTR_L1Ip to use an upper case name like
Linux does.
The patch is also defining ICACHE_POLICY_xxx instead of only having
CTR_L1IP_xxx to sync the definitions with Linux and is updating the code
using those accordingly (arm32 setup).
On platforms with only the same type of cores, this patch should not
modify the current Xen behaviour.
Use arm64 cpu feature sanitization to TAINT Xen if different DCZID values
are found (ftr_dczid is using only STRICT method).
In this case actual memory being cleaned by DC ZVA operations would be
different depending on the cores which could make a guest zeroing too
much or too little memory if it is merged between CPUs.
We could, on processors supporting it, trap access to DCZID_EL0 register
using HFGRTR_EL2 register but this would not solve the case where a
process is being migrated during a copy or if it cached the value of the
register.
Replace the code in p2m trying to find a sane value for the VMID size
supported and the PAR to use. We are now using the boot cpuinfo as the
values there are sanitized during boot and the value for those
parameters is now the safest possible value on the system.
Define a sanitize_cpu function to be called on secondary cores to
sanitize the system cpuinfo structure.
The safest value is taken when possible and the system is marked tainted
if we encounter values which are incompatible with each other.
Call the update_system_features function on all secondary cores that are
kept running and taint the system if different midr are found between
cores but hmp-unsafe=true was passed on Xen command line.
This is only supported on arm64 so update_system_features is an empty
static inline on arm32.
The patch is adding a new TAINT_CPU_OUT_OF_SPEC to warn the user if
Xen is running on a system with features differences between cores which
are not supported.
The patch is disabling CTR_EL0, DCZID_EL0 and ZCRusing #if 0 with a TODO
as this patch is not handling sanitization of those registers.
CTR_EL0/DCZID will be handled in a future patch to properly handle
different cache attributes when possible.
ZCR should be sanitize once we add support for SVE in Xen.
As we will sanitize the content of boot_cpu_data it will not really
contain the boot cpu information but the system sanitize information.
Rename the structure to system_cpuinfo so the user is informed that this
is the system wide available feature and not anymore the features of the
boot cpu.
The original boot cpu data is still available in cpu_data.
Import structures declared in Linux file arch/arm64/kernel/cpufeature.c
and the required types from arch/arm64/include/asm/cpufeature.h.
Current code has been imported from Linux 5.13-rc5 (Commit ID cd1245d75ce93b8fd206f4b34eb58bcfe156d5e9) and copied into cpufeature.c
in arm64 code and cpufeature.h in arm64 specific headers.
Those structure will be used to sanitize the cpu features available to
the ones availble on all cores of a system even if we are on an
heterogeneous platform (from example a big/LITTLE).
For each feature field of all ID registers, those structures define what
is the safest value and if we can allow to have different values in
different cores.
This patch is introducing Linux code without any changes to it.
Jan Beulich [Thu, 16 Sep 2021 09:02:48 +0000 (11:02 +0200)]
VT-d: skip IOMMU bitmap cleanup for phantom devices
Doing the cleanup also for phantom devices is at best redundant with
doing it for the corresponding real device. I couldn't force myself into
checking all the code paths whether it really is: It seems better to
explicitly skip this step in such cases.
Signed-off-by: Jan Beulich <jbeulich@suse.com> Reviewed-by: Kevin Tian <kevin.tian@intel.com>
Jan Beulich [Thu, 16 Sep 2021 09:02:08 +0000 (11:02 +0200)]
VT-d: defer "no DRHD" check when (un)mapping devices
If devices are to be skipped anyway (which is the case in particular for
host bridges), there's no point complaining about a missing DRHD (and
hence a missing association with an IOMMU).
While there convert assignments to initializers and constify "drhd"
local variables.
Signed-off-by: Jan Beulich <jbeulich@suse.com> Reviewed-by: Kevin Tian <kevin.tian@intel.com>
Daniel P. Smith [Thu, 16 Sep 2021 08:59:40 +0000 (10:59 +0200)]
xsm: refactor xsm_ops handling
This renames the `struct xsm_operations` to the shorter `struct xsm_ops` and
converts the global xsm_ops from being a pointer to an explicit instance. As
part of this conversion, it reworks the XSM modules init function to return
their xsm_ops struct which is copied in to the global xsm_ops instance.
Signed-off-by: Daniel P. Smith <dpsmith@apertussolutions.com> Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
Daniel P. Smith [Thu, 16 Sep 2021 08:58:59 +0000 (10:58 +0200)]
xsm: apply coding style
Instead of intermixing coding style changes with code changes as they
are come upon in this patch set, moving all coding style changes
into a single commit. The focus of coding style changes here are,
- move trailing comments to line above
- ensuring line length does not exceed 80 chars
- ensuring proper indentation for 80 char wrapping
- covert u32 type statements to uint32_t
- remove space between closing and opening parens
- drop extern on function declarations
Signed-off-by: Daniel P. Smith <dpsmith@apertussolutions.com> Acked-by: Jan Beulich <jbeulich@suse.com>
Jan Beulich [Thu, 16 Sep 2021 08:56:25 +0000 (10:56 +0200)]
IOMMU: page table dumping adjustments
For one none of the three IOMMU implementations on Arm specify a dumping
hook. Generalize VT-d's "don't dump shared page tables" to cover for
this.
Further in the past I was told that on Arm in principle there could be
multiple different IOMMUs, and hence different domains' platform_ops
pointers could differ. Use each domain's ops for calling the dump hook.
(In the long run all uses of iommu_get_ops() would likely need to
disappear for this reason.)
Signed-off-by: Jan Beulich <jbeulich@suse.com> Reviewed-by: Kevin Tian <kevin.tian@intel.com>
If the new gfn matches the previous one (ie: gpfn == old_gpfn)
xenmem_add_to_physmap_one will issue a duplicated call to
guest_physmap_remove_page with the same guest frame number, because
the get_gpfn_from_mfn call has been moved by commit f8582da041 to be
performed before the original page is removed. This leads to the
second guest_physmap_remove_page failing, which was not the case
before commit f8582da041.
Fix this by adding a check that prevents a second call to
guest_physmap_remove_page if the previous one has already removed the
backing page from that gfn.
Fixes: f8582da041 ('x86/mm: pull a sanity check earlier in xenmem_add_to_physmap_one()') Signed-off-by: Roger Pau Monné <roger.pau@citrix.com> Reviewed-by: Jan Beulich <jbeulich@suse.com>
x86: quote section names when defining them in linker script
LLVM ld seems to require section names to be quoted at both definition
and when referencing them for a match to happen, or else we get the
following errors:
The original fix for GNU ld 2.37 only quoted the section name when
referencing it in the ADDR function. Fix by also quoting the section
names when declaring them.
Fixes: 58ad654ebce7 ("x86: work around build issue with GNU ld 2.37") Reported-by: Andrew Cooper <andrew.cooper3@citrix.com> Signed-off-by: Roger Pau Monné <roger.pau@citrix.com> Reviewed-by: Jan Beulich <jbeulich@suse.com>
Jan Beulich [Wed, 15 Sep 2021 09:01:29 +0000 (11:01 +0200)]
x86/boot: properly "ignore" early evaluated "no-real-mode"
The option parser takes off "no-" prefixes before matching, so they also
shouldn't be specified to match against.
Fixes: e44d98608476 ("x86/setup: Ignore early boot parameters like no-real-mode") Signed-off-by: Jan Beulich <jbeulich@suse.com> Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
Jan Beulich [Wed, 15 Sep 2021 09:00:40 +0000 (11:00 +0200)]
x86/ACPI: ignore processors which cannot be brought online
ACPI 6.3 introduced a flag allowing to tell MADT entries describing
hotpluggable processors from ones which are simply placeholders (often
used by firmware writers to simplify handling there).
Inspired by a Linux patch by Mario Limonciello <mario.limonciello@amd.com>.
Requested-by: Andrew Cooper <andrew.cooper3@citrix.com> Signed-off-by: Jan Beulich <jbeulich@suse.com> Reviewed-by: Roger Pau Monné <roger.pau@citrix.com>
This commit introduces a new function allocate_static_memory to allocate
static memory as guest RAM for domains on Static Allocation.
It uses acquire_domstatic_pages to acquire pre-configured static memory
for the domain, and uses guest_physmap_add_pages to set up the P2M table.
These pre-defined static memory banks shall be mapped to the usual guest
memory addresses (GUEST_RAM0_BASE, GUEST_RAM1_BASE) defined by
xen/include/public/arch-arm.h.
In order to deal with the trouble of count-to-order conversion when page number
is not in a power-of-two, this commit exports p2m_insert_mapping and introduce
a new function guest_physmap_add_pages to cope with adding guest RAM p2m
mapping with nr_pages.
xen/arm: introduce acquire_staticmem_pages and acquire_domstatic_pages
New function acquire_staticmem_pages aims to acquire nr_mfns contiguous pages
of static memory, starting at #smfn. And it is the equivalent of
alloc_heap_pages for static memory.
For each page, it shall check if the page is reserved(PGC_reserved)
and free. It shall also do a set of necessary initialization, which are
mostly the same ones in alloc_heap_pages, like, following the same
cache-coherency policy and turning page status into PGC_state_inuse, etc.
New function acquire_domstatic_pages is the equivalent of alloc_domheap_pages
for static memory, and it is to acquire nr_mfns contiguous pages of
static memory and assign them to one specific domain.
It uses acquire_staticmem_pages to acquire nr_mfns pages of static memory.
Then on success, it will use assign_pages to assign those pages to one
specific domain.
In order to differentiate pages of static memory from those allocated from
heap, this patch introduces a new page flag PGC_reserved, then mark pages of
static memory PGC_reserved when initializing them.
xen: re-define assign_pages and introduce a new function assign_page
In order to deal with the trouble of count-to-order conversion when page number
is not in a power-of-two, this commit re-define assign_pages for nr pages and
assign_page for original page with a single order.
Backporting confusion could be helped by altering the order of assign_pages
parameters, such that the compiler would point out that adjustments at call
sites are needed.
[stefano: switch to unsigned int for nr] Signed-off-by: Penny Zheng <penny.zheng@arm.com> Signed-off-by: Stefano Stabellini <stefano.stabellini@xilinx.com> Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
This commit defines a new helper mark_page_free to extract common code,
like following the same cache/TLB coherency policy, between free_heap_pages
and the new function free_staticmem_pages, which will be introduced later.
The PDX compression makes that conversion between the MFN and the page can
be potentially non-trivial. As the function is internal, pass the MFN and
the page. They are both expected to match.
Static Allocation refers to system or sub-system(domains) for which memory
areas are pre-defined by configuration using physical address ranges.
Those pre-defined memory, -- Static Memory, as parts of RAM reserved in the
beginning, shall never go to heap allocator or boot allocator for any use.
Memory can be statically allocated to a domain using the property "xen,static-
mem" defined in the domain configuration. The number of cells for the address
and the size must be defined using respectively the properties
"#xen,static-mem-address-cells" and "#xen,static-mem-size-cells".
The property 'memory' is still needed and should match the amount of memory
given to the guest. Currently, it either comes from static memory or lets Xen
allocate from heap. *Mixing* is not supported.
The static memory will be mapped in the guest at the usual guest memory
addresses (GUEST_RAM0_BASE, GUEST_RAM1_BASE) defined by
xen/include/public/arch-arm.h.
This patch introduces this new `xen,static-mem` feature, and also documents
and parses this new attribute at boot time.
This patch also introduces a new field "bool xen_domain" in "struct membank"
to tell whether the memory bank is reserved as the whole hardware resource,
or bind to a xen domain node, through "xen,static-mem"
Make the go build use APPEND_{C/LD}FLAGS when necessary, just like
other parts of the build.
Reported-by: Ting-Wei Lan <lantw44@gmail.com> Signed-off-by: Roger Pau Monné <roger.pau@citrix.com> Acked-by: Nick Rosbrook <rosbrookn@ainfosec.com> Acked-by: Ian Jackson <iwj@xenproject.org>
Daniel P. Smith [Fri, 10 Sep 2021 20:12:57 +0000 (16:12 -0400)]
xsm: remove the ability to disable flask
On Linux when SELinux is put into permissive mode the discretionary access
controls are still in place. Whereas for Xen when the enforcing state of flask
is set to permissive, all operations for all domains would succeed, i.e. it
does not fall back to the default access controls. To provide a means to mimic
a similar but not equivalent behaviour, a flask op is present to allow a
one-time switch back to the default access controls, aka the "dummy policy".
While this may be desirable for an OS, Xen is a hypervisor and should not
allow the switching of which security policy framework is being enforced after
boot. This patch removes the flask op to enforce the desired XSM usage model
requiring a reboot of Xen to change the XSM policy module in use.
Signed-off-by: Daniel P. Smith <dpsmith@apertussolutions.com> Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
Andrew Cooper [Fri, 10 Sep 2021 20:12:56 +0000 (16:12 -0400)]
xen: Implement xen/alternative-call.h for use in common code
The alternative call infrastructure is x86-only for now, but the common iommu
code has a variant and more common code wants to use the infrastructure.
Introduce CONFIG_ALTERNATIVE_CALL and a conditional implementation so common
code can use the optimisation when available, without requiring all
architectures to implement no-op stubs.
Write some documentation, which was thus far entirely absent, covering the
requirements for an architecture to implement this optimisation, and how to
use the infrastructure in general code.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> Signed-off-by: Daniel P. Smith <dpsmith@apertussolutions.com> Acked-by: Jan Beulich <jbeulich@suse.com>
Andrew Cooper [Mon, 19 Aug 2019 15:40:06 +0000 (16:40 +0100)]
x86/svm: Intercept and terminate RDPRU with #UD
The RDPRU instruction isn't supported at all (and it is unclear how this can
ever be offered safely to guests). However, a guest which ignores CPUID and
blindly executes RDPRU will find that it functions.
Use the intercept and terminate with #UD. While at it, fold SKINIT into the
same "unconditionally disabled" path.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> Reviewed-by: Jan Beulich <jbeulich@suse.com>
Andrew Cooper [Fri, 25 May 2018 15:13:02 +0000 (16:13 +0100)]
x86/msr: Cleanup of misc constants
Move two blocks of MSRs into the cleaned up section, updating the style as
they move.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> Reviewed-by: Wei Liu <wei.liu2@citrix.com> Reviewed-by: Roger Pau Monné <roger.pau@citrix.com>
Andrew Cooper [Fri, 25 May 2018 15:12:05 +0000 (16:12 +0100)]
x86/msr: Clean up the MSR_EFER constants
There are no remaining users of the bit position constants. Move the used
constants into the cleaned-up area of msr-index.h and apply appropriate style.
Rename EFER_NX to EFER_NXE to match both the Intel and AMD specs.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> Reviewed-by: Wei Liu <wei.liu2@citrix.com> Reviewed-by: Roger Pau Monné <roger.pau@citrix.com>
Andrew Cooper [Fri, 30 Nov 2018 17:17:38 +0000 (17:17 +0000)]
x86/amd: Use newer SSBD mechanisms if they exist
The opencoded legacy Memory Disambiguation logic in init_amd() neglected
Fam19h for the Zen3 microarchitecture. Further more, all Zen2 based system
have the architectural MSR_SPEC_CTRL and the SSBD bit within it, so shouldn't
be using MSR_AMD64_LS_CFG.
Implement the algorithm given in AMD's SSBD whitepaper, and leave a
printk_once() behind in the case that no controls can be found.
This now means that a user explicitly choosing `spec-ctrl=ssbd` will properly
turn off Memory Disambiguation on Fam19h/Zen3 systems.
This still remains a single system-wide setting (for now), and is not context
switched between vCPUs. As such, it doesn't interact with Intel's use of
MSR_SPEC_CTRL and default_xen_spec_ctrl (yet).
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> Reviewed-by: Jan Beulich <jbeulich@suse.com>
Andrew Cooper [Mon, 12 Jul 2021 14:13:32 +0000 (15:13 +0100)]
x86/amd: Enumeration for speculative features/hints
There is a step change in speculation protections between the Zen1 and Zen2
microarchitectures.
Zen1 and older have no special support. Control bits in non-architectural
MSRs are used to make lfence be dispatch-serialising (Spectre v1), and to
disable Memory Disambiguation (Speculative Store Bypass). IBPB was
retrofitted in a microcode update, and software methods are required for
Spectre v2 protections.
Because the bit controlling Memory Disambiguation is model specific,
hypervisors are expected to expose a MSR_VIRT_SPEC_CTRL interface which
abstracts the model specific details.
Zen2 and later implement the MSR_SPEC_CTRL interface in hardware, and
virtualise the interface for HVM guests to use. A number of hint bits are
specified too to help guide OS software to the most efficient mitigation
strategy.
Zen3 introduced a new feature, Predictive Store Forwarding, along with a
control to disable it in sensitive code.
Add CPUID and VMCB details for all the new functionality.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> Reviewed-by: Jan Beulich <jbeulich@suse.com>
Andrew Cooper [Thu, 29 Jul 2021 10:59:22 +0000 (11:59 +0100)]
x86/spec-ctrl: Split the "Hardware features" diagnostic line
Separate the read-only hints from the features requiring active actions on
Xen's behalf.
Also take the opportunity split the IBRS/IBPB and IBPB mess. More features
with overlapping enumeration are on the way, and and it is not useful to split
them like this.
No practical change.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> Reviewed-by: Jan Beulich <jbeulich@suse.com>
Jane Malalane [Wed, 8 Sep 2021 12:39:18 +0000 (14:39 +0200)]
x86/cpuid: detect null segment behaviour on Zen2 CPUs
All Zen2 CPUs actually have this behaviour, but the CPUID bit couldn't
be introduced into Zen2 due to a lack of leaves. So, it was added in a
new leaf in Zen3. Nonetheless, hypervisors can synthesize the CPUID
bit in software.
So, Xen probes for NSCB (NullSelectorClearsBit) and
synthesizes the bit, if the behaviour is present.
Suggested-by: Andrew Cooper <andrew.cooper3@citrix.com> Signed-off-by: Jane Malalane <jane.malalane@citrix.com> Reviewed-by: Jan Beulich <jbeulich@suse.com>
Jan Beulich [Wed, 8 Sep 2021 12:38:33 +0000 (14:38 +0200)]
domain: try to address Coverity pointing out a missing "break" in domain_teardown()
Commit 806448806264 ("xen/domain: Fix label position in
domain_teardown()" has caused Coverity to report a _new_ supposedly
un-annotated fall-through in a switch(). I find this (once again)
puzzling; I'm having an increasingly hard time figuring what patterns
the tool is actually after. I would have expected that the tool would
either have spotted an issue also before this change, or not at all. Yet
if it had spotted one before, the statistics report should have included
an eliminated instance alongside the new one (because then the issue
would simply have moved by a few lines).
Hence the only thing I could guess is that the treatment of comments in
macro expansions might be subtly different. Therefore try whether
switching the comments to the still relatively new "fallthrough" pseudo
keyword actually helps.
Jan Beulich [Wed, 8 Sep 2021 12:37:45 +0000 (14:37 +0200)]
gnttab: deal with status frame mapping race
Once gnttab_map_frame() drops the grant table lock, the MFN it reports
back to its caller is free to other manipulation. In particular
gnttab_unpopulate_status_frames() might free it, by a racing request on
another CPU, thus resulting in a reference to a deallocated page getting
added to a domain's P2M.
Obtain a page reference in gnttab_map_frame() to prevent freeing of the
page until xenmem_add_to_physmap_one() has actually completed its acting
on the page. Do so uniformly, even if only strictly required for v2
status pages, to avoid extra conditionals (which then would all need to
be kept in sync going forward).
Jan Beulich [Tue, 7 Sep 2021 12:24:49 +0000 (14:24 +0200)]
x86/p2m-pt: fix p2m_flags_to_access()
The initial if() was inverted, invalidating all output from this
function. Which in turn means the mirroring of P2M mappings into the
IOMMU didn't always work as intended: Mappings may have got updated when
there was no need to. There would not have been too few (un)mappings;
what saves us is that alongside the flags comparison MFNs also get
compared, with non-present entries always having an MFN of 0 or
INVALID_MFN while present entries always have MFNs different from these
two (0 in the table also meant to cover INVALID_MFN):
OLD NEW
P W access MFN P W access MFN
0 0 r 0 0 0 n 0
0 1 rw 0 0 1 n 0
1 0 n non-0 1 0 r non-0
1 1 n non-0 1 1 rw non-0
present <-> non-present transitions are fine because the MFNs differ.
present -> present transitions as well as non-present -> non-present
ones are potentially causing too many map/unmap operations, but never
too few, because in that case old (bogus) and new access differ.
Fixes: d1bb6c97c31e ("IOMMU: also pass p2m_access_t to p2m_get_iommu_flags()) Signed-off-by: Jan Beulich <jbeulich@suse.com> Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
Jane Malalane [Tue, 7 Sep 2021 07:40:25 +0000 (09:40 +0200)]
x86/cpuid: expose NullSelectorClearsBase CPUID bit to guests
AMD Zen3 adds the NullSelectorClearsBase bit to indicate that loading
a NULL segment selector zeroes the base and limit fields, as well as
just attributes.
Expose bit to all guests.
Suggested-by: Andrew Cooper <andrew.cooper3@citrix.com> Signed-off-by: Jane Malalane <jane.malalane@citrix.com> Reviewed-by: Jan Beulich <jbeulich@suse.com>
Jan Beulich [Tue, 7 Sep 2021 07:39:38 +0000 (09:39 +0200)]
x86/P2M: relax guarding of MMIO entries
One of the changes comprising the fixes for XSA-378 disallows replacing
MMIO mappings by code paths not intended for this purpose. At least in
the case of PVH Dom0 hitting an RMRR covered by an E820 ACPI region,
this is too strict. Generally short-circuit requests establishing the
same kind of mapping (mfn, type), but allow permissions to differ.
While there, also add a log message to the other domain_crash()
invocation that did prevent PVH Dom0 from coming up after the XSA-378
changes.
Fixes: 753cb68e6530 ("x86/p2m: guard (in particular) identity mapping entries") Signed-off-by: Jan Beulich <jbeulich@suse.com> Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
Jan Beulich [Tue, 7 Sep 2021 07:38:42 +0000 (09:38 +0200)]
gnttab: maptrack handle shortage is not IOMMU related
Both comment and message string associated with GNTST_no_device_space
suggest a connection to the IOMMU. A lack of maptrack handles has
nothing to do with that; it's unclear to me why commit 6213b696ba65
("Grant-table interface redone") introduced it this way. Introduce a
new error indicator.
Signed-off-by: Jan Beulich <jbeulich@suse.com> Acked-by: Julien Grall <jgrall@amazon.com>
Jan Beulich [Tue, 7 Sep 2021 07:37:50 +0000 (09:37 +0200)]
gnttab: adjust unmap checking of dev_bus_addr
There's no point checking ->dev_bus_addr when GNTMAP_device_map isn't
set (and hence the field isn't going to be consumed). And if there is a
mismatch, use the so far unused GNTST_bad_dev_addr error indicator - if
not here, where else would this (so far unused) value be used?
Signed-off-by: Jan Beulich <jbeulich@suse.com> Acked-by: Julien Grall <jgrall@amazon.com>
Jan Beulich [Tue, 7 Sep 2021 07:36:59 +0000 (09:36 +0200)]
ns16550: MMIO r/o ranges are maintained at page granularity
Passing byte granular values will not have the intended effect. Address
the immediate issue, but I don't think what we do is actually
sufficient: At least some devices allow access to their registers via
either I/O ports or MMIO. In such aliasing cases we'd need to protect
the MMIO range even when we use I/O port accesses to drive the port.
Note that this way we may write-protect MMIO ranges of unrelated devices
as well. To deal with this, faults resulting from this would need
handling, to emulate the accesses outside of the protected range. (An
alternative would be to relocate the BAR, but I'm afraid this might end
up even more challenging.)
Fixes: c9f8e0aee507 ("ns16550: Add support for UART present in Broadcom TruManage capable NetXtreme chips") Signed-off-by: Jan Beulich <jbeulich@suse.com> Reviewed-by: Julien Grall <jgrall@amazon.com>
Anthony PERARD [Tue, 7 Sep 2021 07:30:25 +0000 (09:30 +0200)]
build: fix clean targets when subdir-y is used
The make variable $(subdir-y) isn't used yet but will be in a
following patch. Anything in $(subdir-y) doesn't to have a '/' as
suffix as we already now it's a directory.
Rework the rules so that it doesn't matter whether there is a '/' or
not. It also mimic more closely to the way Linux's Kbuild descend in
subdirectories.
FORCE phony target isn't needed anymore running clean, so it can be
removed.
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com> Reviewed-by: Jan Beulich <jbeulich@suse.com>
projects / xen.git / log