Re: [PATCH 2/8] KVM: x86/xen: Introduce kvm_xen_has_64bit_shinfo() macro

[David Woodhouse]

On Sat, 2026-06-06 at 12:11 +0100, David Laight wrote:
> On Sat, 06 Jun 2026 10:35:45 +0100
> David Woodhouse <dwmw2@xxxxxxxxxxxxx> wrote:
> 
> > On Sat, 2026-06-06 at 10:30 +0100, David Laight wrote:
> > > On Fri,  5 Jun 2026 15:17:27 +0100
> > > David Woodhouse <dwmw2@xxxxxxxxxxxxx> wrote:
> > >   
> > > > From: David Woodhouse <dwmw@xxxxxxxxxxxx>
> > > > 
> > > > Add a kvm_xen_has_64bit_shinfo() helper macro to replace the repeated
> > > > pattern of 'IS_ENABLED(CONFIG_64BIT) && kvm->arch.xen.long_mode'
> > > > throughout the Xen emulation code. The macro uses READ_ONCE() to
> > > > ensure a consistent snapshot of the flag, which can be changed by
> > > > another vCPU at any time.  
> > > 
> > > If another vCPU changes the flag then isn't it all broken?
> > > The code seems to need the value to be stable.  
> > 
> > Do you believe the explanation in patch 4 to be insufficient?
> 
> (I read patch 2 first...)
> Changing the same lines twice is s bit excessive.

You mean a "no functional change" cleanup followed by the actual
change? No, that's normal.

> 
> There is this bit in #4:
> 
>  Even with this fix, the same corruption can occur if 64-bit mode is
>  latched and the guest switches to 32-bit mode immediately afterward.
> 
> which, I think, means it is all hopeless really.

I'm glad you now think that. I had explained it twice, both in the
cover letter and in the commit message of patch 4 that I pointed you
at.

If a guest switches an *active* shared info page between 32 and 64 bit
then we make almost no attempt to convert the contents.

All we're doing here is making things prettier by at least being
consistent about whether we're treating it as 32-bit or 64-bit for the
duration of each hypercall or event.

Which is why it says, "This fix is for internal consistency rather than
correcting any observable bug."

Did you have a remaining question?

Attachment: smime.p7s
Description: S/MIME cryptographic signature