[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <YyH/tOqrl8pZmoub@google.com>
Date: Wed, 14 Sep 2022 16:22:12 +0000
From: Sean Christopherson <seanjc@...gle.com>
To: Dave Hansen <dave.hansen@...el.com>
Cc: Peter Gonda <pgonda@...gle.com>, Adam Dunlap <acdunlap@...gle.com>,
Thomas Gleixner <tglx@...utronix.de>,
Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>,
Dave Hansen <dave.hansen@...ux.intel.com>,
the arch/x86 maintainers <x86@...nel.org>,
"H. Peter Anvin" <hpa@...or.com>,
Nathan Chancellor <nathan@...nel.org>,
Nick Desaulniers <ndesaulniers@...gle.com>,
Tom Rix <trix@...hat.com>,
"Kirill A. Shutemov" <kirill.shutemov@...ux.intel.com>,
Kuppuswamy Sathyanarayanan
<sathyanarayanan.kuppuswamy@...ux.intel.com>,
Andi Kleen <ak@...ux.intel.com>,
Ben Dooks <ben-linux@...ff.org>,
LKML <linux-kernel@...r.kernel.org>, llvm@...ts.linux.dev,
Jacob Xu <jacobhxu@...gle.com>,
Alper Gun <alpergun@...gle.com>, Marc Orr <marcorr@...gle.com>
Subject: Re: [PATCH v2 RESEND] x86/asm: Force native_apic_mem_read to use mov
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@...gle.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.
Powered by blists - more mailing lists