Interrupt support for confidential VMs

[vijaydhanraj]

In order to support confidential VMs like a TD partitioned guest the following missing features maybe needed in SVSM. Idea is to try keep the implementation platform agnostic.

• Implement interrupt support in SVSM
  • Add LAPIC driver
  • Setup Interrupt infrastructure (entrypoint, registration etc.)
    • Start with IPI?
• Add vLAPIC support for guest in SVSM
• Add vIOAPIC support for guest in SVSM

Are there any plans to implement these features? If so, happy to collaborate and validate on x86 platform.
If not, is this something that I can help with?

[joergroedel]

As discussed in the SVSM call on April 24th, we are starting an effort to get IRQ infrastructure into the SVSM code-base.

• The starting point is an X2APIC driver. Support for MMIO-mapped legacy LAPIC is not needed, unless someone comes up with a good reason to do that.
• Based on the X2APIC driver the IRQ infrastructure can be built. Entry code is ready for that, what is missing is a registration interface for IRQ handlers to implement IPI functionality.
• Once there is a defined HV protocol to signal IRQs to L2, implement the vLAPIC emulation in SVSM for L2 guests.

I don't see a need for vIOAPIC emulation, are there reasons this is absolutely needed?

[dongyaozu]

Before the detail implementation discussion, can we clarify the usage of APIC in L2 ? I see we may support 2 cases: 1) Enlightened APIC driver in L2 (which can probably fully remove IOAPIC usage, 2) unmodified L2 OSes such as Linux today: should we support unmodified OS kernel on top of coconut? If YES, the unmodified L2 kernel may use both IOAPIC/LAPIC --- Of course, we can emulate IOAPIC in host VMM or in L1 coconut.

Personally, I think coconut should support broad usage of L2 OSes including both enlightened kernel and unmodified kernel. Can Joerg calrify?

[joergroedel]

Before the detail implementation discussion, can we clarify the usage of APIC in L2 ? I see we may support 2 cases: 1) Enlightened APIC driver in L2 (which can probably fully remove IOAPIC usage, 2) unmodified L2 OSes such as Linux today: should we support unmodified OS kernel on top of coconut? If YES, the unmodified L2 kernel may use both IOAPIC/LAPIC --- Of course, we can emulate IOAPIC in host VMM or in L1 coconut.

Personally, I think coconut should support broad usage of L2 OSes including both enlightened kernel and unmodified kernel. Can Joerg calrify?

I agree that the target is to support enlightened and unenlightened OSes. For now the plan has been to keep the IOAPIC in the host hypervisor, as there will be no separate IOAPIC per partition and the accesses from the L2 to the IOAPIC will be passed through to the host. If there is a good reason to have an emulation in COCONUT, then we can discuss it.

[vijaydhanraj]

Thanks @joergroedel for the clarifications on X2APIC driver and the vIOAPIC. Also, I assume for the vLAPIC implementation we are looking at full vLAPIC emulation as we want to support both unenlightened as well as enlightened guests. Is my understanding correct?
Regarding the HV protocol to signal IRQs to L2, is there something draft version already available? If so, can you please share it?

[joergroedel]

Hi @vijaydhanraj, yes, a full emulation for vX2APIC is deserved. Not sure if we need to support vLAPIC as a fall-back. The specification is currently being worked on, we will share it when it is ready.

[dongyaozu]

To emulate full vX2APIC, the L1 SVSM and L2 VM interface is naturally following X2APIC spec. But we need to define a hardware neutral interface between L0 and L1. Is this the specification being worked on? If yes, I suggest we build on top of industry standard virtio interface? Any thoughts?

[vijaydhanraj]

Hi @vijaydhanraj, yes, a full emulation for vX2APIC is deserved. Not sure if we need to support vLAPIC as a fall-back. The specification is currently being worked on, we will share it when it is ready.

When you say vLAPIC, I think you are referring to vXAPIC mode right? If so, we may need to enable vXAPIC for the unenlightened guest as default LAPIC mode is XAPIC after reset (please see SDM 11.12.5.1). We can then switch to X2APIC by setting IA32_APIC_BASE[EXTD] =1 on x86 platforms.

[joergroedel]

When you say vLAPIC, I think you are referring to vXAPIC mode right? If so, we may need to enable vXAPIC for the unenlightened guest as default LAPIC mode is XAPIC after reset (please see SDM 11.12.5.1). We can then switch to X2APIC by setting IA32_APIC_BASE[EXTD] =1 on x86 platforms.

Okay, that makes sense. so a vXAPIC emulation is also needed (which in turn needs MMIO emulation).

[vijaydhanraj]

Yes correct. I think we are mostly aligned on the requirements. Only open is the hardware neutral interface between L0 and L1. As we wait for the interface, is it fine if can I start with initial LAPIC driver PR?

[vijaydhanraj]

Hi @msft-jlange we were planning to add a generic LAPIC driver supporting x2APIC mode in SVSM for IPIs, timer. Is this something you are currently working on as part of restricted injection support? If not, would it be ok for us to send a PR for this feature or should we wait?