diff mbox series

[v2,02/12] x86/ioapic: Gate decrypted mapping on cc_platform_has() attribute

Message ID 1668147701-4583-3-git-send-email-mikelley@microsoft.com
State New
Headers
Series Drivers: hv: Add PCI pass-thru support to Hyper-V Confidential VMs |

Commit Message

Michael Kelley (LINUX) Nov. 11, 2022, 6:21 a.m. UTC 
  Current code always maps the IOAPIC 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 IOAPIC.
In such a case, the IOAPIC must be accessed as private (encrypted).

Fix this by gating the IOAPIC decrypted mapping on a new
cc_platform_has() attribute that a subsequent patch in the series
will set only for Hyper-V guests. The new attribute is named
somewhat generically because similar paravisor emulation cases
may arise in the future.

Signed-off-by: Michael Kelley <mikelley@microsoft.com>
Reviewed-by: Wei Liu <wei.liu@kernel.org>
---
 arch/x86/kernel/apic/io_apic.c |  3 ++-
 include/linux/cc_platform.h    | 13 +++++++++++++
 2 files changed, 15 insertions(+), 1 deletion(-)

Comments

Dave Hansen Nov. 12, 2022, 12:21 a.m. UTC | #1 
On 11/10/22 22:21, Michael Kelley wrote:
>  	 * Ensure fixmaps for IOAPIC MMIO respect memory encryption pgprot
>  	 * bits, just like normal ioremap():
>  	 */
> -	flags = pgprot_decrypted(flags);
> +	if (!cc_platform_has(CC_ATTR_HAS_PARAVISOR))
> +		flags = pgprot_decrypted(flags);

This begs the question whether *all* paravisors will want to avoid a
decrypted ioapic mapping.  Is this _fundamental_ to paravisors, or it is
an implementation detail of this _individual_ paravisor?
Michael Kelley (LINUX) Nov. 12, 2022, 4:48 a.m. UTC | #2 
From: Dave Hansen <dave.hansen@intel.com> Sent: Friday, November 11, 2022 4:22 PM
> 
> On 11/10/22 22:21, Michael Kelley wrote:
> >  	 * Ensure fixmaps for IOAPIC MMIO respect memory encryption pgprot
> >  	 * bits, just like normal ioremap():
> >  	 */
> > -	flags = pgprot_decrypted(flags);
> > +	if (!cc_platform_has(CC_ATTR_HAS_PARAVISOR))
> > +		flags = pgprot_decrypted(flags);
> 
> This begs the question whether *all* paravisors will want to avoid a
> decrypted ioapic mapping.  Is this _fundamental_ to paravisors, or it is
> an implementation detail of this _individual_ paravisor?

Hard to say.  The paravisor that Hyper-V provides for use with the vTOM
option in a SEV SNP VM is the only paravisor I've seen.  At least as defined
by Hyper-V and AMD SNP Virtual Machine Privilege Levels (VMPLs), the
paravisor resides within the VM trust boundary.  Anything that a paravisor
emulates would be in the "private" (i.e., encrypted) memory so it can be
accessed by both the guest OS and the paravisor.  But nothing fundamental
says that IOAPIC emulation *must* be done in the paravisor.

I originally though about naming this attribute HAS_EMULATED_IOAPIC, but
that felt a bit narrow as other emulated hardware might need similar treatment
in the future, at least with the Hyper-V and AMD SEV SNP vTOM paravisor.

Net, we currently have N=1 for paravisors, and we won't know what the more
generalized case looks like until N >= 2.  If/when that happens, additional logic
might be needed here, and the name of this attribute might need adjustment
to support broader usage.  But if there's consensus on a different name now,
or on the narrower HAS_EMULATED_IOAPIC name, it doesn’t really matter
to me.

Michael
Dave Hansen Nov. 14, 2022, 4:23 p.m. UTC | #3 
On 11/11/22 20:48, Michael Kelley (LINUX) wrote:
> From: Dave Hansen <dave.hansen@intel.com> Sent: Friday, November 11, 2022 4:22 PM
>> On 11/10/22 22:21, Michael Kelley wrote:
>>>  	 * Ensure fixmaps for IOAPIC MMIO respect memory encryption pgprot
>>>  	 * bits, just like normal ioremap():
>>>  	 */
>>> -	flags = pgprot_decrypted(flags);
>>> +	if (!cc_platform_has(CC_ATTR_HAS_PARAVISOR))
>>> +		flags = pgprot_decrypted(flags);
>> This begs the question whether *all* paravisors will want to avoid a
>> decrypted ioapic mapping.  Is this _fundamental_ to paravisors, or it is
>> an implementation detail of this _individual_ paravisor?
> Hard to say.  The paravisor that Hyper-V provides for use with the vTOM
> option in a SEV SNP VM is the only paravisor I've seen.  At least as defined
> by Hyper-V and AMD SNP Virtual Machine Privilege Levels (VMPLs), the
> paravisor resides within the VM trust boundary.  Anything that a paravisor
> emulates would be in the "private" (i.e., encrypted) memory so it can be
> accessed by both the guest OS and the paravisor.  But nothing fundamental
> says that IOAPIC emulation *must* be done in the paravisor.

