On 2/11/25 14:32, Borislav Petkov wrote: > On Tue, Feb 11, 2025 at 09:43:23AM -0800, Sean Christopherson wrote: >> It conflates two very different things: host/bare metal support for memory >> encryption, and SEV guest support. For kernels that will never run in a VM, >> pulling in all the SEV guest code just to enable host-side support for SME (and >> SEV) is very undesirable. > > Well, that might've grown in the meantime... when we started it, it was all > small so it didn't really matter and we kept it simple. That's why I never > thought about it. And actually, we've been thinking of even ripping out SME > in favor of TSME which is transparent and doesn't need any SME glue. But there > was some reason why we didn't want to do it yet, Tom would know. I think it was because TSME is a BIOS setting and you don't trust BIOS to always expose the setting :) I do have a patch series to remove SME. I haven't updated it in a couple of releases, so would just need to dust it off and rebase it. Thanks, Tom > > As to carving it out now, meh, dunno how much savings that would be. Got > a student to put on that task? :-P > >> And in this case, because AMD_MEM_ENCRYPT gates both host and guest code, it >> can't depend on HYPERVISOR_GUEST like it should, because taking a dependency on >> HYPERVISOR_GUEST to enable SME is obviously wrong. > > Right. >
