Re: [PATCH v2 RESEND] x86/asm: Force native_apic_mem_read to use mov

[Tom Lendacky]

On 9/14/22 06:59, Marc Orr wrote:
> On Wed, Sep 14, 2022 at 12:59 PM Marc Orr <marcorr@xxxxxxxxxx> wrote:
> > On Wed, Sep 14, 2022 at 12:13 PM Peter Gonda <pgonda@xxxxxxxxxx> wrote:
> > > On Thu, Sep 8, 2022 at 6:05 PM Adam Dunlap <acdunlap@xxxxxxxxxx> wrote:
> > > > Previously, when compiled with clang, native_apic_mem_read gets inlined
> > > > into __xapic_wait_icr_idle and optimized to a testl instruction. When
> > > > run in a VM with SEV-ES enabled, it attempts to emulate this
> > > > instruction, but the emulator does not support it. Instead, use inline
> > > > assembly to force native_apic_mem_read to use the mov instruction which
> > > > is supported by the emulator.
> > >
> > > This seems to be an issue with the SEV-ES in guest #VC handler's
> > > "emulator" right?
> > >
> > > If that's the case I think this should be fixed in the #VC handler
> > > instead of fixing the code that is failing to be emulated. What if
> > > there are other places where a testl is used and our tests have not
> > > caught them.
> >
> > That was my initial reaction too. But we spoke w/ Tom offline (before
> > sending this) and my understanding was that we really should be using
> > MOV for MMIO. I've cc'd Tom so he can speak to this directly though.

I did finally find the section in our PPR that references using the MOV 
instruction, but it was for MMIO configuration space, not general MMIO 
operations.

So, yes, the #VC handler could be extended to handle a TEST instruction to 
fix this. My worry would be if the compiler decided to use a different 
instruction in the future. I see that the native_apic_mem_write() is using 
assembler to perform its operation, it just seemed right that the 
native_apic_mem_read() could do the same.

Thanks,
Tom

> Actually cc'ing Tom :-).