On 3/23/2023 5:34 PM, Borislav Petkov wrote: > On Thu, Mar 23, 2023 at 05:11:26PM +0100, Jeremi Piotrowski wrote: >> That same interface is exposed by physical hardware+firmware to the underlying >> Hyper-V. > > Let me see if I understand it correctly: Hyper-V *baremetal* is using > the same ASPT spec to to talk to the *physical* PSP device? > Yes > Is that ASPT interface to talk to the PSP used by the L0 hypervisor? > Yes (unless I am mistaken, this is the same statement as above). > Or does the L0 HV have a normal driver, similar to the Linux one, > without the functionality this ASPT spec provides? > The L0 HV relies on the ASPT spec/interface to map registers and setup interrupts and then uses a protocol driver to handle the PSP command set (like the Linux one). >> So it wasn't a matter of Microsoft architects coming up with a >> guest-host interface but rather exposing the virtual hardware in the same >> way as on a physical server. > > So if you want to expose the same interface to the L1 guest, why isn't > Hyper-V emulating an ACPI device just like any other functionality? Why > does it need to reach into the interrupt handling internals? > The primary stack for nested SNP support is Hyper-V-on-Hyper-V. By exposing the PSP device to the L1 guest in the same way (as the L0), everything can done in the exact same way as on bare-metal. I just really want nested SNP support to work in KVM-on-Hyper-V as well so that's why I'm adding support for these things. Also: if Linux were to run bare-metal on that hardware it would need to be able to handle the PSP through the ASPT interface as well. > I'd expect that the L0 HV would emulate a PSP device, the L1 would > simply load the Linux PSP device driver and everything should just work. > > What's the point of that alternate access at all? > So it's actually great that you made me ask around because I learned something that will help: Since the AMD PSP is a privileged device, there is a desire to not have to trust the ACPI stack, and instead rely fully on static ACPI tables for discovery and configuration. This also applies to the AMD IOMMU. If you look at iommu_setup_intcapxt() in drivers/iommu/amd/init.c, it does exactly the things that are needed to setup the PSP interrupt too. Here's a link to the patch that added that: https://lore.kernel.org/all/20201111144322.1659970-3-dwmw2@xxxxxxxxxxxxx/#t So my plan now is to post a v4 with proper irq_domain handling. Ok Thomas? Best wishes, Jeremi
