Due to a bug in the glibc headers the macros makedev(), major() and
minor() where avaialble by including sys/types.h. This bug was
addressed in glibc-2.25 by introducing a warning when these macros are
used. Since Xen is build with -Werror this new warning cause a compile
error.
Use sys/sysmacros.h to define these three macros.
blktap2 is already Linux specific. The kernel header which was used to
get makedev() does not provided it anymore, and it was wrong to use a
kernel header anyway.
Signed-off-by: Olaf Hering <olaf@aepfle.de>
Acked-by: Wei Liu <wei.liu2@citrix.com>
The previous "tools/libxc: Exposed XEN_DOMCTL_getvcpuextstate" broke
the ARM build (the hypercall does not have a corresponding DOMCTL
ARM struct). This patch fixes the build by returning -ENODEV for
ARM from xc_vcpu_get_extstate().
Signed-off-by: Razvan Cojocaru <rcojocaru@bitdefender.com>
Acked-by: Wei Liu <wei.liu2@citrix.com>
The ARM architecture allows an OS to have per-CPU page tables, as it
guarantees that TLBs never migrate from one CPU to another.
This works fine until this is done in a guest. Consider the following
scenario:
- vcpu-0 maps P to V
- vpcu-1 maps P' to V
If run on the same physical CPU, vcpu-1 can hit in TLBs generated by
vcpu-0 accesses, and access the wrong physical page.
The solution to this is to keep a per-p2m map of which vCPU ran the last
on each given pCPU and invalidate local TLBs if two vPCUs from the same
VM run on the same CPU.
Unfortunately it is not possible to allocate per-cpu variable on the
fly. So for now the size of the array is NR_CPUS, this is fine because
we still have space in the structure domain. We may want to add an
helper to allocate per-cpu variable in the future.
Signed-off-by: Julien Grall <julien.grall@arm.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
Apple's EFI drivers supply device properties which are needed to
support Macs optimally. They contain vital information which cannot be
obtained any other way (e.g. Thunderbolt Device ROM). They're also used
to convey the current device state so that OS drivers can pick up where
EFI drivers left (e.g. GPU mode setting).
Reference: Linux commit 58c5475aba67706b31d9237808d5d3d54074e5ea (see
there for the full original commit message, only the initial part of
which is being reproduced above)
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
Calls to get_fpu() were missing. Calls to put_fpu() are deliberately
not being added: Neither instruction can raise #XM, so the catch-all
_put_fpu() is just fine here.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
There seems to be some weird bug in clang 4.0 that prevents xsm_pmu_op from
working as expected, and vpmu.o ends up with a reference to
__xsm_action_mismatch_detected which makes the build fail:
[...]
ld -melf_x86_64_fbsd -T xen.lds -N prelink.o \
xen/common/symbols-dummy.o -o xen/.xen-syms.0
prelink.o: In function `xsm_default_action':
xen/include/xsm/dummy.h:80: undefined reference to `__xsm_action_mismatch_detected'
xen/xen/include/xsm/dummy.h:80: relocation truncated to fit: R_X86_64_PC32 against undefined symbol `__xsm_action_mismatch_detected'
ld: xen/xen/.xen-syms.0: hidden symbol `__xsm_action_mismatch_detected' isn't defined
Then doing a search in the objects files:
# find xen/ -type f -name '*.o' -print0 | xargs -0 bash -c \
'for filename; do nm "$filename" | \
grep -q __xsm_action_mismatch_detected && echo "$filename"; done' bash
xen/arch/x86/prelink.o
xen/arch/x86/cpu/vpmu.o
xen/arch/x86/cpu/built_in.o
xen/arch/x86/built_in.o
The current patch is the only way I've found to fix this so far, by simply
moving the XSM_PRIV check into the default case in xsm_pmu_op. This also fixes
the behavior of do_xenpmu_op, which will now return -EINVAL for unknown
XENPMU_* operations, instead of -EPERM when called by a privileged domain.
Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
Acked-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Commit 3e5f1a63b5 ("tools: adapt xenlight.pc and xlutil.pc to
new pkg-config scheme") introduced an error for "make distclean" as
*.pc.in are deleted which are now files in git.
Signed-off-by: Juergen Gross <jgross@suse.com>
Acked-by: Wei Liu <wei.liu2@citrix.com>
Recent changes to create *.pc files introduced a bug when trying to
build a library from a directory below tools as PKG_CONFIG_DIR wouldn't
be set. Correct this by adding a default value to Rules.mk.
Signed-off-by: Juergen Gross <jgross@suse.com>
Acked-by: Wei Liu <wei.liu2@citrix.com>
It's useful for an introspection tool to be able to inspect
XSAVE states. Xen already has a DOMCTL that can be used for this
purpose, but it had no public libxc wrapper. This patch adds
xc_vcpu_get_extstate().
Signed-off-by: Razvan Cojocaru <rcojocaru@bitdefender.com>
Acked-by: Wei Liu <wei.liu2@citrix.com>
Instead of generating the *.pc.in files at configure time use the new
pkg-config scheme for those files. Add the dependencies to other Xen
libraries as needed.
Signed-off-by: Juergen Gross <jgross@suse.com>
Acked-by: Wei Liu <wei.liu2@citrix.com>
In order to be able to use pkg-config for obtaining linker- and
compiler-flags provide a xenblktapctl.pc file.
Signed-off-by: Juergen Gross <jgross@suse.com>
Acked-by: Wei Liu <wei.liu2@citrix.com>
In order to be able to use pkg-config for obtaining linker- and
compiler-flags provide a xenvchan.pc file.
Signed-off-by: Juergen Gross <jgross@suse.com>
Acked-by: Wei Liu <wei.liu2@citrix.com>
In order to be able to use pkg-config for obtaining linker- and
compiler-flags provide a xenstat.pc file.
Signed-off-by: Juergen Gross <jgross@suse.com>
Acked-by: Wei Liu <wei.liu2@citrix.com>
In order to be able to use pkg-config for obtaining linker- and
compiler-flags provide a xenstore.pc file.
Signed-off-by: Juergen Gross <jgross@suse.com>
Acked-by: Wei Liu <wei.liu2@citrix.com>
In order to be able to use pkg-config for obtaining linker- and
compiler-flags provide a xenguest.pc file.
Update the xencontrol.pc file to reflect the dependencies of libxenctrl.
Signed-off-by: Juergen Gross <jgross@suse.com>
Acked-by: Wei Liu <wei.liu2@citrix.com>
In order to be able to use pkg-config for obtaining linker- and
compiler-flags provide a xendevicemodel.pc file.
Signed-off-by: Juergen Gross <jgross@suse.com>
Acked-by: Wei Liu <wei.liu2@citrix.com>
In order to be able to use pkg-config for obtaining linker- and
compiler-flags provide a xenforeignmemory.pc file.
Signed-off-by: Juergen Gross <jgross@suse.com>
Acked-by: Wei Liu <wei.liu2@citrix.com>
In order to be able to use pkg-config for obtaining linker- and
compiler-flags provide a xencall.pc file.
Signed-off-by: Juergen Gross <jgross@suse.com>
Acked-by: Wei Liu <wei.liu2@citrix.com>
In order to be able to use pkg-config for obtaining linker- and
compiler-flags provide a xengnttab.pc and a xengntshr.pc file.
Signed-off-by: Juergen Gross <jgross@suse.com>
Acked-by: Wei Liu <wei.liu2@citrix.com>
In order to be able to use pkg-config for obtaining linker- and
compiler-flags provide a xenevtchn.pc file.
Signed-off-by: Juergen Gross <jgross@suse.com>
Acked-by: Wei Liu <wei.liu2@citrix.com>
In order to be able to use pkg-config for obtaining linker- and
compiler-flags provide a xentoollog.pc file.
Signed-off-by: Juergen Gross <jgross@suse.com>
Acked-by: Wei Liu <wei.liu2@citrix.com>
Some libraries require different compiler-flags when being used in a
local build compared to a build using installed libraries.
Reflect that by supporting local cflags variables in generated
pkg-config files. The local variants will be empty in the installed
pkg-config files.
The flags for the linker in the local variants will have to specify
the search patch for the library with "-Wl,-rpath-link=", while the
flags for the installed library will be "-L".
Add needed directory patterns.
Signed-off-by: Juergen Gross <jgross@suse.com>
Acked-by: Wei Liu <wei.liu2@citrix.com>
Instead of installing $(PKG_INSTALLDIR) in multiple Makefiles below
tools, do so in tools/Makefile.
Signed-off-by: Juergen Gross <jgross@suse.com>
Acked-by: Wei Liu <wei.liu2@citrix.com>
Instead of setting the PKG_CONFIG_DIR make variable in each library
Makefile do it in tools/Makefile and stubdom/Makefile globally.
Signed-off-by: Juergen Gross <jgross@suse.com>
Acked-by: Wei Liu <wei.liu2@citrix.com>
LDLIBS_* and SHLIB_* settings in tools/Rules.mk are sometimes missing
some SHDEPS_* added to them.
Add the missing flags, even if sometimes being empty.
Signed-off-by: Juergen Gross <jgross@suse.com>
Acked-by: Wei Liu <wei.liu2@citrix.com>
Commit 78fb69ad9 ("tools/Rules.mk: Properly handle libraries with
recursive dependencies.") introduced a copy and paste error in
tools/Rules.mk:
LDLIBS_libxenstore and SHLIB_libxenstore don't use SHDEPS_libxenstore
but SHDEPS_libxenguest. This will add a superfluous dependency of
libxenstore on libxenevtchn.
Correct this bug.
Signed-off-by: Juergen Gross <jgross@suse.com>
Acked-by: Wei Liu <wei.liu2@citrix.com>
A typo was made in 7a6de259f.
Currently libxlutil lives in the same directory as libxl, fixing this
issue causes no functional change.
Signed-off-by: Wei Liu <wei.liu2@citrix.com>
Move "cannot_emulate" and make it go through the common (error) exit
path.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
Intel SDM states that if the current VMCS is a shadow VMCS,
VMFailInvalid occurs and control passes to the next instruction.
Implement such behaviour for nested vmlaunch.
Signed-off-by: Sergey Dyasli <sergey.dyasli@citrix.com>
Acked-by: Kevin Tian <kevin.tian@intel.com>
Currently xen always sets the shadow VMCS-indicator bit on nested
vmptrld and always clears it on nested vmclear. This behavior is
wrong when the guest loads a shadow VMCS: shadow bit will be lost
on nested vmclear.
Fix this by checking if the guest has provided a shadow VMCS.
Signed-off-by: Sergey Dyasli <sergey.dyasli@citrix.com>
Acked-by: Kevin Tian <kevin.tian@intel.com>
Intel SDM states that if there is a current VMCS and there is MOV-SS
blocking, VMFailValid occurs and control passes to the next instruction.
Implement such behaviour for nested vmlaunch and vmresume.
Signed-off-by: Sergey Dyasli <sergey.dyasli@citrix.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Kevin Tian <kevin.tian@intel.com>
Now that all leaves have been altered to use the guest_cpuid() path, remove
all the remaining legacy infrastructure.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Leaf 0xb is reserved by AMD, and uniformly hidden from guests by the toolstack
logic and hypervisor PV logic. The previous dynamic logic filled in the
x2APIC ID for all HVM guests.
In practice, leaf 0xb is tightly linked with x2APIC, and x2APIC is offered to
guests on AMD hardware, as Xen's APIC emulation is x2APIC capable even if
hardware isn't.
Sensibly exposing the rest of the leaf requires further topology
infrastructure.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Leaf 0xa is reserved by AMD, and only exposed to Intel guests when vPMU is
enabled. Leave the logic as-was, ready to be cleaned up when further
toolstack infrastructure is in place.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
The thermal/performance leaf was previously hidden from HVM guests, but fully
visible to PV guests. Most of the leaf refers to MSR availability, and there
is nothing an unprivileged PV guest can do with the information, so hide the
leaf entirely.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
The MONITOR flag isn't exposed to guests. The existing toolstack logic, and
pv_cpuid() in the hypervisor, zero the MONITOR leaf for queries.
However, the MONITOR leaf is still visible in the hardware domains native
CPUID view, and Linux depends on this to set up C-state information. Leak the
hosts MONITOR leaf under the same circumstances that the MONITOR feature is
leaked.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Leaf 0x4 is reserved by AMD. For Intel, it is a multi-invocation leaf with
ecx enumerating different cache details.
Add a new union for it in struct cpuid_policy, collect it from hardware in
calculate_raw_policy(), audit it in recalculate_cpuid_policy() and update
guest_cpuid() and update_domain_cpuid_info() to properly insert/extract data.
A lot of the data here will need further auditing/refinement when better
topology support is introduced, but for now, this matches the existing
toolstack behaviour.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
hap_p2m_ga_to_gfn() and sh_page_fault() currently use guest_l1e_get_gfn() to
obtain the translation of a pagewalk. This is conceptually wrong (the
semantics of gw.l1e is an internal detail), and will actually be wrong when
PSE36 superpage support is fixed. Switch them to using guest_walk_to_gfn().
guest_walk_tables() also uses guest_l1e_get_gfn(), and is updated for
consistency.
Take the opportunity to const-correct the walk_t parameter of the
guest_walk_to_*() helpers, and implement guest_walk_to_gpa() in terms of
guest_walk_to_gfn() to avoid duplicating the actual translation calculation.
While editing guest_walk_to_gpa(), fix a latent bug by causing it to return
INVALID_PADDR rather than 0 for a failed translation, as 0 is also a valid
successful result. The sole caller, sh_page_fault(), has already confirmed
that the translation is valid, so this doesn't cause a behavioural change.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Tim Deegan <tim@xen.org>
Acked-by: George Dunlap <george.dunlap@citrix.com>
All actions which refer to the active ldt/gdt/idt or task register
(e.g. loading a new segment selector) are known as implicit supervisor
accesses, even when the access originates from user code.
Right away, this fixes a bug during userspace emulation where a pagewalk for a
system table was (incorrectly) performed as a user access, causing an access
violation in the common case, as system tables reside on supervisor mappings.
The implicit/explicit distinction is necessary in the pagewalk when SMAP is
enabled. Refer to Intel SDM Vol 3 "Access Rights" for the exact details.
Introduce a new pagewalk input, and make use of the new system segment
references in hvmemul_{read,write}(). While modifying those areas, move the
calculation of the appropriate pagewalk input before its first use.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Tim Deegan <tim@xen.org>
Acked-by: George Dunlap <george.dunlap@citrix.com>
Reviewed-by: Paul Durrant <paul.durrant@citrix.com>
The way these extension spaces get handled we so far always end up
going through the generic SrcMem operand fetch path for unused table
entries. Suppress actual memory accesses happening by forcing op_bytes
to zero in those cases.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
Olaf Hering