Re: [PATCH 04/11] KVM: VMX: Read 32-bit GPR values for ENCLS instructions outside of 64-bit mode

["Huang, Kai" <kai.huang@intel.com>]

On Wed, 2026-04-15 at 17:27 -0700, Sean Christopherson wrote:
> On Wed, Apr 15, 2026, Kai Huang wrote:
> > On Wed, 2026-04-15 at 14:37 -0700, Sean Christopherson wrote:
> > > On Mon, Apr 13, 2026, Kai Huang wrote:
> > > But IIRC, that's "just" the architectural behavior.  Hardware implementations may
> > > choose to preserve values.
> > 
> > That seems to be a violation to a "basic" architecture :-)
> 
> Not really.  The SDM says they aren't guaranteed to be _preserved_.  It doesn't
> say that they will be zeroed.  And so literally any value in bits 63:32 is
> architecturally legal.

Ah OK.

> 
> > > > If vCPU is in 32-bit mode then it should not be able to access 64-bit GPR?
> > > 
> > > Yes and no.  Mostly no.  Architecturally, they're all off limits.  But, again
> > > going from memory that's ~15 years old at this point, IIRC the behavior is that
> > > writes in 32-bit modes zero bits 63:32, same as 32-bit writes in 64-bit mode.
> > > 
> > > Take all of my memory with a huge grain of salt, it's very possible I'm
> > > mis-remembering hallway discussions from a long time ago.
> > 
> > I tend to think it's beyond the point we need to worry about.  It shouldn't
> > happen even the guest is buggy or malicious AFAICT, unless KVM somehow
> > messes things up itself, in which case a WARN() is more reasonable I
> > suppose.
> 
> KVM needs to worry about it from the perspective of not consuming garbage.  As
> above, KVM cannot assume bits 63:32 are zero, and so needs to be careful to only
> consume bits 31:0.
> 
> > This also made me look into whether how VMENTER handles GPRs when vCPU is
> > not in 64-bit mode.  I see nothing described in the SDM except VMENTRY
> > checks "guest's" RIP and RFLAGS.  Maybe KVM should explicitly clear high
> > bits of GPRs when going back to compatible mode from 64-bit mode, or maybe
> > hardware does it?
> 
> Definitely not.  VM-Exit => VM-Enter must be transparent to the guest.  E.g. if
> a host IRQ arrives, register state shouldn't magically change from the guest's
> perspective.  
> 

Yeah I mean KVM needs to enumerate the behaviour.

> If hardware clobbers state, so be it.  But I don't want KVM to
> actively clobber registers in this case.

OK.  

As you said "not preserved" doesn't architecturally mean "zeroed":

Acked-by: Kai Huang <kai.huang@intel.com>