All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dave Hansen <dave.hansen@intel.com>
To: Peter Gonda <pgonda@google.com>, Adam Dunlap <acdunlap@google.com>
Cc: Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
	Dave Hansen <dave.hansen@linux.intel.com>,
	the arch/x86 maintainers <x86@kernel.org>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Nathan Chancellor <nathan@kernel.org>,
	Nick Desaulniers <ndesaulniers@google.com>,
	Tom Rix <trix@redhat.com>,
	"Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>,
	Sean Christopherson <seanjc@google.com>,
	Kuppuswamy Sathyanarayanan
	<sathyanarayanan.kuppuswamy@linux.intel.com>,
	Andi Kleen <ak@linux.intel.com>, Ben Dooks <ben-linux@fluff.org>,
	LKML <linux-kernel@vger.kernel.org>,
	llvm@lists.linux.dev, Jacob Xu <jacobhxu@google.com>,
	Alper Gun <alpergun@google.com>, Marc Orr <marcorr@google.com>
Subject: Re: [PATCH v2 RESEND] x86/asm: Force native_apic_mem_read to use mov
Date: Wed, 14 Sep 2022 05:03:59 -0700	[thread overview]
Message-ID: <2625dbfa-434c-7d55-6469-9d9e89397e8f@intel.com> (raw)
In-Reply-To: <CAMkAt6qUs526FCq26Ht48c2KVZWe=QcNds6_LE6JJbs-7Hzk+g@mail.gmail.com>

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".

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.

  parent reply	other threads:[~2022-09-14 12:04 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-08-11 18:00 [PATCH] x86/asm: Force native_apic_mem_read to use mov Adam Dunlap
2022-08-11 19:27 ` Sean Christopherson
2022-08-11 19:57   ` H. Peter Anvin
2022-08-11 20:03     ` Sean Christopherson
2022-08-12  4:40       ` H. Peter Anvin
2022-08-12 18:32         ` Adam Dunlap
2022-08-12 18:35           ` [PATCH v2] " Adam Dunlap
2022-09-08 17:04             ` [PATCH v2 RESEND] " Adam Dunlap
2022-09-14 11:13               ` Peter Gonda
2022-09-14 11:59                 ` Marc Orr
2022-09-14 11:59                   ` Marc Orr
2022-09-15  7:51                     ` Tom Lendacky
2022-09-14 12:03                 ` Dave Hansen [this message]
2022-09-14 16:22                   ` Sean Christopherson
2022-09-15  8:09                     ` Peter Gonda
     [not found]                       ` <CAMBK9=YB=8EQymDUda300qPFAL1=7dzC61c0pshrWEC5ibrUfQ@mail.gmail.com>
2022-10-03 23:07                         ` Adam Dunlap
     [not found]                         ` <B7175642-351D-44A0-B7AD-E69C6B64FC18@zytor.com>
2022-10-05 13:28                           ` Tom Lendacky
2022-11-17 21:23                             ` Marc Orr
2023-11-17 18:14                               ` Sidharth Telang
2023-11-17 19:23                                 ` Dave Hansen
2022-08-11 19:53 ` [PATCH] " H. Peter Anvin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=2625dbfa-434c-7d55-6469-9d9e89397e8f@intel.com \
    --to=dave.hansen@intel.com \
    --cc=acdunlap@google.com \
    --cc=ak@linux.intel.com \
    --cc=alpergun@google.com \
    --cc=ben-linux@fluff.org \
    --cc=bp@alien8.de \
    --cc=dave.hansen@linux.intel.com \
    --cc=hpa@zytor.com \
    --cc=jacobhxu@google.com \
    --cc=kirill.shutemov@linux.intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=llvm@lists.linux.dev \
    --cc=marcorr@google.com \
    --cc=mingo@redhat.com \
    --cc=nathan@kernel.org \
    --cc=ndesaulniers@google.com \
    --cc=pgonda@google.com \
    --cc=sathyanarayanan.kuppuswamy@linux.intel.com \
    --cc=seanjc@google.com \
    --cc=tglx@linutronix.de \
    --cc=trix@redhat.com \
    --cc=x86@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.