From: Borislav Petkov <bp@alien8.de> Sent: Friday, February 10, 2023 11:04 AM

On Fri, Feb 10, 2023 at 06:41:54PM +0000, Sean Christopherson wrote:

quoted

Anyways, tying things back to the actual code being discussed, I vote against
CC_ATTR_PARAVISOR.  Being able to trust device emulation is not unique to a
paravisor.  A single flag also makes too many assumptions about what is trusted
and thus should be accessed encrypted.

I'm not crazy about the alternative either: one flag per access type:
IO APIC, vTPM, and soon.

FWIW, I don't think the list of devices to be accessed encrypted is likely
to grow significantly.  Is one or two more possible?  Perhaps.  Does it
become a list of ten?  I doubt it.

One approach is to go with the individual device attributes for now.
If the list does grow significantly, there will probably be patterns
or groupings that we can't discern now.  We could restructure into
larger buckets at that point based on those patterns/groupings.

Michael

Soon this will become an unmaintainable zoo of different guest types
people want the kernel to support. I don't think I want that madness in
kernel proper.