On 30/11/20 19:14, Sean Christopherson wrote:
TDX also selectively blocks/skips portions of other ioctl()s so that the
TDX code itself can yell loudly if e.g. .get_cpl() is invoked. The event
injection restrictions are due to direct injection not being allowed (except
for NMIs); all IRQs have to be routed through APICv (posted interrupts) and
exception injection is completely disallowed.
kvm_vcpu_ioctl_x86_get_vcpu_events:
if (!vcpu->kvm->arch.guest_state_protected)
events->interrupt.shadow = kvm_x86_ops.get_interrupt_shadow(vcpu);
Perhaps an alternative implementation can enter the vCPU with immediate exit
until no events are pending, and then return all zeroes?
This can't work. If the guest has STI blocking, e.g. it did STI->TDVMCALL with
a valid vIRQ in GUEST_RVI, then events->interrupt.shadow should technically be
non-zero to reflect the STI blocking. But, the immediate exit (a hardware IRQ
for TDX guests) will cause VM-Exit before the guest can execute any instructions
and thus the guest will never clear STI blocking and never consume the pending
event. Or there could be a valid vIRQ, but GUEST_RFLAGS.IF=0, in which case KVM
would need to run the guest for an indeterminate amount of time to wait for the
vIRQ to be consumed.
Delayed interrupts are fine, since they are injected according to RVI
and the posted interrupt descriptor. I'm thinking more of events
(exceptions and interrupts) that caused an EPT violation exit and were
recorded in the IDT-vectored info field.
Paolo
Tangentially related, I haven't looked through the official external TDX docs,
but I suspect that vmcs.GUEST_RVI is listed as inaccessible for production TDs.
This will be changed as the VMM needs access to GUEST_RVI to handle
STI->TDVMCALL(HLT), otherwise the VMM may incorrectly put the vCPU into a
blocked (not runnable) state even though it has a pending wake event.
