The current logic on x86 will mark all domain owned pages as needing a TLB
flush before being re-used. However such TLB flushing is only strictly
needed when the pages might have been mapped by a PV domain, as those can
keep a reference to the page in the TLB after it has been freed.
Limit the flushing to builds with PV domain support, as tracking whether a
page might have been mapped by a PV domain is not trivial (and possibly not
worth the extra logic).
Signed-off-by: Roger Pau Monné <roger@xenproject.org>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Adjust some types: int -> bool, int -> unsigned int. Also fix a couple of
typos plus trailing white space.
No functional change intended.
Signed-off-by: Roger Pau Monné <roger@xenproject.org>
Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
The current way in which idle TLB flush and TLB flushing when allocating a
page are done allows for the scrubbing to be done ahead of the TLB flush.
A PV domain can still have a TLB entry for the page after scrubbing, and
hence it may be able to modify it. Such unintended page accessing allows
domains to possibly exchange information even when `xsm=silo scrub-domheap`
are in effect.
Remove the MEMF_no_tlbflush memory allocation flag, and reorder the
flushing so it's always done ahead of the scrubbing in
alloc_{,color_}heap_pages(). The sole user of MEMF_no_tlbflush is
populate_physmap(), and given the constrains above it's no longer safe
to defer the flush, hence the flag removal and the folding of the flush in
the allocator function itself.
This is XSA-511 / CVE-2026-79603.
Fixes: 24f1a58d19 ("mm: option to _always_ scrub freed domheap pages")
Signed-off-by: Roger Pau Monné <roger@xenproject.org>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
hvm_io_intercept() can return X86EMUL_RETRY, and as such it needs to be
handled in the switch in hvmemul_do_io() to avoid triggering the BUG() from
the default case.
Reset the vCPU state to no in-flight IOREQ and return X86EMUL_RETRY so that
the access is retried.
This is XSA-510 / CVE-2026-79602.
Reported-by: Jiqian Chen <Jiqian.Chen@amd.com>
Signed-off-by: Roger Pau Monné <roger@xenproject.org>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
It's possible for domains to generate unaligned PCI config space accesses
when using ECAM, and hence vPCI should support those at least for the
hardware domain. Such unaligned accesses to the PCI config space have been
reported to come from ACPI logic.
Relax the checking in vpci_access_allowed() to allow such accesses for the
hardware domain, and fix the handling in pci_conf_{read,write}{16,32}() to
fulfill them using MMCFG.
MMCFG regions are identity exposed to the hardware domain, and hence such
unaligned accesses can only come as a result of the host having MMCFG in the
first place, as otherwise MMCFG won't be exposed to the hardware domain
either.
Note that vpci_ecam_{read,write}() already refuse accesses that cross a
device boundary unconditionally.
Reported-by: Jason Andryuk <jason.andryuk@amd.com>
Signed-off-by: Roger Pau Monné <roger@xenproject.org>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Stewart Hildebrand <stewart.hildebrand@amd.com>
Roger Pau Monne