Introduce an interface that returns a specific MSR entry from a cpu
policy in xen_msr_entry_t format. Provide a helper to perform a binary
search against an array of MSR entries.
This is useful to callers can peek data from the opaque
xc_cpu_policy_t type.
No caller of the interface introduced
Introduce an interface that returns a specific leaf/subleaf from a cpu
policy in xen_cpuid_leaf_t format.
This is useful to callers can peek data from the opaque
xc_cpu_policy_t type.
No caller of the interface introduced on this patch.
Note that callers of find_leaf need to be slightly
Also change libxl__cpuid_legacy to propagate the error from
xc_cpuid_apply_policy into callers.
Signed-off-by: Roger Pau Monné
Reviewed-by: Jan Beulich
---
Changes since v2:
- Use 'r' for xc_cpuid_apply_policy return value.
- Use LOGEVD to print error message.
Changes since v1:
- Return
, but that's to be discussed, and would be
done as a follow up series.
Thanks, Roger.
Roger Pau Monne (13):
libxl: don't ignore the return value from xc_cpuid_apply_policy
libs/guest: allow fetching a specific CPUID leaf from a cpu policy
libs/guest: allow fetching a specific MSR entry from a cpu
Remove the unneeded usage of the compat layer to copy frame pointers
from guest address space. Instead just use raw_copy_from_guest.
While there change the accessibility check of one frame_head beyond to
be performed as part of the copy, like it's done in the Linux code.
Note it's unclear why
When trying to build an hypervisor without PV or HVM (ie: using
automation/configs/x86/no_hvm_pv_config) it fails to link with:
prelink.o: In function `sh_remove_write_access_from_sl1p':
arch/x86/mm/shadow/common.c:(.text+0x72b4c): undefined reference to
`sh_rm_write_access_from_sl1p__guest_4'
Remove the unneeded usage of the compat layer to copy frame pointers
from guest address space. Instead just use raw_copy_from_guest.
While there drop the checks for the accessibility of one struct
frame_head beyond the current one: it's not clear why it's needed and
all the hypnoses point to
When restoring limit the maximum leaves to the ones supported by Xen
4.12 in order to not expand the maximum leaves a guests sees. Note
this is unlikely to cause real issues.
Guests restored from Xen versions 4.13 or greater will contain CPUID
data on the stream that will override the values set
Remove the unneeded usage of the compat layer to copy frame pointers
from guest address space. Instead just use raw_copy_from_guest.
Reported-by: Andrew Cooper
Signed-off-by: Roger Pau Monné
---
Just build tested. Note sure I'm missing something, since using the
compat layer here was IMO much
When restoring limit the maximum leaves to the ones supported by Xen
4.13 in order to not expand the maximum leaf a guests sees. Note this
is unlikely to cause real issues.
Guests restored from Xen versions 4.13 or greater will contain CPUID
data on the stream that will override the values set by
Clang reports the following build error without CONFIG_PV:
hypercall.c:253:10: error: variable 'op' is used uninitialized whenever 'if'
condition is false [-Werror,-Wsometimes-uninitialized]
if ( !is_pv_32bit_vcpu(curr) )
^~~
hypercall.c:282:21: note:
Clang complains with:
backtrace.c:46:19: error: unused function 'is_32bit_vcpu'
[-Werror,-Wunused-function]
static inline int is_32bit_vcpu(struct vcpu *vcpu)
^
Fix this by guarding the function with CONFIG_COMPAT, as it's only
caller is also doing so.
Fixes: d23d792478d
Hello,
Two clang related build fixes to get the hypervisor building again with
clang without CONFIG_PV32.
Thanks, Roger.
Roger Pau Monne (2):
x86/oprofile: fix oprofile for clang build
x86/pv: fix clang build without CONFIG_PV32
xen/arch/x86/oprofile/backtrace.c | 2 ++
xen/arch/x86/pv
There's no caller anymore that cares about the injected vector, so
drop the returned vector from the function.
No functional change indented.
Signed-off-by: Roger Pau Monné
---
Changes since v3:
- New in this version.
---
xen/arch/x86/hvm/irq.c| 8 ++--
Introduce a per virtual timer lock that replaces the existing per-vCPU
and per-domain vPT locks. Since virtual timers are no longer assigned
or migrated between vCPUs the locking can be simplified to a
in-structure spinlock that protects all the fields.
This requires introducing a helper to
There are no callers anymore passing a get_vector function pointer to
hvm_isa_irq_assert, so drop the parameter.
No functional change expected.
Signed-off-by: Roger Pau Monné
---
Changes since v3:
- New in this version.
---
xen/arch/x86/hvm/dm.c | 2 +-
xen/arch/x86/hvm/irq.c
Currently vPT relies on timers being assigned to a vCPU and performing
checks on every return to HVM guest in order to check if an interrupt
from a vPT timer assigned to the vCPU is currently being injected.
This model doesn't work properly since the interrupt destination vCPU
of a vPT timer can
No longer add vPT timers to lists on specific vCPUs, since there's no
need anymore to check if timer interrupts have been injected on return
to HVM guest.
Such change allows to get rid of virtual timers vCPU migration, and
also cleanup some of the virtual timers fields that are no longer
Switch the dpci GSI EOI callback hooks to use the newly introduced
generic callback functionality, and remove the custom dpci calls found
on the vPIC and vIO-APIC implementations.
Signed-off-by: Roger Pau Monné
---
Changes since v3:
- Print a warning message if the EOI callback cannot be
This is code movement in order to simply further changes.
No functional change intended.
Signed-off-by: Roger Pau Monné
Acked-by: Jan Beulich
---
Changes since v2:
- Drop one of the leading underscores from __hvm_dpci_eoi.
Changes since v1:
- New in this version.
---
Such callbacks will be executed once a EOI is performed by the guest,
regardless of whether the interrupts are injected from the vIO-APIC or
the vPIC, as ISA IRQs are translated to GSIs and then the
corresponding callback is executed at EOI.
The vIO-APIC infrastructure for handling EOIs is build
Switch the emulated IO-APIC code to use the local APIC EOI callback
mechanism. This allows to remove the last hardcoded callback from
vlapic_handle_EOI. Removing the hardcoded vIO-APIC callback also
allows to getting rid of setting the EOI exit bitmap based on the
triggering mode, as now all users
Remove the unconditional call to hvm_dpci_msi_eoi in vlapic_handle_EOI
and instead use the newly introduced EOI callback mechanism in order
to register a callback for MSI vectors injected from passed through
devices.
This avoids having multiple callback functions open-coded in
vlapic_handle_EOI,
Add a new vlapic_set_irq_callback helper in order to inject a vector
and set a callback to be executed when the guest performs the end of
interrupt acknowledgment.
Such functionality will be used to migrate the current ad hoc handling
done in vlapic_handle_EOI for the vectors that require some
Xen has been for a long time setting the WAET ACPI table "RTC good"
flag, which implies there's no need to perform a read of the RTC REG_C
register in order to get further interrupts after having received one.
This is hardcoded in the static ACPI tables, and in the RTC emulation
in Xen.
Drop the
:
- PVH dom0.
- Windows guest, limited to 2% capacity to test delay for missed ticks
mode - time is consistent in the guest.
- Windows guest migration.
- PCI passthrough to a guest.
Thanks, Roger.
Roger Pau Monne (12):
x86/rtc: drop code related to strict mode
x86/vlapic: introduce an EOI
AMD Milan (Zen3) CPUs have an LFENCE Always Serializing CPUID bit in
leaf 8021.eax. Previous AMD versions used to have a user settable
bit in DE_CFG MSR to select whether LFENCE was dispatch serializing,
which Xen always attempts to set. The forcefully always on setting is
due to the addition
Split the logic to attempt to setup LFENCE to be dispatch serializing
on AMD into a helper, so it can be shared with Hygon.
No functional change intended.
Signed-off-by: Roger Pau Monné
Reviewed-by: Andrew Cooper
---
Changes since v1:
- Fix typo in commit message.
---
xen/arch/x86/cpu/amd.c
Hello,
The following patches aim to add support for the LFENCE always
serializing CPUID bit found in leaf 8021.eax. In order to do that
the featureset needs to be expanded to support leaf 8021.eax.
Thanks, Roger.
Roger Pau Monne (2):
x86/amd: split LFENCE dispatch serializing setup
Milan AMD CPUs have an LFENCE Always Serializing CPUID bit in leaf
8021.eax. Previous AMD versions used to have a user settable bit
in DE_CFG MSR to select whether LFENCE was dispatch serializing, which
Xen always attempts to set.
In order to support this new CPUID bit move the
Split the logic to attempt to setup the LFENCE to be dispatch
serializing on AMD into a helper, so it can be shared with Hygon.
No functional change intended.
Signed-off-by: Roger Pau Monné
---
xen/arch/x86/cpu/amd.c | 62 ++--
xen/arch/x86/cpu/cpu.h |
Hello,
The following patches aim to add support for the LFENCE always
serializing CPUID bit found in leaf 8021.eax. In order to do that
the featureset needs to be expanded to support leaf 8021.eax.
Thanks, Roger.
Roger Pau Monne (2):
x86/amd: split LFENCE dispatch serializing setup
Further changes will rely on MSR entries being sorted, so add a test
to assert it.
Signed-off-by: Roger Pau Monné
---
Changes since v1:
- New in this version.
---
tools/tests/cpu-policy/test-cpu-policy.c | 17 +
1 file changed, 17 insertions(+)
diff --git
Move the logic from xc_cpu_policy_apply_cpuid into libxl, now that the
xc_cpu_policy_* helpers allow modifying a cpu policy. By moving such
parsing into libxl directly we can get rid of xc_xend_cpuid, as libxl
will now implement it's own private type for storing CPUID
information, which currently
Pull out the code from xc_cpuid_apply_policy that applies a featureset
to a cpu policy and place it on it's own standalone function that's
part of the public interface.
No functional change intended.
Signed-off-by: Roger Pau Monné
---
tools/include/xenctrl.h | 5 ++
Older Xen versions used to expose some CPUID bits which are no longer
exposed by default. In order to keep a compatible behavior with
guests migrated from versions of Xen that don't encode the CPUID data
on the migration stream introduce a function that sets the same bits
as older Xen versions.
With the addition of the xc_cpu_policy_* now libxl can have better
control over the cpu policy, this allows removing the
xc_cpuid_apply_policy function and instead coding the required bits by
libxl in libxl__cpuid_legacy directly.
Remove xc_cpuid_apply_policy.
Signed-off-by: Roger Pau Monné
---
Such helpers is just a wrapper to the existing
x86_cpu_policies_are_compatible function. This requires building
policy.c from libx86 on user land also.
No user of the interface introduced.
Signed-off-by: Roger Pau Monné
---
Changes since v1:
- Initialize err.
- Explicitly name parameters as
This logic is pulled out from xc_cpuid_apply_policy and placed into a
separate helper. Note the legacy part of the introduced function, as
long term Xen will require a proper topology setter function capable
of expressing a more diverse set of topologies.
No functional change intended.
Introduce a helper to update the MSR policy using an array of
xen_msr_entry_t entries. Note the MSRs present in the input
xen_msr_entry_t array will replace any existing entries on the
policy.
No user of the interface introduced on this patch.
Signed-off-by: Roger Pau Monné
---
Changes since
Rename xc_cpuid_xend_policy to xc_cpu_policy_apply_cpuid and make it
public. Modify the function internally to use the new xc_cpu_policy_*
set of functions. Also don't apply the passed policy to a domain
directly, and instead modify the provided xc_cpu_policy_t. The caller
will be responsible of
Introduce a helper to obtain a compatible cpu policy based on two
input cpu policies. Currently this is done by and'ing all CPUID leaves
and MSR entries, except for MSR_ARCH_CAPABILITIES which has the RSBA
bit or'ed.
The _AC macro is pulled from libxl_internal.h into xen-tools/libs.h
since it's
Such helper is based on the existing functions to fetch a CPUID and
MSR policies, but uses the xc_cpu_policy_t type to return the data to
the caller.
Note some helper functions are introduced, those are split from
xc_cpu_policy_get_system because they will be used by other functions
also.
No
Introduce an interface that returns a specific MSR entry from a cpu
policy in xen_msr_entry_t format. Provide a helper to perform a binary
search against an array of MSR entries.
This is useful to callers can peek data from the opaque
xc_cpu_policy_t type.
No caller of the interface introduced
Such helper is very similar to the existing xc_set_domain_cpu_policy
interface, but takes an opaque xc_cpu_policy_t instead of arrays of
CPUID leaves and MSRs.
No callers of the interface introduced in this patch.
Signed-off-by: Roger Pau Monné
---
tools/include/xenctrl.h | 2 ++
With the introduction of xc_cpu_policy_get_{system,domain} and
xc_cpu_policy_serialise the current users of
xc_get_{system,domain}_cpu_policy can be switched to the new
interface.
Note that xc_get_{system,domain}_cpu_policy is removed from the public
interface and the functions are made static,
Introduce a helper to update the CPUID policy using an array of
xen_cpuid_leaf_t entries. Note the leaves present in the input
xen_cpuid_leaf_t array will replace any existing leaves on the policy.
No user of the interface introduced on this patch.
Signed-off-by: Roger Pau Monné
---
Changes
Introduce an interface that returns a specific leaf/subleaf from a cpu
policy in xen_cpuid_leaf_t format.
This is useful to callers can peek data from the opaque
xc_cpu_policy_t type.
No caller of the interface introduced on this patch.
Note that callers of find_leaf need to be slightly
Also change libxl__cpuid_legacy to propagate the error from
xc_cpuid_apply_policy into callers.
Signed-off-by: Roger Pau Monné
Reviewed-by: Jan Beulich
---
Changes since 1:
- Return ERROR_FAIL on error.
---
tools/libs/light/libxl_cpuid.c| 15 +++
Preparatory change to introduce a new set of xc_cpu_policy_* functions
that will replace the current CPUID/MSR helpers.
No functional change intended.
Signed-off-by: Roger Pau Monné
Acked-by: Andrew Cooper
---
tools/include/xenctrl.h | 2 +-
tools/libs/guest/xg_cpuid_x86.c | 6
Introduce an opaque type that is used to store the CPUID and MSRs
policies of a domain. Such type uses the existing {cpuid,msr}_policy
structures to store the data, but doesn't expose the type to the users
of the xenguest library. There are also two arrays to allow for easier
serialization without
Such helper allow converting a cpu policy into an array of
xen_cpuid_leaf_t and xen_msr_entry_t elements, which matches the
current interface of the CPUID/MSR functions. This is required in
order for the user to be able to parse the CPUID/MSR data.
No user of the interface introduced in this
Such helper is based on the existing functions to fetch a CPUID and
MSR policies, but uses the xc_cpu_policy_t type to return the data to
the caller.
No user of the interface introduced on the patch.
Signed-off-by: Roger Pau Monné
Reviewed-by: Jan Beulich
---
Changes since v1:
- Uniformly
, but that's to be discussed, and would be
done as a follow up series.
Thanks, Roger.
Roger Pau Monne (21):
libxl: don't ignore the return value from xc_cpuid_apply_policy
libs/guest: rename xc_get_cpu_policy_size to xc_cpu_policy_get_size
libs/guest: introduce xc_cpu_policy_t
libs/guest: introduce
It's now unused after commit 28fb8cf323dd93f59a9c851c93ba9b79de8b1c4e.
Fixes: 28fb8cf323d ('x86/iommu: remove code to fetch MSI message from remap
table')
Signed-off-by: Roger Pau Monné
---
xen/include/xen/iommu.h | 1 -
1 file changed, 1 deletion(-)
diff --git a/xen/include/xen/iommu.h
The HV_X64_MSR_EOI wrmsr should always happen with the target vCPU
as current, as there's no support for EOI'ing interrupts on a remote
vCPU.
While there also turn the unconditional assert at the top of the
function into an error on non-debug builds.
No functional change intended.
Requested-by:
Currently vPT relies on timers being assigned to a vCPU and performing
checks on every return to HVM guest in order to check if an interrupt
from a vPT timer assigned to the vCPU is currently being injected.
This model doesn't work properly since the interrupt destination vCPU
of a vPT timer can
Introduce a per virtual timer lock that replaces the existing per-vCPU
and per-domain vPT locks. Since virtual timers are no longer assigned
or migrated between vCPUs the locking can be simplified to a
in-structure spinlock that protects all the fields.
This requires introducing a helper to
No longer add vPT timers to lists on specific vCPUs, since there's no
need anymore to check if timer interrupts have been injected on return
to HVM guest.
Such change allows to get rid of virtual timers vCPU migration, and
also cleanup some of the virtual timers fields that are no longer
Switch the dpci GSI EOI callback hooks to use the newly introduced
generic callback functionality, and remove the custom dpci calls found
on the vPIC and vIO-APIC implementations.
Signed-off-by: Roger Pau Monné
---
Changes since v2:
- Avoid leaking the allocated callback on error paths of
This is code movement in order to simply further changes.
No functional change intended.
Signed-off-by: Roger Pau Monné
Acked-by: Jan Beulich
---
Changes since v2:
- Drop one of the leading underscores from __hvm_dpci_eoi.
Changes since v1:
- New in this version.
---
Such callbacks will be executed once a EOI is performed by the guest,
regardless of whether the interrupts are injected from the vIO-APIC or
the vPIC, as ISA IRQs are translated to GSIs and then the
corresponding callback is executed at EOI.
The vIO-APIC infrastructure for handling EOIs is build
Switch the emulated IO-APIC code to use the local APIC EOI callback
mechanism. This allows to remove the last hardcoded callback from
vlapic_handle_EOI. Removing the hardcoded vIO-APIC callback also
allows to getting rid of setting the EOI exit bitmap based on the
triggering mode, as now all users
Remove the unconditional call to hvm_dpci_msi_eoi in vlapic_handle_EOI
and instead use the newly introduced EOI callback mechanism in order
to register a callback for MSI vectors injected from passed through
devices.
This avoids having multiple callback functions open-coded in
vlapic_handle_EOI,
Add a new vlapic_set_irq_callback helper in order to inject a vector
and set a callback to be executed when the guest performs the end of
interrupt acknowledgment.
Such functionality will be used to migrate the current ad hoc handling
done in vlapic_handle_EOI for the vectors that require some
EOIs are always executed in guest vCPU context, so there's no reason to
pass a domain parameter around as can be fetched from current->domain.
No functional change intended.
Signed-off-by: Roger Pau Monné
Reviewed-by: Paul Durrant
---
Changes since v1:
- New in this version.
---
EOIs are always executed in guest vCPU context, so there's no reason to
pass a vCPU parameter around as can be fetched from current.
While there make the vector parameter of both callbacks unsigned int.
No functional change intended.
Suggested-by: Paul Durrant
Signed-off-by: Roger Pau Monné
:
- PVH dom0.
- Windows guest, limited to 2% capacity to test delay for missed ticks
mode - time is consistent in the guest.
- Windows guest migration.
- PCI passthrough to a guest.
Thanks, Roger.
Roger Pau Monne (11):
x86/hvm: drop vcpu parameter from vlapic EOI callbacks
x86/hvm: drop
The change to deny all accesses to MSRs indexes not explicitly handled
prevents leaking unwanted data into guests.
Signed-off-by: Roger Pau Monné
---
CHANGELOG.md | 1 +
1 file changed, 1 insertion(+)
diff --git a/CHANGELOG.md b/CHANGELOG.md
index f76fadf8c73..d81608af4de 100644
---
Use the value read from the REVID register in order to check for the
presence of the device. A read of all ones is treated as if the device
is not present, and hence probing is ended.
This fixes an issue when running as a Xen PVH dom0, where the ACPI
DSDT table is provided unmodified to dom0 and
When parsing the capability list make sure the offset is between the
MMIO region mapped in 'regs', or else the kernel hits a page fault.
Adding the check is harmless, and prevents buggy or broken systems
from crashing the kernel if the capability linked list is somehow
broken.
Fixes:
Use the value read from the REVID register in order to check for the
presence of the device. A read of all ones is treated as if the device
is not present, and hence probing is ended.
This fixes an issue when running as a Xen PVH dom0, where the ACPI
DSDT table is provided unmodified to dom0 and
Hello,
The following series adds some consistency checks to the values returned
by some of the MMIO registers of the Intel pinctrl device.
That done to avoid a crash when running as a PVH dom0. See patch #1 for
more details.
Thanks, Roger.
Roger Pau Monne (2):
intel/pinctrl: check REVID
When parsing the capability list make sure the offset is between the
MMIO region mapped in 'regs', or else the kernel hits a page fault.
This fault has been seen when running as a Xen PVH dom0, which doesn't
have the MMIO regions mapped into the domain physical memory map,
despite having the
The Xen memory hotplug limit should depend on the memory hotplug
generic option, rather than the Xen balloon configuration. It's
possible to have a kernel with generic memory hotplug enabled, but
without Xen balloon enabled, at which point memory hotplug won't work
correctly due to the size
XEN_BALLOON_MEMORY_HOTPLUG is disabled
with XEN_UNPOPULATED_ALLOC.
Thanks, Roger.
Roger Pau Monne (2):
xen/x86: make XEN_BALLOON_MEMORY_HOTPLUG_LIMIT depend on
MEMORY_HOTPLUG
Revert "xen: fix p2m size in dom0 for disabled memory hotplug case"
arch/x86/include/asm/xen/page.h | 12
ar
This partially reverts commit 882213990d32fd224340a4533f6318dd152be4b2.
There's no need to special case XEN_UNPOPULATED_ALLOC anymore in order
to correctly size the p2m. The generic memory hotplug option has
already been tied together with the Xen hotplug limit, so enabling
memory hotplug should
When parsing the capability list make sure the offset is between the
MMIO region mapped in 'regs', or else the kernel hits a page fault.
This fault has been seen when running as a Xen PVH dom0, which doesn't
have the MMIO regions mapped into the domain physical memory map,
despite having the
epte_get_entry_emt will only be called for HVM domains, so the
is_hvm_domain check is unnecessary. It's a remnant of PVHv1.
Shouldn't result in any functional change.
Signed-off-by: Roger Pau Monné
---
xen/arch/x86/hvm/mtrr.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff
Introduce a helper to update the CPUID policy using an array of
xen_cpuid_leaf_t entries. Note the leaves present in the input
xen_cpuid_leaf_t array will replace any existing leaves on the policy.
No user of the interface introduced on this patch.
Signed-off-by: Roger Pau Monné
---
Move the logic from xc_cpu_policy_apply_cpuid into libxl, now that the
xc_cpu_policy_* helpers allow modifying a cpu policy. Having xenguest
parsing CPUID data in xend format was a layering violation, and by
moving such parsing into libxl directly we can get rid of
xc_xend_cpuid, as libxl will now
With the introduction of xc_cpu_policy_get_{system,domain} and
xc_cpu_policy_serialise the current users of
xc_get_{system,domain}_cpu_policy can be switched to the new
interface.
Note that xc_get_{system,domain}_cpu_policy is removed from the public
interface and the functions are made static,
Introduce a helper to update the MSR policy using an array of
xen_msr_entry_t entries. Note the MSRs present in the input
xen_msr_entry_t array will replace any existing entries on the
policy.
No user of the interface introduced on this patch.
Signed-off-by: Roger Pau Monné
---
To use the new cpu policy interface xc_cpu_policy_set_domain. Note
that xc_set_domain_cpu_policy is removed from the interface and the
function is made static to xg_cpuid_x86.c for it's internal callers.
Signed-off-by: Roger Pau Monné
---
tools/include/xenctrl.h | 5 -
With the addition of the xc_cpu_policy_* now libxl can have better
control over the cpu policy, this allows removing the
xc_cpuid_apply_policy function and instead coding the required bits by
libxl in libxl__cpuid_legacy directly.
Remove xc_cpuid_apply_policy.
Signed-off-by: Roger Pau Monné
---
This logic is pulled out from xc_cpuid_apply_policy and placed into a
separate helper.
No functional change intended.
Signed-off-by: Roger Pau Monné
---
tools/include/xenctrl.h | 4 +
tools/libs/guest/xg_cpuid_x86.c | 181 +---
2 files changed, 102
Pull out the code from xc_cpuid_apply_policy that applies a featureset
to a cpu policy and place it on it's own standalone function that's
part of the public interface.
No functional change intended.
Signed-off-by: Roger Pau Monné
---
tools/include/xenctrl.h | 5 ++
Rename xc_cpuid_xend_policy to xc_cpu_policy_apply_cpuid and make it
public. Modify the function internally to use the new xc_cpu_policy_*
set of functions. Also don't apply the passed policy to a domain
directly, and instead modify the provided xc_cpu_policy_t. The caller
will be responsible of
Older Xen versions used to expose some CPUID bits which are no longer
exposed by default. In order to keep a compatible behavior with
guests migrated from versions of Xen that don't encode the CPUID data
on the migration stream introduce a function that sets the same bits
as older Xen versions.
Introduce a helper to obtain a compatible cpu policy based on two
input cpu policies. Currently this is done by and'ing all CPUID leaves
and MSR entries, except for MSR_ARCH_CAPABILITIES which has the RSBA
bit or'ed.
The _AC macro is pulled from libxl_internal.h into xen-tools/libs.h
since it's
Such helpers is just a wrapper to the existing
x86_cpu_policies_are_compatible function. This requires building
policy.c from libx86 on user land also.
No user of the interface introduced.
Signed-off-by: Roger Pau Monné
---
tools/include/xenctrl.h | 4
tools/libs/guest/Makefile
Introduce an interface that returns a specific MSR entry from a cpu
policy in xen_msr_entry_t format.
This is useful to callers can peek data from the opaque
xc_cpu_policy_t type.
No caller of the interface introduced on this patch.
Signed-off-by: Roger Pau Monné
---
tools/include/xenctrl.h
Introduce an interface that returns a specific leaf/subleaf from a cpu
policy in xen_cpuid_leaf_t format.
This is useful to callers can peek data from the opaque
xc_cpu_policy_t type.
No caller of the interface introduced on this patch.
Signed-off-by: Roger Pau Monné
---
Such helper is very similar to the existing xc_set_domain_cpu_policy
interface, but takes an opaque xc_cpu_policy_t instead of arrays of
CPUID leaves and MSRs.
No callers of the interface introduced in this patch.
Signed-off-by: Roger Pau Monné
---
tools/include/xenctrl.h | 2 ++
Such helper allow converting a cpu policy into an array of
xen_cpuid_leaf_t and xen_msr_entry_t elements, which matches the
current interface of the CPUID/MSR functions. This is required in
order for the user to be able to parse the CPUID/MSR data.
No user of the interface introduced in this
Preparatory change to introduce a new set of xc_cpu_policy_* functions
that will replace the current CPUID/MSR helpers.
No functional change intended.
Signed-off-by: Roger Pau Monné
---
tools/include/xenctrl.h | 2 +-
tools/libs/guest/xg_cpuid_x86.c | 6 +++---
Such helper is based on the existing functions to fetch a CPUID and
MSR policies, but uses the xc_cpu_policy_t type to return the data to
the caller.
No user of the interface introduced on the patch.
Signed-off-by: Roger Pau Monné
---
tools/include/xenctrl.h | 2 ++
Such helper is based on the existing functions to fetch a CPUID and
MSR policies, but uses the xc_cpu_policy_t type to return the data to
the caller.
Note some helper functions are introduced, those are split from
xc_cpu_policy_get_system because they will be used by other functions
also.
No
Introduce an opaque type that is used to store the CPUID and MSRs
policies of a domain. Such type uses the existing cpu_policy structure
to store the data, but doesn't expose the type to the users of the
xenguest library.
Introduce an allocation (init) and freeing function (destroy) to
manage the
, uint32_t *featureset);
We might want to rename those to also use the xc_cpu_* prefix at least?
Using xc_cpu_policy_* would be wrong here IMO, as such functions don't
use the newly introduced xc_cpu_policy_t object.
Thanks, Roger.
Roger Pau Monne (21):
libxl: don't ignore the return value from
801 - 900 of 2071 matches
Mail list logo
