The TLB clock is helpful when running Xen on bare metal because when
doing a TLB flush each CPU is IPI'ed and can keep a timestamp of the
last flush.
This is not the case however when Xen is running virtualized, and the
underlying hypervisor provides mechanism to assist in performing TLB
flushes:
Use Xen's L0 HVMOP_flush_tlbs hypercall in order to perform flushes.
This greatly increases the performance of TLB flushes when running
with a high amount of vCPUs as a Xen guest, and is specially important
when running in shim mode.
The following figures are from a PV guest running `make -j32 xen
Check if hosts have SMT based on the number of threads per core. A
value of threads per core different than 0 implies SMT support.
Signed-off-by: Roger Pau Monné
---
sg-run-job | 1 +
ts-examine-cpu | 32
2 files changed, 33 insertions(+)
create mode 100755
Run a simple core scheduling tests on a host that has SMT support.
This is only enabled for Xen >= 4.13.
The runvar difference is:
+test-amd64-coresched-amd64-xl all_host_di_version 2020-02-10
+test-amd64-coresched-i386-xl all_host_di_version 2020-02-10
+test-amd64-coresched-amd64-xl all_host_su
Check if hosts have SMT based on the number of threads per core. A
value of threads per core greater than 1 implies SMT support.
Signed-off-by: Roger Pau Monné
---
Changes since v1:
- Fix regex and set SMT if number of threads per core is > 1.
---
sg-run-job | 1 +
ts-examine-cpu | 32
Add a missing break in the HVMOP_altp2m_set_visibility case, or else
code flow will continue into the default case and trigger the assert.
Fixes: 3fd3e9303ec4b1 ('x86/altp2m: hypercall to set altp2m view visibility')
Coverity-ID: 1461759
Signed-off-by: Roger Pau Monné
---
xen/arch/x86/hvm/hvm.c
Check if hosts have SMT based on the number of threads per core. A
value of threads per core greater than 1 implies SMT support.
Signed-off-by: Roger Pau Monné
---
Changes since v2:
- Use hw-smt.
Changes since v1:
- Fix regex and set SMT if number of threads per core is > 1.
---
sg-run-job
Run a simple core scheduling tests on a host that has SMT support.
This is only enabled for Xen >= 4.13.
The runvar difference is:
+test-amd64-coresched-amd64-xl all_host_di_version 2020-02-10
+test-amd64-coresched-i386-xl all_host_di_version 2020-02-10
+test-amd64-coresched-amd64-xl all_host_su
Use Xen's L0 HVMOP_flush_tlbs hypercall in order to perform flushes.
This greatly increases the performance of TLB flushes when running
with a high amount of vCPUs as a Xen guest, and is specially important
when running in shim mode.
The following figures are from a PV guest running `make -j32 xen
Introduce a specific flag to request a HVM guest linear TLB flush,
which is an ASID/VPID tickle that forces a guest linear to guest
physical TLB flush for all HVM guests.
This was previously unconditionally done in each pre_flush call, but
that's not required: HVM guests not using shadow don't req
The TLB clock is helpful when running Xen on bare metal because when
doing a TLB flush each CPU is IPI'ed and can keep a timestamp of the
last flush.
This is not the case however when Xen is running virtualized, and the
underlying hypervisor provides mechanism to assist in performing TLB
flushes:
Hello,
This is the remaining of the assisted TLB flush series. This last set of
patches enable the usage of the Xen assisted flush when running nested
on Xen.
Thanks, Roger.
Roger Pau Monne (3):
x86/tlb: introduce a flush HVM ASIDs flag
x86/tlb: allow disabling the TLB clock
x86/tlb: use
The EPT page tables can be shared with the IOMMU as long as the page
sizes supported by EPT are also supported by the IOMMU.
Current code checks that both the IOMMU and EPT support the same page
sizes, but this is not strictly required, the IOMMU supporting more
page sizes than EPT is fine and sho
The EPT page tables can be shared with the IOMMU as long as the page
sizes supported by EPT are also supported by the IOMMU.
Current code checks that both the IOMMU and EPT support the same page
sizes, but this is not strictly required, the IOMMU supporting more
page sizes than EPT is fine and sho
The way to fetch the number of threads from the output of xl info is
wrong, as the result of =~ is either true or false, but will never be a
numeric value.
Fix the regex to have a capture group in order to fetch the number of
threads, and store the capture in the threads variable.
Signed-off-by:
Hello,
This is the remaining of the assisted TLB flush series. This last set of
patches enable the usage of the Xen assisted flush when running nested
on Xen.
Thanks, Roger.
Roger Pau Monne (3):
x86/tlb: introduce a flush HVM ASIDs flag
x86/tlb: allow disabling the TLB clock
x86/tlb: use
Use Xen's L0 HVMOP_flush_tlbs hypercall in order to perform flushes.
This greatly increases the performance of TLB flushes when running
with a high amount of vCPUs as a Xen guest, and is specially important
when running in shim mode.
The following figures are from a PV guest running `make -j32 xen
The TLB clock is helpful when running Xen on bare metal because when
doing a TLB flush each CPU is IPI'ed and can keep a timestamp of the
last flush.
This is not the case however when Xen is running virtualized, and the
underlying hypervisor provides mechanism to assist in performing TLB
flushes:
Introduce a specific flag to request a HVM guest linear TLB flush,
which is an ASID/VPID tickle that forces a guest linear to guest
physical TLB flush for all HVM guests.
This was previously unconditionally done in each pre_flush call, but
that's not required: HVM guests not using shadow don't req
When doing an assisted flush on HAP the purpose of the
on_selected_cpus is just to trigger a vmexit on remote CPUs that are
in guest context, and hence just using is_vcpu_dirty_cpu is too lax,
also check that the vCPU is running.
While there also pass NULL as the data parameter of on_selected_cpus
Improve the assisted flush by expanding the interface and allowing for
more fine grained TLB flushes to be issued using the HVMOP_flush_tlbs
hypercall. Support for such advanced flushes is signaled in CPUID
using the XEN_HVM_CPUID_ADVANCED_FLUSH flag.
The new features make use of the NULL paramete
has_igd_gfx_passthru is only available when QEMU is built with
CONFIG_XEN_PCI_PASSTHROUGH, and hence shouldn't be used in common
code without checking if it's available.
Fixes: 46472d82322d0 ('xen: convert "-machine igd-passthru" to an accelerator
property')
Signed-off-by: Roger Pau Monné
---
Cc
PVHv1 dom0 was given access to all PHYSDEVOP hypercalls, and such
restriction was not removed when PVHv1 code was removed. As a result
the switch in hvm_physdev_op was more complicated than required, and
relied on PVHv2 dom0 not having PIRQ support in order to prevent
access to some PV specific PHY
Clang 10 complains with:
13: error: misleading indentation; statement is not part of the previous 'if'
[-Werror,-Wmisleading-indentation]
if ( ! yyg->yy_state_buf )
^
libxlu_disk_l.c:1259:9: note: previous statement is here
if ( ! yyg->yy_state_buf )
^
The path provided by EXTRA_PREFIX should be added to the search path
of the configure script, like it's done in Config.mk. Not doing so
makes the search path for configure differ from the search path used
by the build.
Signed-off-by: Roger Pau Monné
---
Please re-run autoconf.sh after applying.
-
Hello,
Patches 1 and 3 are fixes in order to build Xen with Clang 10. Patch 2
is a fix for a configure bug I've found while attempting to fix Clang
10.
Thanks, Roger.
Roger Pau Monne (3):
x86/mm: do not attempt to convert _PAGE_GNTTAB to a boolean
configure: also add EXTRA_PREFIX to {C
Clang 10 complains with:
mm.c:1239:10: error: converting the result of '<<' to a boolean always
evaluates to true
[-Werror,-Wtautological-constant-compare]
if ( _PAGE_GNTTAB && (l1e_get_flags(l1e) & _PAGE_GNTTAB) &&
^
xen/include/asm/x86_64/page.h:161:25: note: expanded from ma
The aim of this patch is to make it easier to digest the output of the
gitlab jobs, as the current is IMO too long and that makes it hard to
spot what went wrong. So this patch does the following:
- Rename build.log into run.log.
- Split each build log into a logs folder, using the
build{-kcon
Apply a workaround for Intel errata CLX30: "A Pending Fixed Interrupt
May Be Dispatched Before an Interrupt of The Same Priority Completes".
It's not clear which models are affected, as the errata is listed in
the "Second Generation Intel Xeon Scalable Processors" specification
update, but the iss
Apply a workaround for Intel errata CLX30: "A Pending Fixed Interrupt
May Be Dispatched Before an Interrupt of The Same Priority Completes".
It's not clear which models are affected, as the errata is listed in
the "Second Generation Intel Xeon Scalable Processors" specification
update, but the iss
Remove the eax and cstate local variables, the same can be directly
fetched from acpi_processor_cx without any transformations.
No functional change.
Signed-off-by: Roger Pau Monné
---
xen/arch/x86/cpu/mwait-idle.c | 11 ---
1 file changed, 4 insertions(+), 7 deletions(-)
diff --git a/
Add entries for the relevant changes I've been working on during the
4.14 development time frame. Mostly performance improvements related
to pvshim scalability issues when running with high number of vCPUs.
Signed-off-by: Roger Pau Monné
---
CHANGELOG.md | 6 ++
1 file changed, 6 insertions(
Apply a workaround in order to cope with the BDX99, CLX30, SKX100,
CFW125, BDF104, BDH85, BDM135, KWB131 erratas.
Roger Pau Monne (2):
x86/idle: rework C6 EOI workaround
x86/idle: prevent entering C6 with in service interrupts on Intel
docs/misc/xen-command-line.pandoc | 9
xen/arch
Change the C6 EOI workaround (errata AAJ72) to use x86_match_cpu. Also
call the workaround from mwait_idle, previously it was only used by
the ACPI idle driver. Finally make sure the routine is called for all
states equal or greater than ACPI_STATE_C3, note that the ACPI driver
doesn't currently ha
Apply a workaround for Intel errata BDX99, CLX30, SKX100, CFW125,
BDF104, BDH85, BDM135, KWB131: "A Pending Fixed Interrupt May Be
Dispatched Before an Interrupt of The Same Priority Completes".
Apply the errata to all server and client models (big cores) from
Broadwell to Cascade Lake. The workar
has_igd_gfx_passthru is only available when QEMU is built with
CONFIG_XEN_PCI_PASSTHROUGH, and hence shouldn't be used in common
code without checking if it's available.
Fixes: 46472d82322d0 ('xen: convert "-machine igd-passthru" to an accelerator
property')
Signed-off-by: Roger Pau Monné
---
Cc
Apply a workaround for Intel errata BDX99, CLX30, SKX100, CFW125,
BDF104, BDH85, BDM135, KWB131: "A Pending Fixed Interrupt May Be
Dispatched Before an Interrupt of The Same Priority Completes".
Apply the errata to all server and client models (big cores) from
Broadwell to Cascade Lake. The workar
The TLB clock is helpful when running Xen on bare metal because when
doing a TLB flush each CPU is IPI'ed and can keep a timestamp of the
last flush.
This is not the case however when Xen is running virtualized, and the
underlying hypervisor provides mechanism to assist in performing TLB
flushes:
The current implementation of the hypervisor assisted flush for HAP is
extremely inefficient.
First of all there's no need to call paging_update_cr3, as the only
relevant part of that function when doing a flush is the ASID vCPU
flush, so just call that function directly.
Since hvm_asid_flush_vcp
Current implementation of hvm_asid_flush_vcpu is not safe to use
unless the target vCPU is either paused or the currently running one,
as it modifies the generation without any locking.
Fix this by using atomic operations when accessing the generation
field, both in hvm_asid_flush_vcpu_asid and ot
Introduce a specific flag to request a HVM guest TLB flush, which is
an ASID/VPID tickle that forces a linear TLB flush for all HVM guests.
This was previously unconditionally done in each pre_flush call, but
that's not required: HVM guests not using shadow don't require linear
TLB flushes as Xen
reference on the performance improvement see patch #7, as it's a
huge increase which can benefit other guests using assisted TLB flushes,
and also the ones using the viridian TLB flush assist (ie: Windows).
Thanks, Roger.
Roger Pau Monne (7):
x86/hvm: allow ASID flush when v != current
Use Xen's L0 HVMOP_flush_tlbs hypercall in order to perform flushes.
This greatly increases the performance of TLB flushes when running
with a high amount of vCPUs as a Xen guest, and is specially important
when running in shim mode.
The following figures are from a PV guest running `make -j32 xen
Add shadow and hap implementation specific helpers to perform guest
TLB flushes. Note that the code for both is exactly the same at the
moment, and is copied from hvm_flush_vcpu_tlb. This will be changed by
further patches that will add implementation specific optimizations to
them.
No functional
Adapt the hypervisor ops framework so it can be used with the
alternative calls framework. So far no hooks are modified to make use
of the alternatives patching, as they are not in any hot path.
No functional change intended.
Signed-off-by: Roger Pau Monné
---
Changes since v3:
- New in this ve
Current usage of the per-CPU scratch cpumask is dangerous since
there's no way to figure out if the mask is already being used except
for manual code inspection of all the callers and possible call paths.
This is unsafe and not reliable, so introduce a minimal get/put
infrastructure to prevent nes
. Patch #2 is a fix for that usage.
Patch #3 adds some debug infrastructure to make sure the scratch cpumask
is used in the right context, and hence should prevent further missuses.
Thanks, Roger.
Roger Pau Monne (3):
x86/smp: unify header includes in smp.h
x86/smp: use a dedicated scratch cpumask
Unify the two adjacent header includes that are both gated with ifndef
__ASSEMBLY__.
No functional change intended.
Signed-off-by: Roger Pau Monné
---
xen/include/asm-x86/smp.h | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/xen/include/asm-x86/smp.h b/xen/include/asm-x8
Using scratch_cpumask in send_IPI_mak is not safe because it can be
called from interrupt context, and hence Xen would have to make sure
all the users of the scratch cpumask disable interrupts while using
it.
Instead introduce a new cpumask to be used by send_IPI_mask, and
disable interrupts while
Don't allow cpu_hotplug_begin to fail by converting the trylock into a
blocking lock acquisition. Write users of the cpu_add_remove_lock are
limited to CPU plug/unplug operations, and cannot deadlock between
themselves or other users taking the lock in read mode as
cpu_add_remove_lock is always loc
done to reduce the failure of the CPU plug/unplug operations,
since the lock is more contended now and trylock can easily fail if
there are readers.
Thanks, Roger.
Roger Pau Monne (2):
smp: convert the cpu maps lock into a rw lock
smp: convert cpu_hotplug_begin into a blocking lock acquisition
Most users of the cpu maps just care about the maps not changing while
the lock is being held, but don't actually modify the maps.
Convert the lock into a rw lock, and take the lock in read mode in
get_cpu_maps and in write mode in cpu_hotplug_begin. This will lower
the contention around the lock,
Hello,
Current nested VMX code advertises support for the MSR bitmap feature,
yet the implementation isn't done. Previous to this series Xen just maps
the nested guest MSR bitmap (as set by L1) and that's it, the L2 guest
ends up using the L1 MSR bitmap.
This series adds handling of the L2 MSR bi
Import the functions and it's dependencies. Based on Linux 5.5, commit
id d5226fa6dbae0569ee43ecfc08bdcd6770fc4755.
Signed-off-by: Roger Pau Monné
---
Changes since v4:
- Introduce BIT_WORD in generic header bitops.h (instead of the x86
one).
- Include byteorder.h for __LITTLE_ENDIAN
- Remo
Current implementation of nested VMX has a half baked handling of MSR
bitmaps for the L1 VMM: it maps the L1 VMM provided MSR bitmap, but
doesn't actually load it into the nested vmcs, and thus the nested
guest vmcs ends up using the same MSR bitmap as the L1 VMM.
This is wrong as there's no assur
Nested VMX doesn't expose support for
SECONDARY_EXEC_VIRTUALIZE_X2APIC_MODE,
SECONDARY_EXEC_VIRTUAL_INTR_DELIVERY or
SECONDARY_EXEC_APIC_REGISTER_VIRT, and hence the x2APIC MSRs should
always be trapped in the nested guest MSR bitmap, or else a nested
guest could access the hardware x2APIC MSRs giv
So BIT_WORD can be imported from Linux. The difference between current
Linux implementation of BIT_WORD is that the size of the word unit is
a long integer, while the Xen one is hardcoded to 32 bits.
Current users of BITOP_WORD on Arm (which considers a word a long
integer) are switched to use the
Current usage of the per-CPU scratch cpumask is dangerous since
there's no way to figure out if the mask is already being used except
for manual code inspection of all the callers and possible call paths.
This is unsafe and not reliable, so introduce a minimal get/put
infrastructure to prevent nes
This is modeled after the irq_count variable, and is used to account
for all the NMIs handled by the system.
This will allow to repurpose the nmi_count() helper so it can be used
in a similar manner as local_irq_count(): account for the NMIs
currently in service.
Signed-off-by: Roger Pau Monné
-
Add helpers to track when running in #MC context. This is modeled
after the in_irq helpers, but does not support reentry.
Note that there are no users of in_mc() introduced by the change,
further users will be added by followup changes.
Signed-off-by: Roger Pau Monné
---
xen/arch/x86/traps.c
Using scratch_cpumask in send_IPI_mak is not safe because it can be
called from interrupt context, and hence Xen would have to make sure
all the users of the scratch cpumask disable interrupts while using
it.
Instead introduce a new cpumask to be used by send_IPI_mask, and
disable interrupts while
hence should prevent further missuses.
Thanks, Roger.
Roger Pau Monne (6):
x86/smp: unify header includes in smp.h
x86: introduce a nmi_count tracking variable
x86: track when in #MC context
x86: track when in #NMI context
x86/smp: use a dedicated scratch cpumask in send_IPI_mask
x86
Unify the two adjacent header includes that are both gated with ifndef
__ASSEMBLY__.
No functional change intended.
Signed-off-by: Roger Pau Monné
Reviewed-by: Wei Liu
Acked-by: Jan Beulich
---
xen/include/asm-x86/smp.h | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/x
Add helpers to track when executing in #MC context. This is modeled
after the in_irq helpers.
Note that there are no users of in_mc() introduced by the change,
further users will be added by followup changes.
Signed-off-by: Roger Pau Monné
---
xen/arch/x86/cpu/mcheck/mce.c | 2 ++
xen/include/a
Nested VMX doesn't expose support for
SECONDARY_EXEC_VIRTUALIZE_X2APIC_MODE,
SECONDARY_EXEC_VIRTUAL_INTR_DELIVERY or
SECONDARY_EXEC_APIC_REGISTER_VIRT, and hence the x2APIC MSRs should
always be trapped in the nested guest MSR bitmap, or else a nested
guest could access the hardware x2APIC MSRs giv
Import the functions and it's dependencies. Based on Linux 5.5, commit
id d5226fa6dbae0569ee43ecfc08bdcd6770fc4755.
Signed-off-by: Roger Pau Monné
Acked-by: Jan Beulich
---
Changes since v4:
- Introduce BIT_WORD in generic header bitops.h (instead of the x86
one).
- Include byteorder.h for
So BIT_WORD can be imported from Linux. The difference between current
Linux implementation of BIT_WORD is that the size of the word unit is
a long integer, while the Xen one is hardcoded to 32 bits.
Current users of BITOP_WORD on Arm (which considers a word a long
integer) are switched to use the
Hello,
Patch #3 makes sure the x2APIC MSR range is always trapped, or else a
guest with nested virtualization enabled could manage to access some of
the x2APIC MSR registers from the host. Previous patches are preparatory
patches in order to import bitmap_{set/clear}.
Thanks, Roger.
Roger Pau
Reported-by: Coverity
CID: 1458632
Fixes: 709d3ddea2d5e ('AMD/IOMMU: Common the #732/#733 errata handling in
iommu_read_log()')
Signed-off-by: Roger Pau Monné
---
xen/drivers/passthrough/amd/iommu_init.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/xen/drivers/passthrough/amd/iommu_init.c
Current implementation of hvm_asid_flush_vcpu is not safe to use
unless the target vCPU is either paused or the currently running one,
as it modifies the generation without any locking.
Fix this by using atomic operations when accessing the generation
field, both in hvm_asid_flush_vcpu_asid and ot
The TLB clock is helpful when running Xen on bare metal because when
doing a TLB flush each CPU is IPI'ed and can keep a timestamp of the
last flush.
This is not the case however when Xen is running virtualized, and the
underlying hypervisor provides mechanism to assist in performing TLB
flushes:
v4 is a fix to extract the order from the flags field in patch
#7.
Thanks, Roger.
Roger Pau Monne (7):
x86/hvm: allow ASID flush when v != current
x86/paging: add TLB flush hooks
x86/hap: improve hypervisor assisted guest TLB flush
x86/tlb: introduce a flush guests TLB flag
x86/tlb: allow di
The current implementation of the hypervisor assisted flush for HAP is
extremely inefficient.
First of all there's no need to call paging_update_cr3, as the only
relevant part of that function when doing a flush is the ASID vCPU
flush, so just call that function directly.
Since hvm_asid_flush_vcp
Adapt the hypervisor ops framework so it can be used with the
alternative calls framework. So far no hooks are modified to make use
of the alternatives patching, as they are not in any hot path.
No functional change intended.
Signed-off-by: Roger Pau Monné
Reviewed-by: Wei Liu
Reviewed-by: Paul
Use Xen's L0 HVMOP_flush_tlbs hypercall in order to perform flushes.
This greatly increases the performance of TLB flushes when running
with a high amount of vCPUs as a Xen guest, and is specially important
when running in shim mode.
The following figures are from a PV guest running `make -j32 xen
Add shadow and hap implementation specific helpers to perform guest
TLB flushes. Note that the code for both is exactly the same at the
moment, and is copied from hvm_flush_vcpu_tlb. This will be changed by
further patches that will add implementation specific optimizations to
them.
No functional
Introduce a specific flag to request a HVM guest TLB flush, which is
an ASID/VPID tickle that forces a linear TLB flush for all HVM guests.
This was previously unconditionally done in each pre_flush call, but
that's not required: HVM guests not using shadow don't require linear
TLB flushes as Xen
Allow a CPU already holding the lock in write mode to also lock it in
read mode. There's no harm in allowing read locking a rwlock that's
already owned by the caller (ie: CPU) in write mode. Allowing such
accesses is required at least for the CPU maps use-case.
In order to do this reserve 12bits o
Allow a CPU already holding the lock in write mode to also lock it in
read mode. There's no harm in allowing read locking a rwlock that's
already owned by the caller (ie: CPU) in write mode. Allowing such
accesses is required at least for the CPU maps use-case.
In order to do this reserve 14bits o
Allow a CPU already holding the lock in write mode to also lock it in
read mode. There's no harm in allowing read locking a rwlock that's
already owned by the caller (ie: CPU) in write mode. Allowing such
accesses is required at least for the CPU maps use-case.
In order to do this reserve 12bits o
-project/people/royger/xen/pipelines/120144901
Thanks, Roger.
Roger Pau Monne (2):
atomic: add atomic_and operations
rwlock: allow recursive read locking when already locked in write mode
xen/common/rwlock.c| 4 +--
xen/include/asm-arm/arm32/atomic.h | 17 ++
xen/include
To x86 and Arm. This performs an atomic AND operation against an
atomic_t variable with the provided mask.
Requested-by: Jan Beulich
Signed-off-by: Roger Pau Monné
---
xen/include/asm-arm/arm32/atomic.h | 17 +
xen/include/asm-arm/arm64/atomic.h | 14 ++
xen/include/
Add helpers to track when executing in #MC context. This is modeled
after the in_irq helpers.
Note that there are no users of in_mc() introduced by the change,
further users will be added by followup changes.
Signed-off-by: Roger Pau Monné
---
Changes since v2:
- Move definition of mc_count to
This is modeled after the irq_count variable, and is used to account
for all the NMIs handled by the system.
This will allow to repurpose the nmi_count() helper so it can be used
in a similar manner as local_irq_count(): account for the NMIs
currently in service.
Signed-off-by: Roger Pau Monné
-
Add helpers to track when running in #NMI context. This is modeled
after the in_irq helpers.
The SDM states that no #NMI can be delivered while handling a #NMI
until the processor has executed an iret instruction. It's possible
however that another fault is received while handling the #NMI (a #MC
hence should prevent further missuses.
Thanks, Roger.
Roger Pau Monne (5):
x86: introduce a nmi_count tracking variable
x86: track when in #NMI context
x86: track when in #MC context
x86/smp: use a dedicated scratch cpumask in send_IPI_mask
x86: add accessors for scratch cpu mask
xen
Using scratch_cpumask in send_IPI_mask is not safe because it can be
called from interrupt context, and hence Xen would have to make sure
all the users of the scratch cpumask disable interrupts while using
it.
Instead introduce a new cpumask to be used by send_IPI_mask, and
disable interrupts whil
Current usage of the per-CPU scratch cpumask is dangerous since
there's no way to figure out if the mask is already being used except
for manual code inspection of all the callers and possible call paths.
This is unsafe and not reliable, so introduce a minimal get/put
infrastructure to prevent nes
This is modeled after the irq_count variable, and is used to account
for all the NMIs handled by the system.
This will allow to repurpose the nmi_count() helper so it can be used
in a similar manner as local_irq_count(): account for the NMIs
currently in service.
Signed-off-by: Roger Pau Monné
-
Add helpers to track when executing in #MC handler context. This is
modeled after the in_irq helpers.
Note that there are no users of in_mce_handler() introduced by the
change, further users will be added by followup changes.
Signed-off-by: Roger Pau Monné
---
Changes since v3:
- Rename to in_m
. Patch #4 is a fix for that usage,
together with also preventing the usage of any per-CPU variables when
send_IPI_mask is called from #MC or NMI context. Previous patches are
preparatory changes.
Thanks, Roger.
Roger Pau Monne (4):
x86: introduce a nmi_count tracking variable
x86: track when in
Using scratch_cpumask in send_IPI_mask is not safe in IRQ or exception
context because it can nest, and hence send_IPI_mask could be
overwriting another user scratch cpumask data when used in such
contexts.
Instead introduce a new cpumask to be used by send_IPI_mask, and
disable interrupts while u
Add helpers to track when running in NMI handler context. This is
modeled after the in_irq helpers.
The SDM states that no NMI can be delivered while handling a NMI
until the processor has executed an iret instruction. It's possible
however that another fault is received while handling the NMI (a
Using scratch_cpumask in send_IPI_mask is not safe in IRQ or exception
context because it can nest, and hence send_IPI_mask could be
overwriting another user scratch cpumask data when used in such
contexts.
Instead introduce a new cpumask to be used by send_IPI_mask, and
disable interrupts while u
Hello,
Following series contain yet one more bugfix that removes the usage of
the scratch cpumask in send_IPI_mask and the introduction of accessors
to get/put the per-CPU scratch cpumask in order to prevent such issues
form happening in the future.
Thanks, Roger.
Roger Pau Monne (2):
x86/smp
Some callers of send_IPI_mask pass the scratch cpumask as the mask
parameter of send_IPI_mask, so the scratch cpumask cannot be used by
the function. The following trace has been obtained with a debug patch
and shows one of those callers:
(XEN) scratch CPU mask already in use by
arch/x86/mm.c#_ge
Current usage of the per-CPU scratch cpumask is dangerous since
there's no way to figure out if the mask is already being used except
for manual code inspection of all the callers and possible call paths.
This is unsafe and not reliable, so introduce a minimal get/put
infrastructure to prevent nes
Hello,
Following series contain yet one more bugfix that removes the usage of
the scratch cpumask in send_IPI_mask and the introduction of accessors
to get/put the per-CPU scratch cpumask in order to prevent such issues
form happening in the future.
Thanks, Roger.
Roger Pau Monne (2):
x86/smp
Current usage of the per-CPU scratch cpumask is dangerous since
there's no way to figure out if the mask is already being used except
for manual code inspection of all the callers and possible call paths.
This is unsafe and not reliable, so introduce a minimal get/put
infrastructure to prevent nes
Some callers of send_IPI_mask pass the scratch cpumask as the mask
parameter of send_IPI_mask, so the scratch cpumask cannot be used by
the function. The following trace has been obtained with a debug patch
and shows one of those callers:
(XEN) scratch CPU mask already in use by
arch/x86/mm.c#_ge
801 - 900 of 2554 matches
Mail list logo
