On Fri, Jan 24, 2025 at 03:31:30PM +0100, Roger Pau Monné wrote:
> On Thu, Jan 25, 2024 at 12:24:53PM -0800, Elliott Mitchell wrote:
> > Apparently this was first noticed with 4.14, but more recently I've been
> > able to reproduce the issue:
> >
> > https://bugs.debian.org/988477
> >
> > The ori
On 21/01/25 18:00, Uladzislau Rezki wrote:
>> >
>> > As noted before, we defer flushing for vmalloc. We have a lazy-threshold
>> > which can be exposed(if you need it) over sysfs for tuning. So, we can add
>> > it.
>> >
>>
>> In a CPU isolation / NOHZ_FULL context, isolated CPUs will be running a
On Thu, Jan 25, 2024 at 12:24:53PM -0800, Elliott Mitchell wrote:
> Apparently this was first noticed with 4.14, but more recently I've been
> able to reproduce the issue:
>
> https://bugs.debian.org/988477
>
> The original observation features MD-RAID1 using a pair of Samsung
> SATA-attached fla
On Fri, Jan 24, 2025 at 02:24:34PM +, Andrew Cooper wrote:
> On 24/01/2025 12:01 pm, Roger Pau Monne wrote:
> > Hello,
> >
> > The following series is the original CX16 series sent by Teddy, with the
> > CX16 checks split into a separate patch, plus one extra patch to switch
> > AMD-Vi to use C
On 24/01/2025 12:01 pm, Roger Pau Monne wrote:
> Hello,
>
> The following series is the original CX16 series sent by Teddy, with the
> CX16 checks split into a separate patch, plus one extra patch to switch
> AMD-Vi to use CMPXCHG16B when updating Interrupt Remapping Entries.
>
> Note that last pat
Philippe Mathieu-Daudé writes:
> Use the tcg_enabled() check so the compiler can elide
> the call when TCG isn't available, allowing to remove
> the tb_flush() stub.
>
> Signed-off-by: Philippe Mathieu-Daudé
Reviewed-by: Alex Bennée
--
Alex Bennée
Virtualisation Tech Lead @ Linaro
From: Teddy Astie
As CX16 support is mandatory for IOMMU usage, the checks for CX16 in the
interrupt remapping code are stale. Remove them together with the
associated code introduced in case CX16 was not available.
Note that AMD-Vi support for atomically updating a 128bit IRTE entry is
still n
From: Teddy Astie
This flag was only used in case cx16 is not available, as those code paths no
longer exist, this flag now does basically nothing.
Signed-off-by: Teddy Astie
Signed-off-by: Roger Pau Monné
---
xen/drivers/passthrough/vtd/iommu.c | 12 +++-
xen/drivers/passthrough/vtd/
Hello,
The following series is the original CX16 series sent by Teddy, with the
CX16 checks split into a separate patch, plus one extra patch to switch
AMD-Vi to use CMPXCHG16B when updating Interrupt Remapping Entries.
Note that last patch to use CMPXCHG16B fixes a real bug with AMD
hardware.
T
Either when using a 32bit Interrupt Remapping Entry or a 128bit one update
the entry atomically, by using cmpxchg unconditionally as IOMMU depends on
it. No longer disable the entry by setting RemapEn = 0 ahead of updating
it. As a consequence of not toggling RemapEn ahead of the update the
Inter
From: Teddy Astie
As CX16 support is mandatory for IOMMU usage, the checks for CX16 in the
DMA remapping code are stale. Remove them together with the associated
code introduced in case CX16 was not available.
Suggested-by: Andrew Cooper
Signed-off-by: Teddy Astie
Signed-off-by: Roger Pau Mon
From: Teddy Astie
All hardware with VT-d/AMD-Vi has CMPXCHG16B support. Check this at
initialisation time, and remove the effectively-dead logic for the
non-cx16 case.
If the local APICs support x2APIC mode the IOMMU support for interrupt
remapping will be checked earlier using a specific helper
On Mon, Feb 26, 2024 at 05:40:25PM +0100, Jan Beulich wrote:
> 01: VMX: don't run with CR4.VMXE set when VMX could not be enabled
> 02: x86/HVM: improve CET-IBT pruning of ENDBR
> 03: VMX: drop vmcs_revision_id
> 04: VMX: convert vmx_basic_msr
> 05: VMX: convert vmx_pin_based_exec_control
> 06: VMX
On Fri, Jan 24, 2025 at 11:51:37AM +0100, Roger Pau Monné wrote:
> On Mon, Feb 26, 2024 at 05:42:50PM +0100, Jan Beulich wrote:
> > It's effectively redundant with vmx_basic_msr. For the #define
> > replacement to work, struct vmcs_struct's respective field name also
> > needs to change: Drop the n
On Mon, Feb 26, 2024 at 05:43:21PM +0100, Jan Beulich wrote:
> ... to a struct field, which is then going to be accompanied by other
> capability/control data presently living in individual variables. As
> this structure isn't supposed to be altered post-boot, put it in
> .data.ro_after_init right
Hello Valentin,
On 1/14/2025 11:21 PM, Valentin Schneider wrote:
[..snip..]
diff --git a/include/linux/context_tracking_work.h
b/include/linux/context_tracking_work.h
index c68245f8d77c5..931ade1dcbcc2 100644
--- a/include/linux/context_tracking_work.h
+++ b/include/linux/context_tracking_work.
On Mon, Feb 26, 2024 at 05:42:50PM +0100, Jan Beulich wrote:
> It's effectively redundant with vmx_basic_msr. For the #define
> replacement to work, struct vmcs_struct's respective field name also
> needs to change: Drop the not really meaningful "vmcs_" prefix from it.
>
> Signed-off-by: Jan Beul
On Mon, Feb 26, 2024 at 05:42:02PM +0100, Jan Beulich wrote:
> While generally benign, doing so is still at best misleading.
>
> Signed-off-by: Jan Beulich
Acked-by: Roger Pau Monné
Thanks, Roger.
On Thu, Jan 23, 2025 at 05:14:39PM +0100, Jan Beulich wrote:
> On 23.01.2025 15:24, Roger Pau Monné wrote:
> > On Thu, Jan 23, 2025 at 02:18:41PM +0100, Jan Beulich wrote:
> >> On 23.01.2025 13:41, Roger Pau Monné wrote:
> >>> On Mon, Feb 26, 2024 at 05:42:20PM +0100, Jan Beulich wrote:
> ---
19 matches
Mail list logo
