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.
Or are there no similar TDX solutions planned where the guest runs
unmodified and under a paravisor?
> 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.
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquette
