Messages in this thread | | | From | "Yao, Jiewen" <> | Subject | RE: [PATCH v8 2/5] x86/tdx: Add TDX Guest event notify interrupt support | Date | Sat, 25 Jun 2022 03:35:27 +0000 |
| |
Thank you, Jun.
Yes. I confirmed that we will include below change to GHCI.next spec.
================ 3.5 TDG.VP.VMCALL<SetupEventNotifyInterrupt>
From: "The host VMM should use SEAMCALL [TDWRVPS] leaf to inject an interrupt at the requested-interrupt vector into the TD via the posted-interrupt descriptor. "
To: "The host VMM should use SEAMCALL [TDWRVPS] leaf to inject an interrupt at the requested-interrupt vector into the TD VCPU that executed TDG.VP.VMCALL <SetupEventNotifyInterrupt> via the posted-interrupt descriptor. "
3.13 TDG.VP.VMCALL<Service>
Table 3-39: TDG.VP.VMCALL< Service >-Input Operands
From: R14: "Event notification interrupt vector - (valid values 32~255) selected by TD 0: blocking action. VMM need get response then return. 1~31: Reserved. Should not be used. 32~255: Non-block action. VMM can return immediately and signal the interrupt vector when the response is ready. "
To: R14: "Event notification interrupt vector - (valid values 32~255) selected by TD 0: blocking action. VMM need get response then return. 1~31: Reserved. Should not be used. 32~255: Non-block action. VMM can return immediately and signal the interrupt vector when the response is ready. VMM should inject interrupt vector into the TD VCPU that executed TDG.VP.VMCALL<Service>."
================
Thank you Yao Jiewen
> -----Original Message----- > From: Nakajima, Jun <jun.nakajima@intel.com> > Sent: Saturday, June 25, 2022 7:42 AM > To: Sathyanarayanan Kuppuswamy > <sathyanarayanan.kuppuswamy@linux.intel.com> > Cc: Huang, Kai <kai.huang@intel.com>; Thomas Gleixner <tglx@linutronix.de>; > Ingo Molnar <mingo@redhat.com>; Borislav Petkov <bp@alien8.de>; Dave > Hansen <dave.hansen@linux.intel.com>; x86@kernel.org; H . Peter Anvin > <hpa@zytor.com>; Kirill A . Shutemov <kirill.shutemov@linux.intel.com>; Luck, > Tony <tony.luck@intel.com>; Andi Kleen <ak@linux.intel.com>; Wander Lairson > Costa <wander@redhat.com>; Isaku Yamahata <isaku.yamahata@gmail.com>; > marcelo.cerri@canonical.com; tim.gardner@canonical.com; > khalid.elmously@canonical.com; Cox, Philip <philip.cox@canonical.com>; LKML > <linux-kernel@vger.kernel.org>; Yao, Jiewen <jiewen.yao@intel.com> > Subject: Re: [PATCH v8 2/5] x86/tdx: Add TDX Guest event notify interrupt > support > > Replying to this (not the latest one) to reduce the quoting levels, adding Jiewen. > > > > On Jun 20, 2022, at 8:44 AM, Sathyanarayanan Kuppuswamy > <sathyanarayanan.kuppuswamy@linux.intel.com> wrote: > > > > Hi, > > > > + Jun > > > > On 6/20/22 5:33 AM, Kai Huang wrote: > >> On Wed, 2022-06-08 at 19:52 -0700, Kuppuswamy Sathyanarayanan wrote: > >>> Host-guest event notification via configured interrupt vector is useful > >>> in cases where a guest makes an asynchronous request and needs a > >>> callback from the host to indicate the completion or to let the host > >>> notify the guest about events like device removal. One usage example is, > >>> callback requirement of GetQuote asynchronous hypercall. > >> > >> Although this paragraph is from GHCI spec, IMHO it is not very helpful. In > >> fact, I think this paragraph is not that right and should be removed from GHCI. > >> The reason is such event notification from VMM in cases like "device > removal" is > >> too vague. There's no _specification_ in GHCI around which "device > removal" > >> should VMM inject such event. For instance, I _think_ the Qemu enumerated > ACPI- > >> based hotplug should continue to work in TD. > > > > Yes. It just says that it *can* be used to signal a device removal. It is just > > an example for where it can be used. But I agree that such a use case is vague. > > If it makes it better, I am fine with removing it. > > Yes, the “device removal” is just an example, especially, "the TD OS should be > designed to not use the event notification for trusted operations”, based on the > context of the spec. > > >> > >>> > >>> Reserve 0xec IRQ vector address for TDX guest to receive the event > >>> completion notification from VMM. Also add related IDT handler to > >>> process the notification event. > >> > >> Here lacks why we need to choose to reserve a system vector. For instance, > why > >> we cannot choose to use device IRQ way which only requires one vector on > one > > > > As you have explained below, as per current spec, it just expects a system > > vector. > > > >> cpu. As you can see reserving a system vector isn't ideal especially for > >> attestation as it is not a frequent operation. It is wasteful of using IRQ > > > > I agree that event notification is currently only used for attestation. But I > > think in future there could be other use cases for it. If the intention is just > > to use it for attestation, then we can just modify the GetQuote TDVMCALL to > pass > > the vector address, and there is no need for new TDVMCALL. I think the > intention > > here is to have generic method for VMM to notify TD about some events. I am > not > > clear about the possible future use cases, so I cannot comment on frequency > of > > its use. > > > > Jun, any comments? > > > > The GHCI spec was not just clear, and we’ll update the spec, for example: > > 3.5 TDG.VP.VMCALL<SetupEventNotifyInterrupt> > ... > From: > > “The host VMM should use SEAMCALL [TDWRVPS] leaf to inject an interrupt at > the requested-interrupt vector into the TD via the posted-interrupt descriptor. “ > > To: > > “The host VMM should use SEAMCALL [TDWRVPS] leaf to inject an interrupt at > the requested-interrupt vector into the TD VCPU that executed TDG.VP.VMCALL > <SetupEventNotifyInterrupt>, via the posted-interrupt descriptor. “ > > --- > Jun
| |