mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: "Edgecombe, Rick P" <rick.p.edgecombe@intel.com>
To: "dmaluka@chromium.org" <dmaluka@chromium.org>,
	"kvm@vger.kernel.org" <kvm@vger.kernel.org>,
	"pbonzini@redhat.com" <pbonzini@redhat.com>,
	"Hansen, Dave" <dave.hansen@intel.com>,
	"seanjc@google.com" <seanjc@google.com>,
	"binbin.wu@linux.intel.com" <binbin.wu@linux.intel.com>,
	"Yamahata, Isaku" <isaku.yamahata@intel.com>
Cc: "bp@alien8.de" <bp@alien8.de>, "x86@kernel.org" <x86@kernel.org>,
	"kas@kernel.org" <kas@kernel.org>,
	"hpa@zytor.com" <hpa@zytor.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"mingo@redhat.com" <mingo@redhat.com>,
	"dave.hansen@linux.intel.com" <dave.hansen@linux.intel.com>,
	"tglx@kernel.org" <tglx@kernel.org>,
	"linux-coco@lists.linux.dev" <linux-coco@lists.linux.dev>
Subject: Re: [PATCH] KVM: TDX: Fix APIC MSR ranges in tdx_has_emulated_msr()
Date: Thu, 19 Mar 2026 19:33:11 +0000	[thread overview]
Message-ID: <f67179d7050ae28ac261bb6227b1c045c10579c9.camel@intel.com> (raw)
In-Reply-To: <ee8d7ea3-0ece-43cf-ab07-6954df4c01ad@linux.intel.com>

On Thu, 2026-03-19 at 15:40 +0800, Binbin Wu wrote:
> tdx_has_emulated_msr() is used by KVM to decide whether to emulate a MSR access from the
> TDVMCALL or just return the error code.
> 
> During an off-list discussion, Rick noted that #VE reduction could change the behavior of
> accessing an MSR (e.g., from #VE to #GP or to be virtualized by the TDX module) without
> KVM knowing.Because KVM lacks the full context to perfectly decide if an MSR should be
> emulated, the question was raised: Can we just delete tdx_has_emulated_msr() entirely?
> 
> However, these native type x2apic MSRs are a special case. Since the TDX module owns the
> APICv page, KVM cannot emulate these MSRs. If we remove tdx_has_emulated_msr(), a guest
> directly issuing TDVMCALLs for these native type x2apic MSRs will trigger a silent failure,
> even though this is the guest's fault.
> 
> It comes down to a tradeoff. Should we prioritize code simplicity by dropping the function,
> or keep it to explicitly catch this misbehaving guest corner case?

I think from KVM's perspective it doesn't want to help the guest behave
correctly. So we can ignore that I think. But it does really care to not define
any specific guest ABI that it has to maintain. So tdx_has_emulated_msr() has
some value there. And even more, it wants to not allow the guest to hurt the
host.

On the latter point, another problem with deleting tdx_has_emulated_msr() is the
current code path skips the checks done in the other MSR paths. So we would need
to call some appropriate higher up MSR helper to protect the host? And that
wades into the CPUID bit consistency issues.

So maybe... could we do a more limited version of the deletion where we allow
all the APIC MSRs through? We'd have to check that it won't cause problems.

Failing that, we should maybe just explicitly list the ones TDX supports rather
than the current way we define the APIC ones. As you mention below, it's not
correct in other ways too so it could be more robust.

> 
> 
> BTW, besides the bug described by this patch, according to the latest published TDX module
> ABI table, MSR IA32_X2APIC_SELF_IPI is native type, but not included in the list.
> There are some MSRs, which are reserved for xAPIC MSR, not included in the list, but they
> can be covered by the KVM common code.


  reply	other threads:[~2026-03-19 19:33 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-03-18 19:01 Dmytro Maluka
2026-03-18 19:42 ` Dave Hansen
2026-03-18 20:30   ` Dmytro Maluka
2026-03-19  1:14   ` Binbin Wu
2026-03-19  1:48     ` Dave Hansen
2026-03-19  7:40       ` Binbin Wu
2026-03-19 19:33         ` Edgecombe, Rick P [this message]
2026-04-03 16:30           ` Sean Christopherson
2026-04-03 18:40             ` Edgecombe, Rick P
2026-04-03 19:07               ` Sean Christopherson
2026-04-03 19:30                 ` Edgecombe, Rick P
2026-04-03 23:07                   ` Sean Christopherson
2026-04-04  0:11                     ` Edgecombe, Rick P
2026-04-06 23:07                       ` Sean Christopherson

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=f67179d7050ae28ac261bb6227b1c045c10579c9.camel@intel.com \
    --to=rick.p.edgecombe@intel.com \
    --cc=binbin.wu@linux.intel.com \
    --cc=bp@alien8.de \
    --cc=dave.hansen@intel.com \
    --cc=dave.hansen@linux.intel.com \
    --cc=dmaluka@chromium.org \
    --cc=hpa@zytor.com \
    --cc=isaku.yamahata@intel.com \
    --cc=kas@kernel.org \
    --cc=kvm@vger.kernel.org \
    --cc=linux-coco@lists.linux.dev \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=seanjc@google.com \
    --cc=tglx@kernel.org \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®