From: Borislav Petkov <bp@xxxxxxxxx> Sent: Friday, February 10, 2023 11:04 AM > > On Fri, Feb 10, 2023 at 06:41:54PM +0000, Sean Christopherson wrote: > > 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. >
