While we shouldn't remove its current invocation, we need to re-run it
for the case that the X86_FEATURE_TSC_RELIABLE feature flag has been
cleared, in order to avoid using the TSC rendezvous function in case
the TSC can't be written.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Joao Martins <joao.m.martins@oracle.com>
Commit c7bdecae42 ("x86/apicv: fix RTC periodic timer and apicv issue") has
added a assertion that intack.vector is the highest priority vector. But
according to the osstest, the assertion failed sometimes. More discussion can
be found in the thread
(https://lists.xenproject.org/archives/html/xen-devel/2017-01/msg01019.html).
The assertion failure is hard to reproduce. In order to root cause issue, this
patch is to add logs to dump PIR and vIRR when failure takes place. It should
be reverted once the root cause is found.
Signed-off-by: Chao Gao <chao.gao@intel.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Kevin Tian <kevin.tian@intel.com>
It turns out that GCCs 4.9.2 and 6.3.0 instantiate __scanbit() in three
translation units, but never references the result. All real uses of
__scanbit() are already suitably inline.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
libxl.c has grown to an uncomfortable size. Carve out the domain
related functions to libxl_domain.c.
Signed-off-by: Juergen Gross <jgross@suse.com>
Reviewed-by: Wei Liu <wei.liu2@citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
libxl.c has grown to an uncomfortable size. Carve out the tmem
related functions to libxl_tmem.c.
Signed-off-by: Juergen Gross <jgross@suse.com>
Reviewed-by: Wei Liu <wei.liu2@citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
libxl.c has grown to an uncomfortable size. Carve out the memory
related functions to libxl_mem.c.
Signed-off-by: Juergen Gross <jgross@suse.com>
Reviewed-by: Wei Liu <wei.liu2@citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
libxl.c has grown to an uncomfortable size. Carve out the console
related functions (including channels, keyboard and frame buffer)
to libxl_console.c.
Signed-off-by: Juergen Gross <jgross@suse.com>
Reviewed-by: Wei Liu <wei.liu2@citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
libxl.c has grown to an uncomfortable size. Carve out the disk
related functions to libxl_disk.c.
Signed-off-by: Juergen Gross <jgross@suse.com>
Reviewed-by: Wei Liu <wei.liu2@citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
libxl.c has grown to an uncomfortable size. Carve out the scheduler
related functions to libxl_sched.c.
Signed-off-by: Juergen Gross <jgross@suse.com>
Reviewed-by: Wei Liu <wei.liu2@citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
libxl.c has grown to an uncomfortable size. Carve out the cpupool
related functions to libxl_cpupool.c.
Signed-off-by: Juergen Gross <jgross@suse.com>
Reviewed-by: Wei Liu <wei.liu2@citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Splitting up libxl.c will require two functions to be globally visible.
Add their prototypes to libxl_internal.h.
Signed-off-by: Juergen Gross <jgross@suse.com>
Reviewed-by: Wei Liu <wei.liu2@citrix.com>
Commit 7603eb256 ("x86emul: use eflags definitions in x86-defns.h")
removed the EFLG_* definitions without updating the use sites (which
- oddly enough - happen to all be in 32-bit only code paths).
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Wei Liu <wei.liu2@citrix.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
50a498 failed to add a break in the p2m_mmio_direct case, so Xen was still not
adding IOMMU entries for p2m_mmio_direct regions.
Spotted by Coverity.
Reported-by: Andrew Cooper <andrew.cooper3@citrix.com>
Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
It is currently possible for the guest to lock when subscribing
to synchronous vm_events if max_vcpus is larger than the
number of available ring buffer slots. This patch no longer
blocks already paused VCPUs, fixing the issue for this use
case, and wakes up as many blocked VCPUs as there are slots
available in the ring buffer, eliminating the blockage for
asynchronous events.
Signed-off-by: Razvan Cojocaru <rcojocaru@bitdefender.com>
Acked-by: Tamas K Lengyel <tamas@tklengyel.com>
Current code in acpi_os_map_memory uses the direct map in order to map memory
in the low 1MB, but acpi_os_unmap_memory doesn't takes that into account, and
always tries to perform a vunmap, which results in the following WARN:
(XEN) Xen WARN at vmap.c:185
(XEN) ----[ Xen-4.9-unstable x86_64 debug=y Tainted: C ]----
(XEN) CPU: 0
(XEN) RIP: e008:[<ffff82d0801369d7>] vmap.c#vm_free+0xd7/0xe0
[...]
(XEN) Xen call trace:
(XEN) [<ffff82d0801369d7>] vmap.c#vm_free+0xd7/0xe0
(XEN) [<ffff82d0802bdeda>] acpi_find_root_pointer+0x3a/0x170
(XEN) [<ffff82d0802bd0ee>] acpi_os_get_root_pointer+0x4e/0x60
(XEN) [<ffff82d0802d74d0>] domain_build.c#pvh_setup_acpi_xsdt+0x90/0x240
(XEN) [<ffff82d0802d5d1a>] domain_build.c#pvh_setup_acpi+0x18a/0x2e0
(XEN) [<ffff82d0802d3ad2>] domain_build.c#construct_dom0_pvh+0xd2/0x120
(XEN) [<ffff82d0802c9174>] __start_xen+0x1d14/0x2420
(XEN) [<ffff82d080100073>] __high_start+0x53/0x60
Fix this by checking if the virtual address passed to acpi_os_unmap_memory
belongs to the direct map.
Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
The usage of the __transparent__ attribute in 991033fa introduces some issues
when compiled with clang 3.8.0:
xen/include/asm/hvm/vmx/vmx.h:605:15: error: transparent_union attribute can only be
applied to a union definition; attribute ignored [-Werror,-Wignored-attributes]
typedef union __transparent__ ept_qual {
^
xen/include/xen/compiler.h:50:44: note: expanded from macro '__transparent__'
This can be easily fixed by moving the attribute to the end of the definition,
but then the following error triggers:
xen/include/asm/hvm/vmx/vmx.h:607:5: error: size of field '' (16 bits) does not
match the size of the first field in transparent union; transparent_union attribute ignored
[-Werror,-Wignored-attributes]
struct {
^
xen/include/asm/hvm/vmx/vmx.h:606:19: note: size of first field is 64 bits
unsigned long raw;
^
Which can be fixed by introducing a new field in the nested structure that
contains the padding in order to match the size of an unsigned long.
Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
While adjusting these functions, use unsigned int rather than uint8_t for the
loop variable, and fix the whitespace style.
No functional change.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: George Dunlap <george.dunlap@citrix.com>
The original function doesn't distinguish between Valid and Invalid
VMfails. Improved function returns error code depending on the outcome:
VMsucceed: 0
VMfailValid: VM Instruction Error Number
VMfailInvalid: VMX_INSN_FAIL_INVALID (~0)
Existing users of __vmread_safe() are updated and double underscore
prefix is removed from the function's name because such prefixes are
reserved to a compiler.
Signed-off-by: Sergey Dyasli <sergey.dyasli@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Kevin Tian <kevin.tian@intel.com>
Any fail during the original __vmwrite() leads to BUG() which can be
easily exploited from a guest in the nested vmx mode.
The new function returns error code depending on the outcome:
VMsucceed: 0
VMfailValid: VM Instruction Error Number
VMfailInvalid: a new VMX_INSN_FAIL_INVALID
A new macro GAS_VMX_OP is introduced in order to improve the
readability of asm. Existing ASM_FLAG_OUT macro is reused and copied
into asm_defns.h
Signed-off-by: Sergey Dyasli <sergey.dyasli@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Kevin Tian <kevin.tian@intel.com>
Current __hvm_copy assumes that the destination memory belongs to the current
vcpu, but this is not always the case since for PVHv2 Dom0 build hvm copy
functions are used with current being the idle vcpu. Add a new vcpu parameter
to hvm copy in order to solve that. Note that only hvm_copy_to_guest_phys is
changed to take a vcpu parameter, because that's the only one at the moment
that's required in order to build a PVHv2 Dom0.
While there, also assert that the passed vcpu belongs to a HVM guest.
Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Kevin Tian <kevin.tian@intel.com>
Fix the build, retaining prior log message attributes.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
There's nothing wrong with allowing the domain to perform DMA transfers to
MMIO areas that it already can access from the CPU, and this allows us to
remove the hack in set_identity_p2m_entry for PVH Dom0.
Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Kevin Tian <kevin.tian@intel.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Acked-by: George Dunlap <george.dunlap@citrix.com>
Especially printing virtual addresses of mappings of the individual
pages seems rather useless here - this mostly obfuscates the important
numbers, and hinders comparing two printouts. Printing the page table
level indexes isn't very useful either, as the immediately following
lines will print the indexes again as part of printing the raw entries.
Take the opportunity and also
- adjust some format specifiers,
- widen (zero-pad) array indexes to their nominal width.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Kevin Tian <kevin.tian@intel.com>
c/s 11c397c broke the ARM build by introducing a common ACCESS_ONCE() which is
different to the definition in smmu.c
The SMMU code included a scalar typecheck, which is worth keeping in the
common case, given ACCESS_ONCE()'s restrictions. However, express the
typecheck differently so as to avoid Coverity complaints about unused
variables.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Signed-off-by: Stefano Stabellini <sstabellini@kernel.org>
Acked-by: Julien Grall <julien.grall@arm.com>
Commit 146786b "efi: create efi_enabled()" introduced a variable
efi_flags stored in BSS and used to pass information between the stub
and Xen. However on ARM, BSS is zeroed after the stub has finished to
run and before Xen is started. This means that the bits set in efi_flags
will be lost.
We were not affected before because all the variables used to pass
information between Xen and the stub are living in initdata or data.
Looking at the description of the field SizeOfRawData in the PE/COFF
header (see [1]):
"If this is less than VirtualSize, the remainder of the section is
zero-filled. Because the SizeOfRawData field is rounded but the
VirtualSize field is not, it is possible for SizeOfRawData to be greater
than VirtualSize as well. When a section contains only uninitialized
data, this field should be zero."
Both VirtualSize and SizeOfRawData are correctly set in the header (see
arch/arm/arm64/head.S) so the EFI firmware will zero BSS for us.
Therefore we don't need to zero BSS before running the EFI stub and can
skip the one between the EFI stub and Xen.
To avoid another branch instruction, slightly refactor the code. The
register x26 is allocated to hold whether BSS is skipped. The value will
be:
- 0 when the code is running on CPU0 and EFI is not used
- 1 when EFI is used or running on other processor than the boot one.
[1] https://msdn.microsoft.com/en-us/library/windows/desktop/ms680547(v=vs.85).aspx
Signed-off-by: Julien Grall <julien.grall@arm.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Until the IPI has completed, other processors might be running on this nested
p2m object. clear_domain_page() does not guarantee to make 8-byte atomic
updates, which means that a pagewalk on a remote processor might encounter a
partial update.
This is currently safe as other issues prevents a nested p2m ever being shared
between two cpus (although this is contrary to the original plan).
Setting p2m->np2m_base to P2M_BASE_EADDR before the IPI ensures that the IPI'd
processors won't continue to use the flushed mappings.
While modifying this function, remove all the trailing whitespace and tweak
style in the affected areas.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Tim Deegan <tim@xen.org>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
There is no need for the volatile cast in the timer interrupt; the compiler
may not elide the update. This reduces the generated assembly from a read,
local modify, write to a single add instruction.
Drop the memory barriers from timer_irq_works(), as they are not needed.
pit0_ticks is only modified by timer_interrupt() running on the same CPU, so
all that is required is a volatile reference to prevent the compiler from
eliding the second read.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Creating a domain with an invalid controller specification for a pvusb
device will currently segfault.
Avoid this by bailing out early in case of a mandatory xenstore path
not existing.
Signed-of-by: Juergen Gross <jgross@suse.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Wei Liu <wei.liu2@citrix.com>
The ept_get_*() helpers are not used consistently, and are more verbose than
the code they wrap. Drop the wrappers and use the internal union names
consistently.
While making these adjustments, drop the redundant ept_* prefix from mt, wl
and ad, and rename the asr field to mfn for consistency with Xen's existing
terminology.
No functional change.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: George Dunlap <george.dunlap@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Kevin Tian <kevin.tian@intel.com>
The "reg" variable in fuzz_read_msr stores the real MSR index, not an
index within the fuzzer.
The rest of that function already handles things correctly. We just need
to remove the bogus check.
Spotted by Coverity.
Signed-off-by: Wei Liu <wei.liu2@citrix.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
As such clearing of flags may have an impact on the selected rendezvous
function, defer the establishing of a rendezvous function other than
the initial default one (std) until after all APs have been brought up.
But don't allow such feature flags to be cleared during CPU hotplug:
Platform and local system times may have diverged significantly by
then, potentially causing noticeably (even if only temporary) strange
behavior. As we're anyway expecting only sufficiently similar CPUs to
appear during hotplug, this shouldn't be introducing new limitations.
Reported-by: Joao Martins <joao.m.martins@oracle.com>
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
... to make alloc_boot_pages() fail for late callers. Don't rely on
reaching the BOOT_BUG_ON(1) near the end of that function though, but
instead make this situation easier to distinguish from actual
allocation failures by adding an explicit check.
While there, make the iteration variable unsigned and guard against
underflow.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
Adjust/manage the return values of register_one_rmrr() such that new
callers log errors for non-debug builds too, while not affecting the
behavior of the original callers.
Signed-off-by: Venu Busireddy <venu.busireddy@oracle.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Kevin Tian <kevin.tian@intel.com>
For some MMIO regions, such as those high above RAM, mfn_valid() will
return false.
Since the fix for XSA-154 in commit c61a6f74f8 ("x86: enforce
consistent cachability of MMIO mappings"), guests have no longer been
able to use PAT to obtain write-combining on such regions because the
'ignore PAT' bit is set in EPT.
We probably want to err on the side of caution and preserve that
behaviour for addresses in mmio_ro_ranges, but not for normal MMIO
mappings. That necessitates a slight refactoring to check mfn_valid()
later, and let the MMIO case get through to the right code path.
Since we're not bailing out for !mfn_valid() immediately, the range
checks need to be adjusted to cope simply by masking in the low bits
to account for 'order' instead of adding, to avoid overflow when the mfn
is INVALID_MFN (which happens on unmap, since we carefully call this
function to fill in the EMT even though the PTE won't be valid).
The range checks are also slightly refactored to put only one of them in
the fast path in the common case. If it doesn't overlap, then it
*definitely* isn't contained, so we don't need both checks. And if it
overlaps and is only one page, then it definitely *is* contained.
Finally, add a comment clarifying how that 'return -1' works it isn't
returning an error and causing the mapping to fail; it relies on
resolve_misconfig() being able to split the mapping later. So it's
*only* sane to do it where order>0 and the 'problem' will be solved by
splitting the large page. Not for blindly returning 'error', which I was
tempted to do in my first attempt.
Signed-off-by: David Woodhouse <dwmw@amazon.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Kevin Tian <kevin.tian@intel.com>
XS_RESTRICT and the xenstore library function xs_restrict() have never
been usable in all configurations and there are no known users.
This functionality was thought to limit access rights of device models
to xenstore in order to avoid affecting other domains in case of a
security breech. Unfortunately XS_RESTRICT won't help as current
qemu is requiring access to dom0 only accessible xenstore paths to
work correctly. So this command is useless and should be removed.
In order to avoid problems in the future remove all support for
XS_RESTRICT from xenstore.
Signed-off-by: Juergen Gross <jgross@suse.com>
Reviewed-by: Wei Liu <wei.liu2@citrix.com>
Acked-by: David Scott <dave@recoil.org>
... so that users can know how big the initial input should be.
Signed-off-by: Wei Liu <wei.liu2@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Change the names used in code according to numeric values. Remove the
now unused macros in x86_emualte.c and fix indentation. This in turns
requires including msr-index.h and removing duplicates in userspace
x86_emulate.c in userspace harness program.
No functional change.
Signed-off-by: Wei Liu <wei.liu2@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>