RE: [PATCH v5 06/14] x86/ioremap: Support hypervisor specified range to map as encrypted

[Michael Kelley (LINUX)]

From: Borislav Petkov <bp@xxxxxxxxx> Sent: Tuesday, February 7, 2023 4:41 AM
> 
> On Thu, Feb 02, 2023 at 05:49:44AM +0000, Michael Kelley (LINUX) wrote:
> > I could do:
> > 1.  CC_ATTR_PARAVISOR_SPLIT_ADDRESS_SPACE, which is similar to
> >     what I had for v1 & v2.   At the time, somebody commented that
> >     this might be a bit too general.
> > 2.  Keep CC_ATTR_ACCESS_IOAPIC_ENCRYPTED and add
> >     CC_ATTR_ACCESS_TPM_ENCRYPTED, which would decouple them
> > 3.  CC_ATTR_ACCESS_IOAPIC_AND_TPM_ENCRYPTED, which is very
> >     narrow and specific.
> >
> > I have weak preference for #1 above, but I could go with any of them.
> > What's your preference?
> 
> Either 1. but a shorter name or something which works with the TDX side
> too.

Unless there are objections, I'll go with CC_ATTR_PARAVISOR_DEVICES,
which is shorter.  The full details of the meaning will be in a comment
where this is defined with all the other CC_ATTR_* values.

> 
> Or are there no similar TDX solutions planned where the guest runs
> unmodified and under a paravisor?

The TDX plans are still being sorted out.  But if we end up with such
an approach, CC_ATTR_PARAVISOR_DEVICES will be correct for TDX
also.

Michael

> 
> > For v6 of the patch series, I've coded devm_ioremap_resource_enc() to call
> > __devm_ioremap(), which then calls ioremap_encrypted().  I've updated the
> > TPM driver to use cc_platform_has() with whatever attribute name we agree
> > on to decide between devm_ioremap_resource_enc() and
> > devm_ioremap_resource().
> >
> > If this approach is OK with the TPM driver maintainers, I'm good with it.
> > More robust handling of a mix of encrypted and decrypted devices can get
> > sorted out later.
> 
> Makes sense to me...
> 
> Thx.