All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sean Christopherson <seanjc@google.com>
To: Xiaoyao Li <xiaoyao.li@intel.com>
Cc: Rick P Edgecombe <rick.p.edgecombe@intel.com>,
	"kvm@vger.kernel.org" <kvm@vger.kernel.org>,
	 "pbonzini@redhat.com" <pbonzini@redhat.com>
Subject: Re: [RFC] TDX module configurability of 0x80000008
Date: Tue, 7 May 2024 10:11:57 -0700	[thread overview]
Message-ID: <Zjpg3dhf0mWetkSE@google.com> (raw)
In-Reply-To: <6e0dc5f2-169e-4277-b7fe-e69234ccc1fd@intel.com>

On Wed, May 08, 2024, Xiaoyao Li wrote:
> On 4/25/2024 12:55 AM, Edgecombe, Rick P wrote:
> > One of the TDX module features is called MAXPA_VIRT. In short, it is similar to
> > KVM’s allow_smaller_maxphyaddr. It requires an explicit opt-in by the VMM, and
> > allows a TD’s 0x80000008.EAX[7:0] to be configured by the VMM. Accesses to
> > physical addresses above the specified value by the TD will cause the TDX module
> > to inject a mostly correct #PF with the RSVD error code set. It has to deal with
> > the same problems as allow_smaller_maxphyaddr for correctly setting the RSVD
> > bit. I wasn’t thinking to push this feature for KVM due the movement away from
> > allow_smaller_maxphyaddr and towards 0x80000008.EAX[23:16].
> > 
> 
> I would like to get your opinion of the MAXPA_VIRT feature of TDX. What is
> likely the KVM's decision on it? Won't support it due to it has the same
> limitation of allow_smaller_maxphyaddr?

Not supporting MAXPA_VIRT has my vote.  I'm of the opinion that allow_smaller_maxphyaddr
should die a horrible, fiery death :-)

  reply	other threads:[~2024-05-07 17:11 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-04-24 16:55 [RFC] TDX module configurability of 0x80000008 Edgecombe, Rick P
2024-04-25 15:09 ` Xiaoyao Li
2024-04-25 16:31   ` Edgecombe, Rick P
2024-04-25 16:59     ` Sean Christopherson
2024-04-25 18:20       ` Edgecombe, Rick P
2024-04-25 21:39         ` Sean Christopherson
2024-04-25 22:41           ` Edgecombe, Rick P
2024-04-25 22:53             ` Sean Christopherson
2024-04-25 23:08               ` Edgecombe, Rick P
2024-04-25 23:28                 ` Sean Christopherson
2024-04-25 23:38                   ` Edgecombe, Rick P
2024-05-06 18:40                     ` Edgecombe, Rick P
2024-05-07 14:22                       ` Chao Gao
2024-05-07 14:49                         ` Edgecombe, Rick P
2024-05-07 16:21                           ` Sean Christopherson
2024-05-07 16:41 ` Xiaoyao Li
2024-05-07 17:11   ` Sean Christopherson [this message]
2024-05-08  7:50     ` Xiaoyao Li

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=Zjpg3dhf0mWetkSE@google.com \
    --to=seanjc@google.com \
    --cc=kvm@vger.kernel.org \
    --cc=pbonzini@redhat.com \
    --cc=rick.p.edgecombe@intel.com \
    --cc=xiaoyao.li@intel.com \
    /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.