Please just make this check more specific.  Either make this a specific
Hyper-V+SVM check, or rename it HAS_EMULATED_IOAPIC, like you were
thinking.  If paravisors catch on and we end up with ten more of these
things across five different paravisors and see a pattern, *then* a
paravisor-specific one makes sense.
Michael Kelley (LINUX) Nov. 14, 2022, 4:54 p.m. UTC | #4 
From: Dave Hansen <dave.hansen@intel.com> Sent: Monday, November 14, 2022 8:23 AM
> 
> On 11/11/22 20:48, Michael Kelley (LINUX) wrote:
> > From: Dave Hansen <dave.hansen@intel.com> Sent: Friday, November 11, 2022 4:22
> PM
> >> On 11/10/22 22:21, Michael Kelley wrote:
> >>>  	 * Ensure fixmaps for IOAPIC MMIO respect memory encryption pgprot
> >>>  	 * bits, just like normal ioremap():
> >>>  	 */
> >>> -	flags = pgprot_decrypted(flags);
> >>> +	if (!cc_platform_has(CC_ATTR_HAS_PARAVISOR))
> >>> +		flags = pgprot_decrypted(flags);
> >> This begs the question whether *all* paravisors will want to avoid a
> >> decrypted ioapic mapping.  Is this _fundamental_ to paravisors, or it is
> >> an implementation detail of this _individual_ paravisor?
> > Hard to say.  The paravisor that Hyper-V provides for use with the vTOM
> > option in a SEV SNP VM is the only paravisor I've seen.  At least as defined
> > by Hyper-V and AMD SNP Virtual Machine Privilege Levels (VMPLs), the
> > paravisor resides within the VM trust boundary.  Anything that a paravisor
> > emulates would be in the "private" (i.e., encrypted) memory so it can be
> > accessed by both the guest OS and the paravisor.  But nothing fundamental
> > says that IOAPIC emulation *must* be done in the paravisor.
> 
> Please just make this check more specific.  Either make this a specific
> Hyper-V+SVM check, or rename it HAS_EMULATED_IOAPIC, like you were
> thinking.  If paravisors catch on and we end up with ten more of these
> things across five different paravisors and see a pattern, *then* a
> paravisor-specific one makes sense.

I'm good with that.  I'll use HAS_EMULATED_IOAPIC in v3.

Michael
diff mbox series

Patch

diff --git a/arch/x86/kernel/apic/io_apic.c b/arch/x86/kernel/apic/io_apic.c
index a868b76..d2c1bf7 100644
--- a/arch/x86/kernel/apic/io_apic.c
+++ b/arch/x86/kernel/apic/io_apic.c
@@ -2686,7 +2686,8 @@  static void io_apic_set_fixmap(enum fixed_addresses idx, phys_addr_t phys)
 	 * Ensure fixmaps for IOAPIC MMIO respect memory encryption pgprot
 	 * bits, just like normal ioremap():
 	 */
-	flags = pgprot_decrypted(flags);
+	if (!cc_platform_has(CC_ATTR_HAS_PARAVISOR))
+		flags = pgprot_decrypted(flags);
 
 	__set_fixmap(idx, phys, flags);
 }
diff --git a/include/linux/cc_platform.h b/include/linux/cc_platform.h
index cb0d6cd..b6c4a79 100644
--- a/include/linux/cc_platform.h
+++ b/include/linux/cc_platform.h
@@ -90,6 +90,19 @@  enum cc_attr {
 	 * Examples include TDX Guest.
 	 */
 	CC_ATTR_HOTPLUG_DISABLED,
+
+	/**
+	 * @CC_ATTR_HAS_PARAVISOR: Guest VM is running with a paravisor
+	 *
+	 * The platform/OS is running as a guest/virtual machine with
+	 * a paravisor in VMPL0. Having a paravisor affects things
+	 * like whether the I/O APIC is emulated and operates in the
+	 * encrypted or decrypted portion of the guest physical address
+	 * space.
+	 *
+	 * Examples include Hyper-V SEV-SNP guests using vTOM.
+	 */
+	CC_ATTR_HAS_PARAVISOR,
 };
 
 #ifdef CONFIG_ARCH_HAS_CC_PLATFORM