Re: [PATCH v8 2/5] x86/tdx: Add TDX Guest event notify interrupt support

["Nakajima, Jun" <jun.nakajima@intel.com>]

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