Messages in this thread | | | From | Peter Gonda <> | Date | Thu, 15 Sep 2022 09:09:45 +0100 | Subject | Re: [PATCH v2 RESEND] x86/asm: Force native_apic_mem_read to use mov |
| |
On Wed, Sep 14, 2022 at 5:22 PM Sean Christopherson <seanjc@google.com> wrote: > > On Wed, Sep 14, 2022, Dave Hansen wrote: > > On 9/14/22 04:13, Peter Gonda wrote: > > > On Thu, Sep 8, 2022 at 6:05 PM Adam Dunlap <acdunlap@google.com> 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? > > > > No. > > > > It's not just an SEV-ES thing. It's a problem for TDX and _probably_ a > > problem for normal virtualization where it's a host-side issue. Kirill > > wrote a lot of great background information in here: > > > > > https://lore.kernel.org/all/164946765464.4207.3715751176055921036.tip-bot2@tip-bot2/ > > > > So, the question is not "should we extend the MMIO instruction decoders > > to handle one more instruction?". It is "should we extend the MMIO > > decoders to handle *ALL* memory read instructions?" > > > > That's an even more emphatic "NO". > > +1, keep the guest-side decoding as simple as possible. > > > readl() seems to be the right thing to do. Also, Dear TDX, SEV and virt > > folks: please look for more of these. They're going to bite you sooner > > or later. You should have caught this one before now.
Thanks for the context here Dave. Fixing the offending MMIO instruction here makes sense.
| |