| Message ID | 20231108111806.92604-26-nsaenz@amazon.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | KVM: x86: hyperv: Introduce VSM support | expand |
On 08.11.23 12:17, Nicolas Saenz Julienne wrote: > Introduce the following memory attributes: > - KVM_MEMORY_ATTRIBUTE_READ > - KVM_MEMORY_ATTRIBUTE_WRITE > - KVM_MEMORY_ATTRIBUTE_EXECUTE > - KVM_MEMORY_ATTRIBUTE_NO_ACCESS > > Note that NO_ACCESS is necessary in order to make a distinction between > the lack of attributes for a gfn, which defaults to the memory > protections of the backing memory, versus explicitly prohibiting any > access to that gfn. If we negate the attributes (no read, no write, no execute), we can keep 0 == default and 0b111 becomes "no access". Alex Amazon Development Center Germany GmbH Krausenstr. 38 10117 Berlin Geschaeftsfuehrung: Christian Schlaeger, Jonathan Weiss Eingetragen am Amtsgericht Charlottenburg unter HRB 149173 B Sitz: Berlin Ust-ID: DE 289 237 879
On Wed, Nov 08, 2023, Alexander Graf wrote: > > On 08.11.23 12:17, Nicolas Saenz Julienne wrote: > > Introduce the following memory attributes: > > - KVM_MEMORY_ATTRIBUTE_READ > > - KVM_MEMORY_ATTRIBUTE_WRITE > > - KVM_MEMORY_ATTRIBUTE_EXECUTE > > - KVM_MEMORY_ATTRIBUTE_NO_ACCESS > > > > Note that NO_ACCESS is necessary in order to make a distinction between > > the lack of attributes for a gfn, which defaults to the memory > > protections of the backing memory, versus explicitly prohibiting any > > access to that gfn. > > > If we negate the attributes (no read, no write, no execute), we can keep 0 > == default and 0b111 becomes "no access". Yes, I suggested this in the initial discussion[*]. I think it makes sense to have the uAPI flags have positive polarity, i.e. as above, but internally we can invert things so that the default 000b gives full RWX protections. Or we could make the push for a range-based xarray implementation so that storing 111b for all gfns is super cheap. Regardless of how KVM stores the information internally, there's no need for a NO_ACCESS flag in the uAPI. [*] https://lore.kernel.org/all/ZGfUqBLaO+cI9ypv@google.com
diff --git a/include/uapi/linux/kvm.h b/include/uapi/linux/kvm.h index bd97c9852142..6b875c1040eb 100644 --- a/include/uapi/linux/kvm.h +++ b/include/uapi/linux/kvm.h @@ -2314,7 +2314,11 @@ struct kvm_memory_attributes { __u64 flags; }; +#define KVM_MEMORY_ATTRIBUTE_READ (1ULL << 0) +#define KVM_MEMORY_ATTRIBUTE_WRITE (1ULL << 1) +#define KVM_MEMORY_ATTRIBUTE_EXECUTE (1ULL << 2) #define KVM_MEMORY_ATTRIBUTE_PRIVATE (1ULL << 3) +#define KVM_MEMORY_ATTRIBUTE_NO_ACCESS (1ULL << 4) #define KVM_CREATE_GUEST_MEMFD _IOWR(KVMIO, 0xd4, struct kvm_create_guest_memfd)
Introduce the following memory attributes: - KVM_MEMORY_ATTRIBUTE_READ - KVM_MEMORY_ATTRIBUTE_WRITE - KVM_MEMORY_ATTRIBUTE_EXECUTE - KVM_MEMORY_ATTRIBUTE_NO_ACCESS Note that NO_ACCESS is necessary in order to make a distinction between the lack of attributes for a gfn, which defaults to the memory protections of the backing memory, versus explicitly prohibiting any access to that gfn. These new memory attributes will, for now, only made be available through the VSM KVM device (which we introduce in subsequent patches). Signed-off-by: Nicolas Saenz Julienne <nsaenz@amazon.com> --- include/uapi/linux/kvm.h | 4 ++++ 1 file changed, 4 insertions(+)