The code in viridian_synic_wrmsr() duplicates logic in vlapic_reg_write()
to update the ICR, ICR2 and TASKPRI registers. Instead of doing this,
make vlapic_reg_write() non-static and call it.
Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
Rename "offset" to "reg" for consistency with the rest of the vlapic API.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
When viridian APIC assist is active, the code in vlapic_has_pending_irq()
may end up re-calling vlapic_find_highest_isr() after emulating an EOI
whereas simply moving the call after the EOI emulation removes the need
for this duplication.
Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
To be able to use it for the hot-plugged CPUs as well.
The reason why we link proc_info_list in ".rodata" section is that
it context should never be modified.
This patch also renames ".init.proc.info" section to ".proc.info"
as "init" prefix is not actual anymore.
Signed-off-by: Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>
The Xenstore domid isn't set for HVM domains. This will result in
failure when booting a HVM domain on a system with Xenstore not running
in dom0.
Same applies for console domid, so set both.
This is broken since commit a2d9a6fa1f ("tools/libxenctrl: use new
xenforeignmemory API to seed grant table").
Signed-off-by: Juergen Gross <jgross@suse.com>
Acked-by: Wei Liu <wei.liu2@citrix.com>
Which, on x86, requires fiddling with the INTx bit in PCI config space,
since for internally used MSI we can't delegate this to Dom0.
ns16550_init_postirq() also needs (benign) re-ordering of its
operations.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Wei Liu <wei.liu2@citrix.com>
Reviewed-by: Roger Pau Monné <roger.pau@citrix.com>
In order for a Xen internal PCI device driver to enable MSI on the
device, we need another hook which the driver can use to create the IRQ
(doing this in the init_preirq hook is too early, since IRQ code hasn't
got initialized at that time yet, and doing it in init_postirq is too
late because at least on x86 smp_intr_init() needs to know the IRQ
number).
On x86 this additionally requires a slight ordering change to IRQ
initialization, to facilitate calling the new hook between basic
initialization and the call path leading to smp_intr_init().
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Wei Liu <wei.liu2@citrix.com>
Reviewed-by: Roger Pau Monné <roger.pau@citrix.com>
Even if unlikely, donate_page() should not ignore the possible need to
obtain a domain reference. To make people look more closely when they
add new uses of domain_adjust_tot_pages(), force its return value to be
checked. This in turn requires a benign change to assign_pages().
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
Quite a bit of duplicate code has accumulated on the "paging" types
special case path. Re-use what can be re-used from the common path.
Since it needs touching anyway, slightly re-format and extend the
gdprintk() on the common path as well.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
Break out files for build jobs and test jobs. Keep the top level
.gitlab-ci.yaml small.
Signed-off-by: Wei Liu <wei.liu2@citrix.com>
Acked-by: Doug Goldstein <cardoe@cardoe.com>
Dispatch from the guest_{rd,wr}msr() functions. The read side should be safe
outside of current context, but the write side is definitely not. As the
toolstack has no legitimate reason to access the APIC registers via this
interface (not least because whether they are accessible at all depends on
guest settings), unilaterally reject access attempts outside of current
context.
Rename to guest_{rd,wr}msr_x2apic() for consistency, and alter the functions
to use X86EMUL_EXCEPTION rather than X86EMUL_UNHANDLEABLE. The previous
callers turned UNHANDLEABLE into EXCEPTION, but using UNHANDLEABLE will now
interfere with the fallback to legacy MSR handling.
While altering guest_rdmsr_x2apic() make a couple of minor improvements.
Reformat the initialiser for readable[] so it indents in a more natural way,
and alter high to be a 64bit integer to avoid shifting 0 by 32 in the common
path.
Observant people might notice that we now don't let PV guests read the x2apic
MSRs. They should never have been able to in the first place.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Roger Pau Monné <roger.pau@citrix.com>
We currently have MSR_IA32_APICBASE and MSR_IA32_APICBASE_MSR which are
synonymous from a naming point of view, but refer to very different things.
Rename the x2APIC MSRs to MSR_X2APIC_*, which are shorter constants and
visually separate the register function from the generic APIC name. For the
case ranges, introduce MSR_X2APIC_LAST, rather than relying on the knowledge
that there are 0x3ff MSRs architecturally reserved for x2APIC functionality.
For functionality relating to the APIC_BASE MSR, use MSR_APIC_BASE for the MSR
itself, but drop the MSR prefix from the other constants to shorten the names.
In all cases, the fact that we are dealing with the APIC_BASE MSR is obvious
from the context.
No functional change (the combined binary is identical).
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Reviewed-by: Kevin Tian <kevin.tian@intel.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Roger Pau Monné <roger.pau@citrix.com>
This appears to be a vestigial remnent of an old version of the
XSA-254/Spectre series, and has never been used.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
bti= was introduced with the original Spectre fixes (Jan 2018), but by the
time Speculative Store Bypass came along (May 2018), it was superceeded by the
more generic spec-ctrl=.
Since then, we've had LazyFPU (June 2018) and L1TF (August 2018), which means
noone will be using the option. Remove it entirely - anyone who happens to
accidentially be using it might now spot Xen complaining about an option it
doesn't understand.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
These errata affect the values read from the BAR registers, and could
render vPCI (and by extension PVH Dom0 unusable).
HSE43 is a Haswell erratum where a non-BAR register is implemented at
the position where the first BAR of the device should be found in a
Power Control Unit device. Note that there are no BARs on this device,
apart from the bogus CSR register positioned on top of the first BAR.
BDF2/BDX2 is a Broadwell erratum where BARs in the Home Agent device
will return bogus non-zero values.
In both cases the solution is to treat such devices as having no BARs
in the vPCI code.
Reported-by: Jan Beulich <jbeulich@suse.com>
Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
This is a check explicitly listed by the instruction page in the SDM.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
get_cpuid_domain_info() has two conflicting return styles - either -error for
local failures, or -1/errno for hypercall failures. Switch to consistently
use -error.
While fixing the xc_get_cpu_featureset(), take the opportunity to remove the
redundancy and move it to be adjacent to the other featureset handling.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Wei Liu <wei.liu2@citrix.com>
In almost all cases, Xen and libxc will agree on the featureset length,
because they are built from the same source.
However, there are circumstances (e.g. security hotfixes) where the featureset
gets longer and dom0 will, after installing updates, be running with an old
Xen but new libxc. Despite writing the code with this scenario in mind, there
were some bugs.
First, xen-cpuid's get_featureset() erroneously allocates a buffer based on
Xen's featureset length, but records libxc's length, which may be longer.
In this situation, the hypercall bounce buffer code reads/writes the recorded
length, which is beyond the end of the allocated object, and a later free()
encounters corrupt heap metadata. Fix this by recording the same length that
we allocate.
Secondly, get_cpuid_domain_info() has a related bug when the passed-in
featureset is a different length to libxc's.
A large amount of the libxc cpuid functionality depends on info->featureset
being as long as expected, and it is allocated appropriately. However, in the
case that a shorter external featureset is passed in, the logic to check for
trailing nonzero bits may read off the end of it. Rework the logic to use the
correct upper bound.
In addition, leave a comment next to the fields in struct cpuid_domain_info
explaining the relationship between the various lengths, and how to cope with
different lengths.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Wei Liu <wei.liu2@citrix.com>
Every invocation of xl via valgrind will show three leaks.
Since libxl_bitmap_alloc uses NOGC, the caller has to free the memory
after use. And since xl_ctx_free might be called before
parse_global_config, also move the libxl_bitmap_init calls into
xl_ctx_alloc.
Also move the call to atexit() after xl_ctx_alloc, because the latter is
also called again in postfork.
Signed-off-by: Olaf Hering <olaf@aepfle.de>
Acked-by: Wei Liu <wei.liu2@citrix.com>
We've had more than one report of host crashes after failed migration,
and in at least one case we've had a hint towards a too far shrunk
shadow allocation pool. Instead of just checking the pool for being
empty, check whether the pool is smaller than what
shadow_set_allocation() would minimally bump it to if it was invoked in
the first place.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Tim Deegan <tim@xen.org>
Host bridges are not behind an IOMMU, and are already special cased and
skipped in amd_iommu_add_device. Apply the same special casing when
updating page tables.
This is required or else update_paging_mode will fail and return an
error to the caller (amd_iommu_{un}map_page) which will destroy the
domain.
Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
Acked-by: Brian Woods <brian.woods@amd.com>
AMD IOMMU devices are exposed on the PCI bus, and thus are assigned by
default to the hardware domain. This can cause issues because the
IOMMU devices themselves are not behind an IOMMU, so update_paging_mode will
return an error if Xen tries to expand the page tables of a domain
that has assigned devices not behind an IOMMU. update_paging_mode
failing will cause the domain to be destroyed.
Fix this by hiding PCI IOMMU devices, so they are not assigned to the
hardware domain.
Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Brian Woods <brian.woods@amd.com>
...for N in {8, 16, 32, 64}.
Bring the coding style up to date.
Also, while in the neighbourhood, fix some tabs and remove use of uint64_t
values where it leads to the need for explicit casting.
Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Brian Woods <brian.woods@amd.com>
Selecting between single/multiple BAR mode should happen after checking
whether to skip the present device, or else multi-BAR devices won't be
skipped correctly, due to port_idx getting set to zero in that case.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Wei Liu <wei.liu2@citrix.com>
paging_max_paddr_bits() has an invalid use of IS_ENABLED(): instead of
IS_ENABLED(CONFIG_BIGMEM) it is using IS_ENABLED(BIGMEM). Fix that.
Signed-off-by: Juergen Gross <jgross@suse.com>
Reviewed-by: Roger Pau Monné <roger.pau@citrix.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
As done for other cases by commit 7869e2bafe ("x86emul/fuzz: add
rudimentary limit checking"), address calculations should also use
truncate_ea() for the AVX2 gather insns.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
Bring the coding style up to date. No functional change (except for
removal of some pointless initializers).
Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Brian Woods <brian.woods@amd.com>
Several public header files have trailing spaces in them. This is
rather annoying when importing them into other projects as they might
be rejected not complying to coding style.
Remove the trailing spaces in all headers below xen/include/public/.
Signed-off-by: Juergen Gross <jgross@suse.com>
Acked-by: Wei Liu <wei.liu2@citrix.com>
Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
LLVM code generation can attempt to load from a variable in the next
condition of an expression under certain circumstances, thus turning
the following condition:
if ( system_state < SYS_STATE_active && opt_bootscrub == BOOTSCRUB_IDLE )
Into:
0xffff82d080223967 <+103>: cmpl $0x3,0x37b032(%rip) # 0xffff82d08059e9a0 <system_state>
0xffff82d08022396e <+110>: setb -0x29(%rbp)
0xffff82d080223972 <+114>: cmpl $0x2,0x228a8b(%rip) # 0xffff82d08044c404 <opt_bootscrub>
Such code will trigger a page fault if system_state >=
SYS_STATE_active because opt_bootscrub will be unmapped.
Fix this by making opt_bootscrub non-init, thus preventing the page
fault. The LLVM bug with the discussion about this issue can be found
at:
https://bugs.llvm.org/show_bug.cgi?id=39707
I haven't been able to find any other instances of such conditional
expression that uses system_state together with an init variable or
function.
Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
Reviewed-by: Sergey Dyasli <sergey.dyasli@citrix.com>
Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Julien Grall <julien.grall@arm.com>
Acked-by: Wei Liu <wei.liu2@citrix.com>
c/s 18596903 "xen/tools: support Python 2 and Python 3" unfortunately
introduced a TypeError when changing how Fail exceptions were printed:
/local/xen.git/xen/../xen/tools/gen-cpuid.py:Traceback (most recent call last):
File "/local/xen.git/xen/../xen/tools/gen-cpuid.py", line 483, in <module>
sys.stderr.write(e)
TypeError: expected a character buffer object
Coerce e to a string before printing. While changing this, fold the three
write() calls making up the line into a single one, and take the opportunity
to neaten the output.
A sample error is:
/local/xen.git/xen/tools/gen-cpuid.py: Fail: Aliased value between FOO and BAR
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Wei Liu <wei.liu2@citrix.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
Whilst attempting to crash an apparently wedged Windows domain using
'xen-hvmcrash' I managed to trigger the following ASSERT:
(XEN) Assertion '!vp->ptr' failed at viridian.c:607
with stack:
(XEN) [<ffff82d08032c55d>] viridian_map_guest_page+0x1b4/0x1b6
(XEN) [<ffff82d08032b1db>] viridian_synic_load_vcpu_ctxt+0x39/0x3b
(XEN) [<ffff82d08032b90d>] viridian.c#viridian_load_vcpu_ctxt+0x93/0xcc
(XEN) [<ffff82d0803096d6>] hvm_load+0x10e/0x19e
(XEN) [<ffff82d080274c6d>] arch_do_domctl+0xb74/0x25b4
(XEN) [<ffff82d0802068ab>] do_domctl+0x16f7/0x19d8
This happened because viridian_map_guest_page() was not written to cope
with being called multiple times, but this is unfortunately exactly what
happens when xen-hvmcrash re-loads the domain context (having clobbered
the values of RIP).
This patch simply makes viridian_map_guest_page() return immediately if it
finds the page already mapped (i.e. vp->ptr != NULL).
Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
Reviewed-by: Roger Pau Monné <roger.pau@citrix.com>
A top level "make build", as used e.g. by osstest, wants to build all
"all" targets in enabled tools subdirectories, which by default also
includes the emulator test harness. The use of, in particular, {evex}
insn pseudo-prefixes in, again in particular, test_x86_emulator.c causes
this build to fail though when the assembler is not new enough. Take
another big hammer and suppress the default harness build altogether
also when this and other pseudo-prefixes are not supported by the
specified (or defaulted to) assembler.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Wei Liu <wei.liu2@citrix.com>
When preparing what is now 52c37f7ab9 ("x86emul: also allow running the
32-bit harness on a 64-bit distro") I first wrongly used XEN_TARGET_ARCH
instead of XEN_COMPILE_ARCH. When realizing the mistake I forgot to also
switch around the use in the expression controlling the rule
dependencies, causing "make distclean" to fail on 64-bit distros.
Reported-by: Paul Durrant <Paul.Durrant@citrix.com>
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Tested-by: Paul Durrant <Paul.Durrant@citrix.com>
Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Wei Liu <wei.liu2@citrix.com>
The per-arch top level make files don't record any dependencies for the
file, so its mere existence is enough for make to consider it up-to-
date. As of ab3e5f5ff9 ("xsplice, symbols: Implement fast symbol names
-> virtual addresses lookup") the file, however, depends on the
FAST_SYMBOL_LOOKUP config option, which may change between incremental
re-builds.
Use the $(extra-y) machinery to get the file built without an extra
recursion step into common/, but instead right when the other things in
that directory get built. Some makefile adjustments are necessary to
actually make this machinery work beyond the restricted set of place it
was used in before. Note however that an important restriction remains:
$(extra-y) may not overlap $(obj-y) or $(obj-bin-y).
Take the opportunity and also make the gendep invocation cover both
$(obj-bin-y) and $(extra-y), even if this is not directly related here.
I should have included them right away in 8b6ef9c152 ("compat: enforce
distinguishable file names in symbol table").
Reported-by: Wei Liu <wei.liu2@citrix.com>
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Wei Liu <wei.liu2@citrix.com>
Once created there's no point re-creating them on every incremental
make. This in particular prevents them from becoming root-owned during
e.g. "sudo make install-xen", but it also allows (during development)
to replace them there (instead of in common/efi/) by actual files with
perhaps slightly changed contents.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
Make sure the MSIX MMIO regions don't have p2m entries setup, so that
accesses to them trap into the hypervisor and can be handled by vpci.
Commit 042678762 ("x86/iommu: add map-reserved dom0-iommu option to
map reserved memory ranges") added mappings for all the reserved
regions into the PVH Dom0 p2m, and some of those reserved regions
might contain MSIX MMIO regions, hence the need to make sure there are
no mappings established.
Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Ian Jackson