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.
