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 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.
