From: "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>
To: Sean Christopherson <seanjc@google.com>
Cc: Dave Hansen <dave.hansen@intel.com>,
tglx@linutronix.de, mingo@redhat.com, bp@alien8.de,
luto@kernel.org, peterz@infradead.org,
sathyanarayanan.kuppuswamy@linux.intel.com, ak@linux.intel.com,
dan.j.williams@intel.com, david@redhat.com, hpa@zytor.com,
thomas.lendacky@amd.com, x86@kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] x86/tdx: Handle load_unaligned_zeropad() page-cross to a shared page
Date: Thu, 19 May 2022 21:19:58 +0300 [thread overview]
Message-ID: <20220519181958.libitxp2jws4prcr@black.fi.intel.com> (raw)
In-Reply-To: <YoQnQIfX8GuOgKqH@google.com>
On Tue, May 17, 2022 at 10:52:48PM +0000, Sean Christopherson wrote:
> On Tue, May 17, 2022, Sean Christopherson wrote:
> > On Tue, May 17, 2022, Dave Hansen wrote:
> > > On 5/17/22 13:17, Kirill A. Shutemov wrote:
> > > >>> Given that we had to adjust IP in handle_mmio() anyway, do you still think
> > > >>> "ve->instr_len = 0;" is wrong? I dislike ip_adjusted more.
> > > >> Something is wrong about it.
> > > >>
> > > >> You could call it 've->instr_bytes_to_handle' or something. Then it
> > > >> makes actual logical sense when you handle it to zero it out. I just
> > > >> want it to be more explicit when the upper levels need to do something.
> > > >>
> > > >> Does ve->instr_len==0 both when the TDX module isn't providing
> > > >> instruction sizes *and* when no handling is necessary? That seems like
> > > >> an unfortunate logical multiplexing of 0.
> > > > For EPT violation, ve->instr_len has *something* (not zero) that doesn't
> > > > match the actual instruction size. I dig out that it is filled with data
> > > > from VMREAD(0x440C), but I don't know where is the ultimate origin of the
> > > > data.
> > >
> > > The SDM has a breakdown:
> > >
> > > 27.2.5 Information for VM Exits Due to Instruction Execution
> > >
> > > I didn't realize it came from VMREAD. I guess I assumed it came from
> > > some TDX module magic. Silly me.
> > >
> > > The SDM makes it sound like we should be more judicious about using
> > > 've->instr_len' though. "All VM exits other than those listed in the
> > > above items leave this field undefined." Looking over
> > > virt_exception_kernel(), we've got five cases from CPU instructions that
> > > cause unconditional VMEXITs:
>
> Ideally, what the SDM says wouldn't matter at all. The TDX module spec really
> should be the authorative source in this case, but it just punts to the SDM:
>
> The 32-bit value that would have been saved into the VMCS as VM-exit instruction
> length if a legacy VM exit had occurred instead of the virtualization exception.
>
> Even if the TDX spec wants to punt to the SDM, it would save a lot of headache and
> SDM reading if it also said something to the effect of:
>
> The INSTRUCTION_LENGTH and INSTRUCTION_INFORMATION fields are valid for all
> #VEs injected by the Intel TDX Module. The fields are undefined for #VEs
> injected by the CPU due to EPT Violations.
I initiated update to the spec, but it will take time.
--
Kirill A. Shutemov
next prev parent reply other threads:[~2022-05-19 18:20 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-05-17 15:30 [PATCH] x86/tdx: Handle load_unaligned_zeropad() page-cross to a shared page Kirill A. Shutemov
2022-05-17 16:36 ` Dave Hansen
2022-05-17 17:40 ` Kirill A. Shutemov
2022-05-17 18:14 ` Dave Hansen
2022-05-17 20:17 ` Kirill A. Shutemov
2022-05-17 22:16 ` Dave Hansen
2022-05-17 22:40 ` Sean Christopherson
2022-05-17 22:52 ` Dave Hansen
2022-05-17 22:52 ` Sean Christopherson
2022-05-19 18:19 ` Kirill A. Shutemov [this message]
2022-05-19 18:35 ` Dave Hansen
2022-05-19 18:07 ` Kirill A. Shutemov
2022-05-19 18:33 ` Dave Hansen
2022-05-18 8:39 ` David Laight
2022-05-18 12:18 ` Kirill A. Shutemov
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=20220519181958.libitxp2jws4prcr@black.fi.intel.com \
--to=kirill.shutemov@linux.intel.com \
--cc=ak@linux.intel.com \
--cc=bp@alien8.de \
--cc=dan.j.williams@intel.com \
--cc=dave.hansen@intel.com \
--cc=david@redhat.com \
--cc=hpa@zytor.com \
--cc=linux-kernel@vger.kernel.org \
--cc=luto@kernel.org \
--cc=mingo@redhat.com \
--cc=peterz@infradead.org \
--cc=sathyanarayanan.kuppuswamy@linux.intel.com \
--cc=seanjc@google.com \
--cc=tglx@linutronix.de \
--cc=thomas.lendacky@amd.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.