Hi, On Fri, 13 Mar 2026 at 00:36, Sean Christopherson <[email protected]> wrote: > > On Thu, Mar 12, 2026, Ackerley Tng wrote: > > Sean Christopherson <[email protected]> writes: > > > > > On Thu, Mar 12, 2026, Fuad Tabba wrote: > > >> Hi Ackerley, > > >> > > >> Before getting into the UAPI semantics, thank you for all the heavy > > >> lifting you've done here. Figuring out how to make it all work across > > >> the different platforms is not easy :) > > >> > > >> <snip> > > >> > > >> > The policy definitions below provide more details: > > > > > > Please drop "CONTENT_POLICY" from the KVM documentation. From KVM's > > > perspective, > > > these are not "policy", they are purely properties of the underlying > > > memory. > > > Userspace will likely use the attributes to implement policy of some > > > kind, but > > > KVM straight up doesn't care. > > > > Policy might have been the wrong word. I think this is a property of the > > conversion process/request, not a property of the memory like how > > shared/private is a property of the memory? > > > > I'll have to find another word to describe this enum of > > Or just don't? I'm 100% serious, because unless we carve out a field _just_ > for > these two flags, they're eventually going to get mixed with other stuff. At > that > point, having a precisely named enum container just gets in the way.
I agree. It makes sense to drop the enum wrapper and the "policy" terminology entirely. Let's go with direct flags passed to the ioctl representing the requested memory properties upon conversion. > > I see you dropped any documentation to do with testing. > > Yes. > > > I meant to document it (at least something about the unspecified case) so it > > can be relied on in selftests, with the understanding (already specified > > elsewhere in Documentation/virt/kvm/api.rst) that nothing about > > KVM_X86_SW_PROTECTED_VM is to be relied on in production, and can be changed > > anytime. What do you think? > > KVM_X86_SW_PROTECTED_VM should self-report like all other VM types, and > shouldn't > support anything that isn't documented as possible. I.e. we shouldn't allow > ZERO on shared=>private "for testing". > > What I do think we should do is scribble memory on conversions without ZERO or > PRIVATE, probably guarded by a Kconfig or maybe a module param, to do a best > effort enforcement of the ABI, i.e. to try and prevent userspace from > depending > on uarch/vendor specific behavior. I strongly agree with scribbling/poisoning the memory on default conversions. If userspace specifies neither flag, actively destroying the data in software is the only way to strictly enforce that the ABI makes no guarantees, preventing the VMM from implicitly relying on underlying hardware behavior (like TDX automatically zeroing). Cheers, /fuad
