From: Borislav Petkov <bp@xxxxxxxxx> Sent: Thursday, December 29, 2022 3:39 AM > > On Tue, Dec 06, 2022 at 07:54:02PM +0000, Michael Kelley (LINUX) wrote: > > Exactly correct. > > Ok, thanks. > > Let's put that in the commit message and get rid of the "subsequent > patch" wording as patch order in git is ambiguous. > > IOW, something like this: > > Current code always maps the IO-APIC as shared (decrypted) in a > confidential VM. But Hyper-V guest VMs on AMD SEV-SNP with vTOM enabled > use a paravisor running in VMPL0 to emulate the IO-APIC. > > In such a case, the IO-APIC must be accessed as private (encrypted) > because the paravisor emulates the IO-APIC in the lower half of the vTOM > where all accesses must be encrypted. > > Add a new CC attribute which determines how the IO-APIC MMIO mapping > should be established depending on the platform the kernel is running on > as a guest. > Works for me. I'll adopt this wording in v5. Michael
