Today when setting up a minimal domain configuration file for dom0 and
eventually xenstore-domain the domain type is harcoded as PV. Change
that by asking the hypervisor for the correct type.
Signed-off-by: Juergen Gross <jgross@suse.com>
Acked-by: Wei Liu <wei.liu2@citrix.com>
The regexp used with find in order to list the man pages doesn't work
with FreeBSD find, so use a wildcard instead. No functional change.
Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
Acked-by: Wei Liu <wei.liu2@citrix.com>
The default value of DEFCONFIG_LIST is wrong: it should be the value of
the configured ARCH_DEFCONFIG item, not the string "$ARCH_DEFCONFIG".
Signed-off-by: Juergen Gross <jgross@suse.com>
Acked-by: Wei Liu <wei.liu2@citrix.com>
Reviewed-by: Doug Goldstein <cardoe@cardoe.com>
New field backend_type is added to vkb device in order to have QEMU and user
space backend simultaneously. Each vkb backend shall read appropriate XS entry
and service only own frontends. Id is a string field which used by the backend
to indentify the frontend.
Signed-off-by: Oleksandr Grytsov <oleksandr_grytsov@epam.com>
Acked-by: Wei Liu <wei.liu2@citrix.com>
Logically it is better to move vkb to separate file as vkb device used not only
by vfb and console.
Signed-off-by: Oleksandr Grytsov <oleksandr_grytsov@epam.com>
Acked-by: Wei Liu <wei.liu2@citrix.com>
The iommu initialization will also create MMIO mappings in the Dom0
p2m, so the paging memory pool needs to be allocated or else iommu
initialization will fail.
Move the call to init the iommu after the Dom0 p2m has been setup in
order to solve this.
Note that issues caused by this wrong ordering have only been seen
when using shadow paging.
Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
If panic is called before init_idle_domain on a tboot-launched system,
then Xen recursively faults in write_ptbase as seen below.
(XEN) [<ffff82d080286690>] write_ptbase+0/0x10
(XEN) [<ffff82d0802c4c3b>] tboot_shutdown+0x6b/0x260
(XEN) [<ffff82d08029ddac>] machine_restart+0xac/0x2d0
(XEN) [<ffff82d080286690>] write_ptbase+0/0x10
(XEN) [<ffff82d0802446c1>] panic+0x111/0x120
(XEN) [<ffff82d0802a51c1>] do_general_protection+0x171/0x1f0
(XEN) [<ffff82d080287a82>] mm.c#virt_to_xen_l2e+0x12/0x1c0
(XEN) [<ffff82d080354720>] x86_64/entry.S#handle_exception_saved+0x66/0xa4
(XEN) [<ffff82d080286690>] write_ptbase+0/0x10
(XEN) [<ffff82d0802c4c3b>] tboot_shutdown+0x6b/0x260
(XEN) [<ffff82d08029ddac>] machine_restart+0xac/0x2d0
(XEN) [<ffff82d0802446c1>] panic+0x111/0x120
(XEN) [<ffff82d0803c11a0>] setup.c#bootstrap_map+0/0x11a
(XEN) [<ffff82d0803b82a0>] flask_op.c#parse_flask_param+0/0xb0
(XEN) [<ffff82d0803c11a0>] setup.c#bootstrap_map+0/0x11a
(XEN) [<ffff82d0803b6f6c>] xsm_multiboot_init+0x7c/0xb0
(XEN) [<ffff82d0803c34bb>] __start_xen+0x1d2b/0x2da0
(XEN) [<ffff82d0802000f3>] __high_start+0x53/0x60
idle_vcpu[0] is still poisoned with INVALID_VCPU, so write_ptbase faults
dereferencing the pointer. This fault calls panic and recurses through
the same code path.
If tboot_shutdown is called while idle_vcpu[0] == INVALID_VCPU, then we
are still operating with the initial page tables. Therefore changing
page tables with write_ptbase is unnecessary.
An easy way to reproduce this is to use tboot to launch an XSM-enabled
Xen without an XSM policy.
Signed-off-by: Jason Andryuk <jandryuk@gmail.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Level triggered interrupts are not an optional feature of HPET, and
must be implemented in order to comply with the HPET specification.
Implement them by adding a callback to the timer which sets the
interrupt bit in the general interrupt status register. Further
interrupts (in case of periodic mode) will not be injected until the
bit is cleared.
In order to reset the interrupts when the status bit is clear Xen must
also detect accesses to such register.
While there convert tn and i in hpet_write to unsigned.
Reported-by: Stefan Bader <stefan.bader@canonical.com>
Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Level trigger interrupts will be asserted regardless of whether the
interrupt is masked, and thus the callback will also be executed.
Add a new 'level' parameter to create_periodic_time in order to create
level triggered timers. None of the current users of vpt are switched
to use level triggered interrupts yet.
Note that periodic level triggered interrupts are not supported. This
is because level triggered interrupts always require a deassert of the
IO-APIC pin, which should be done by the caller of vpt at which point
the caller should also reset the timer if required.
Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
The calls to xpti_init_default() in parse_xpti() are buggy. The CPUID data
hasn't been fetched that early, and boot_cpu_has(X86_FEATURE_ARCH_CAPS) will
always evaluate false.
As a result, the default case won't disable XPTI on Intel hardware which
advertises ARCH_CAPABILITIES_RDCL_NO.
Simplify parse_xpti() to solely the setting of opt_xpti according to the
passed string, and have init_speculation_mitigations() call
xpti_init_default() if appropiate. Drop the force parameter, and pass caps
instead, to avoid redundant re-reading of MSR_ARCH_CAPS.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Juergen Gross <jgross@suse.com>
Reviewed-by: Wei Liu <wei.liu2@citrix.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
Because of a bug in 2010, LMSL support isn't available to guests.
c/s f2c608444 noticed but avoided fixing the issue for migration reasons. In
addition to migration problems, changes to the segmentation logic for
emulation would be needed before the feature could be enabled.
This feature is entirely unused by operating systems (probably owing to its
semantics which only cover half the segment registers), and no one has
commented on its absence from Xen. As supporting it would involve a large
amount of effort, it seems better to remove the code entirely.
If someone finds a valid usecase, we can resurrecting the code and
implementing the remaining parts, but I doubt anyone will.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Wei Liu <wei.liu2@citrix.com>
It turns out that nothing ever prevented HVM guests from trying to set unknown
EFER bits. Generally, this results in a vmentry failure.
For Intel hardware, all implemented bits are covered by the checks.
For AMD hardware, the only EFER bit which isn't covered by the checks is TCE
(which AFAICT is specific to AMD Fam15/16 hardware). We never advertise TCE
in CPUID, but it isn't a security problem to have TCE unexpected enabled in
guest context.
Disallow the setting of bits outside of the EFER_KNOWN_MASK, which prevents
any vmentry failures for guests, yielding #GP instead.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Roger Pau Monné <roger.pau@citrix.com>
Reviewed-by: Wei Liu <wei.liu2@citrix.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
Clang complains:
systemd_stubs.c:51:8: error: shifting a negative signed value is undefined [-Werror,-Wshift-negative-value]
ret = Val_int(-1U);
^~~~~~~~~~~~
Since sd_notify_fd has a signature of unit -> unit, we simply change
the return value to Val_unit.
Signed-off-by: Wei Liu <wei.liu2@citrix.com>
Acked-by: Christian Lindig <christian.lindig@citrix.com>
Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
Currently building gdbsx with clang 3.8 gives the following errors:
xg_main.c:783:17: error: 'aligned' attribute ignored when parsing type [-Werror,-Wignored-attributes]
iop->uva = (uint64_aligned_t)((unsigned long)tobuf);
^~~~~~~~~~~~~~~~
/builds/liuw/xen/tools/debugger/gdbsx/xg/../../../../tools/include/xen/arch-x86/xen-x86_32.h:105:50: note: expanded from macro 'uint64_aligned_t'
^~~~~~~~~~
xg_main.c:816:17: error: 'aligned' attribute ignored when parsing type [-Werror,-Wignored-attributes]
iop->uva = (uint64_aligned_t)((unsigned long)frombuf);
^~~~~~~~~~~~~~~~
/builds/liuw/xen/tools/debugger/gdbsx/xg/../../../../tools/include/xen/arch-x86/xen-x86_32.h:105:50: note: expanded from macro 'uint64_aligned_t'
According to https://bugs.llvm.org/show_bug.cgi?id=11071, this issue has
been fixed in clang. But we're not going to get that in 3.8.
Explicitly disable that warning to fix the build.
Signed-off-by: Wei Liu <wei.liu2@citrix.com>
Reviewed-by: Roger Pau Monné <roger.pau@citrix.com>
Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
For the hostp2m, access_required starts off as 0, then it can be
set with xc_domain_set_access_required(). However, all the altp2ms
set it to 1 on init, and ignore both the hostp2m and the hypercall.
This patch sets access_required to the value from the hostp2m
on altp2m init, and propagates the values received via hypercall
to all the active altp2ms, when applicable.
Signed-off-by: Razvan Cojocaru <rcojocaru@bitdefender.com>
Acked-by: Tamas K Lengyel <tamas@tklengyel.com>
Reviewed-by: George Dunlap <george.dunlap@citrix.com>
Acked-by: Julien Grall <julien.grall@arm.com>
This is to facilitate the values being passed in via domain_create(), at which
point the dom0 construction code needs to know them.
While cleaning up, drop the DEFAULT_* defines, which are only used immediately
adjacent in a context which makes it obvious that they are the defaults, and
drop the (unused) logic to allow a per-arch override of
DEFAULT_MAX_NR_GRANT_FRAMES.
No functional change.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
It is identical on all architecture, and this is a better overall than fixing
it up to have a proper boolean return value.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Julien Grall <julien.grall@arm.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
This adds a script that can be used to do builds easily within the
defined containers under the automation directory. These containers live
in the public GitLab registry under the xen-project namespace. The
script can be executed a number of ways but the default is to drop you
at a bash shell within a Debian Stretch container at the top level of
the source tree.
Signed-off-by: Doug Goldstein <cardoe@cardoe.com>
Acked-by: Wei Liu <wei.liu2@citrix.com>
Remove local definition of MIN and instead include the kernel.h header
for the hypervisor build. Fixes the following error on the tools build:
In file included from xc_dom_decompress_unsafe_lzma.c:8:0:
../../xen/common/unlzma.c:33:0: error: "MIN" redefined [-Werror]
#define MIN(a, b) (((a) < (b)) ? (a) : (b))
^
In file included from xc_private.h:43:0,
from xg_private.h:29,
from xc_dom_decompress_unsafe_lzma.c:5:
/home/osstest/build.125458.build-amd64/xen/stubdom/libxc-x86_64/../../tools/include/xen-tools/libs.h:21:0: note: this is the location of the previous definition
#define MIN(x, y) ((x) < (y) ? (x) : (y))
^
Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
Acked-by: Wei Liu <wei.liu2@citrix.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
If xcr0_max exceeds xfeature_mask, then something is broken with the CPUID
policy derivation or auditing logic. If hardware rejects new_bv, then
something is broken with Xen's xstate logic.
In both cases, crash the domain with an obvious error message, to help
highlight the issues.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
It turns out that Xen has never enforced that a domain remain within the
xstate features advertised in CPUID.
The check of new_bv against xfeature_mask ensures that a domain stays within
the set of features that Xen has enabled in hardware (and therefore isn't a
security problem), but this does means that attempts to level a guest for
migration safety might not be effective if the guest ignores CPUID.
Check the CPUID policy in validate_xstate() (for incoming migration) and in
handle_xsetbv() (for guest XSETBV instructions). This subsumes the PKRU check
for PV guests in handle_xsetbv() (and also demonstrates that I should have
spotted this problem while reviewing c/s fbf9971241).
For migration, this is correct despite the current (mis)ordering of data
because d->arch.cpuid is the applicable max policy.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
To facilitate the shared Xen and toolstack code in libx86, struct msr_policy
needs to be available in the same way as struct cpuid_policy.
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>
Acked-by: Jan Beulich <jbeulich@suse.com>
Move x86_cpuid_lookup_deep_deps() into the shared library, removing the
individual copies from the hypervisor and libxc respectively.
Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Wei Liu <wei.liu2@citrix.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
Both Xen and the toolstack have need of the same logic when it comes to
manipulation and checking of the CPUID and MSR values offered to guests. To
that end, libx86 is being introduced to allow Xen and the toolstack to share a
single implementation, rather than duplicating the logic.
No functional change.
Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Wei Liu <wei.liu2@citrix.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
Begin to untangle the header dependency tangle by moving definition of
struct cpuid_leaf out of x86_emulate.h into the new cpuid.h.
Additionally, plumb the header through to libxc. This is technically a
redundant include at this point, but it helps build-test the later changes,
and will be used eventually.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
Reviewed-by: Wei Liu <wei.liu2@citrix.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
c/s 4f36452b63 introduced a write to %dr6 in the #DB intercept case, but the
guests debug registers may be lazy at this point, at which point the guests
later attempt to read %dr6 will discard this value and use the older stale
value.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Roger Pau Monné <roger.pau@citrix.com>
Acked-by: Kevin Tian <kevin.tian@intel.com>
Shared resources (L1 cache and TLB in particular) present a risk of
information leak via side channels. Provide a means to avoid use of
hyperthreads in such cases.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Roger Pau Monné <roger.pau@citrix.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reportedly Intel CPUs which can't broadcast #MC to all targeted
cores/threads because some have CR4.MCE clear will shut down. Therefore
we want to keep CR4.MCE enabled when offlining a CPU, and we need to
bring up all CPUs in order to be able to set CR4.MCE in the first place.
The use of clear_in_cr4() in cpu_mcheck_disable() was ill advised
anyway, and to avoid future similar mistakes I'm removing clear_in_cr4()
altogether right here.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Roger Pau Monné <roger.pau@citrix.com>
Reviewed-by: Wei Liu <wei.liu2@citrix.com>
In order to be able to service #MC on offlined CPUs, the GDT, IDT,
stack, and per-CPU data (which includes the TSS) need to be kept
allocated. They should only be freed upon CPU removal (which we
currently don't support, so some code is becoming effectively dead for
the moment).
Note that for now park_offline_cpus doesn't get set to true anywhere -
this is going to be the subject of a subsequent patch.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Wei Liu <wei.liu2@citrix.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
Older gcc at -O2 (and perhaps higher) does not recognize that apparently
uninitialized variables aren't really uninitialized. Pull out the
assignments used by two of the three case blocks and make them
initializers of the variables, as I think I had suggested during review.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Wei Liu <wei.liu2@citrix.com>
Acked-by: Kevin Tian <kevin.tian@intel.com>
gcc-8.1 complains:
| xentop.c: In function 'print':
| xentop.c:304:4: error: 'vwprintw' is deprecated [-Werror=deprecated-declarations]
| vwprintw(stdscr, (curses_str_t)fmt, args);
| ^~~~~~~~
vw_printw (note the underscore) is a non-deprecated alternative.
Signed-off-by: Christopher Clark <christopher.clark6@baesystems.com>
Acked-by: Wei Liu <wei.liu2@citrix.com>
Fam17 replaces CUs by HTs, which we should reflect accordingly, even if
the difference is not very big. The most relevant change (requiring some
code restructuring) is that the topoext feature no longer means there is
a valid CU ID.
Take the opportunity and convert wrongly plain int variables in
set_cpu_sibling_map() to unsigned int.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Brian Woods <brian.woods@amd.com>
Reviewed-by: Roger Pau Monné <roger.pau@citrix.com>
Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
While I've run into the issue with further patches in place which no
longer guarantee the per-CPU area to start out as all zeros, the
CPU_DOWN_FAILED processing looks to have the same issue: By not zapping
the per-CPU cpupool pointer, cpupool_cpu_add()'s (indirect) invocation
of schedule_cpu_switch() will trigger the "c != old_pool" assertion
there.
Clearing the field during CPU_DOWN_PREPARE is too early (afaict this
should not happen before cpu_disable_scheduler()). Clearing it in
CPU_DEAD and CPU_DOWN_FAILED would be an option, but would take the same
piece of code twice. Since the field's value shouldn't matter while the
CPU is offline, simply clear it (implicitly) for CPU_ONLINE and
CPU_DOWN_FAILED, but only for other than the suspend/resume case (which
gets specially handled in cpupool_cpu_remove()).
By adjusting the conditional in cpupool_cpu_add() CPU_DOWN_FAILED
handling in the suspend case should now also be handled better.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Juergen Gross <jgross@suse.com>
Since the generic pattern rules don't match those, explicit rules need
to be put in place for this to work.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
It's used in quite a few places, and hence doing so eases subsequent
adjustment to how these (indirect) calls are carried out.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
This patch modifies the hvm_funcs.virtual_intr_delivery_enabled()
to become a bool variable as VMX does and SVM will simply return a
static value.
Signed-off-by: Suravee Suthikulpanit <suravee.suthikulpanit@amd.com>
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Kevin Tian <kevin.tian@intel.com>
Instead of checking hvm_tsc_scaling_supported inside the hook function,
install the hook only when setting state such that said predicate
becomes true.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Kevin Tian <kevin.tian@intel.com>
Wei Liu
Juergen Gross
Anthony PERARD
Roger Pau Monne
Oleksandr Grytsov
Jason Andryuk
Andrew Cooper
Razvan Cojocaru
Zhenzhong Duan
Doug Goldstein
Jan Beulich
Christopher Clark
Suravee Suthikulpanit