xen/arch/x86/pv/iret.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
Use new helper functions to simplfiy the logic. This removes an alternative
behind the scenes.
No functional change.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
---
CC: Jan Beulich <jbeulich@suse.com>
CC: Roger Pau Monné <roger@xenproject.org>
CC: Teddy Astie <teddy.astie@vates.tech>
async_exception_cleanup() is complete nonsense. It's not remotely close to
how interupt blocking works in x86.
---
xen/arch/x86/pv/iret.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/xen/arch/x86/pv/iret.c b/xen/arch/x86/pv/iret.c
index 39ce316b8d91..0efc0c7f12f3 100644
--- a/xen/arch/x86/pv/iret.c
+++ b/xen/arch/x86/pv/iret.c
@@ -31,8 +31,8 @@ static void async_exception_cleanup(struct vcpu *curr)
if ( !curr->arch.async_exception_mask )
return;
- if ( !(curr->arch.async_exception_mask & (curr->arch.async_exception_mask - 1)) )
- trap = __scanbit(curr->arch.async_exception_mask, VCPU_TRAP_NONE);
+ if ( !multiple_bits_set(curr->arch.async_exception_mask) )
+ trap = ffs(curr->arch.async_exception_mask) + 1;
else
for ( trap = VCPU_TRAP_NONE + 1; trap <= VCPU_TRAP_LAST; ++trap )
if ( (curr->arch.async_exception_mask ^
--
2.39.5
On 02/11/2026 5:42 pm, Andrew Cooper wrote: > Use new helper functions to simplfiy the logic. This removes an alternative > behind the scenes. > > No functional change. > > Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> > --- > CC: Jan Beulich <jbeulich@suse.com> > CC: Roger Pau Monné <roger@xenproject.org> > CC: Teddy Astie <teddy.astie@vates.tech> > > async_exception_cleanup() is complete nonsense. It's not remotely close to > how interupt blocking works in x86. > --- > xen/arch/x86/pv/iret.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/xen/arch/x86/pv/iret.c b/xen/arch/x86/pv/iret.c > index 39ce316b8d91..0efc0c7f12f3 100644 > --- a/xen/arch/x86/pv/iret.c > +++ b/xen/arch/x86/pv/iret.c > @@ -31,8 +31,8 @@ static void async_exception_cleanup(struct vcpu *curr) > if ( !curr->arch.async_exception_mask ) > return; > > - if ( !(curr->arch.async_exception_mask & (curr->arch.async_exception_mask - 1)) ) > - trap = __scanbit(curr->arch.async_exception_mask, VCPU_TRAP_NONE); > + if ( !multiple_bits_set(curr->arch.async_exception_mask) ) > + trap = ffs(curr->arch.async_exception_mask) + 1; This should of course be a -1 rather than +1. Fixed locally. ~Andrew
On 03.11.2026 12:00, Andrew Cooper wrote: > On 02/11/2026 5:42 pm, Andrew Cooper wrote: >> Use new helper functions to simplfiy the logic. This removes an alternative >> behind the scenes. Does it? __scanbit() engages an alternative only when its 2nd argument is BITS_PER_LONG. >> No functional change. >> >> Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> >> --- >> CC: Jan Beulich <jbeulich@suse.com> >> CC: Roger Pau Monné <roger@xenproject.org> >> CC: Teddy Astie <teddy.astie@vates.tech> >> >> async_exception_cleanup() is complete nonsense. It's not remotely close to >> how interupt blocking works in x86. Are you perhaps expecting something that (for PV) was never intended? >> --- a/xen/arch/x86/pv/iret.c >> +++ b/xen/arch/x86/pv/iret.c >> @@ -31,8 +31,8 @@ static void async_exception_cleanup(struct vcpu *curr) >> if ( !curr->arch.async_exception_mask ) >> return; >> >> - if ( !(curr->arch.async_exception_mask & (curr->arch.async_exception_mask - 1)) ) >> - trap = __scanbit(curr->arch.async_exception_mask, VCPU_TRAP_NONE); >> + if ( !multiple_bits_set(curr->arch.async_exception_mask) ) >> + trap = ffs(curr->arch.async_exception_mask) + 1; > > This should of course be a -1 rather than +1. Fixed locally. Acked-by: Jan Beulich <jbeulich@suse.com> (with the description corrected or you pointing out which other alternative you mean) Jan
On 03/11/2026 11:36 am, Jan Beulich wrote: > On 03.11.2026 12:00, Andrew Cooper wrote: >> On 02/11/2026 5:42 pm, Andrew Cooper wrote: >>> Use new helper functions to simplfiy the logic. This removes an alternative >>> behind the scenes. > Does it? __scanbit() engages an alternative only when its 2nd argument is > BITS_PER_LONG. Oh, yes. I'll drop that sentence. >>> No functional change. >>> >>> Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> >>> --- >>> CC: Jan Beulich <jbeulich@suse.com> >>> CC: Roger Pau Monné <roger@xenproject.org> >>> CC: Teddy Astie <teddy.astie@vates.tech> >>> >>> async_exception_cleanup() is complete nonsense. It's not remotely close to >>> how interupt blocking works in x86. > Are you perhaps expecting something that (for PV) was never intended? I've long since given up being surprised at PV doing bizarre things. This async_exception_state[].pending is used for HVM guests; this aspect does need to change. async_exception_state[].old_mask is specific to PV and, AFAICT, interlocks both NMI and #MC together so they nest, with HYPERCALL_iret "refcounts" the unwinding. Architecturally, NMIs are blocked until the next sequential IRET, while #MC has no blocking capabilities at all. PV guests behaving the way they do violates the principle of least surprise. >>> --- a/xen/arch/x86/pv/iret.c >>> +++ b/xen/arch/x86/pv/iret.c >>> @@ -31,8 +31,8 @@ static void async_exception_cleanup(struct vcpu *curr) >>> if ( !curr->arch.async_exception_mask ) >>> return; >>> >>> - if ( !(curr->arch.async_exception_mask & (curr->arch.async_exception_mask - 1)) ) >>> - trap = __scanbit(curr->arch.async_exception_mask, VCPU_TRAP_NONE); >>> + if ( !multiple_bits_set(curr->arch.async_exception_mask) ) >>> + trap = ffs(curr->arch.async_exception_mask) + 1; >> This should of course be a -1 rather than +1. Fixed locally. > Acked-by: Jan Beulich <jbeulich@suse.com> > (with the description corrected or you pointing out which other alternative > you mean) Thanks. ~Andrew
© 2016 - 2026 Red Hat, Inc.