| Message ID | 20250218172500.807733-5-tabba@google.com (mailing list archive) |
|---|---|
| State | Superseded |
| Headers | show |
| Series | KVM: Mapping guest_memfd backed memory at the host for software protected VMs | expand |
On Tue, Feb 18, 2025 at 05:24:54PM +0000, Fuad Tabba wrote: > Add the KVM capability KVM_CAP_GMEM_SHARED_MEM, which indicates > that the VM supports shared memory in guest_memfd, or that the > host can create VMs that support shared memory. Supporting shared > memory implies that memory can be mapped when shared with the > host. > > Signed-off-by: Fuad Tabba <tabba@google.com> > --- > include/uapi/linux/kvm.h | 1 + > virt/kvm/kvm_main.c | 4 ++++ > 2 files changed, 5 insertions(+) > > diff --git a/include/uapi/linux/kvm.h b/include/uapi/linux/kvm.h > index 45e6d8fca9b9..117937a895da 100644 > --- a/include/uapi/linux/kvm.h > +++ b/include/uapi/linux/kvm.h > @@ -929,6 +929,7 @@ struct kvm_enable_cap { > #define KVM_CAP_PRE_FAULT_MEMORY 236 > #define KVM_CAP_X86_APIC_BUS_CYCLES_NS 237 > #define KVM_CAP_X86_GUEST_MODE 238 > +#define KVM_CAP_GMEM_SHARED_MEM 239 I think SHARED_MEM is ok. Said that, to me the use case in this series is more about "in-place" rather than "shared". In comparison, what I'm recently looking at is a "more" shared mode of guest-memfd where it works almost like memfd. So all pages will be shared there. That helps me e.g. for the N:1 kvm binding issue I mentioned in another email (in one of my relies in previous version), in which case I want to enable gmemfd folios to be mapped more than once in a process. That'll work there as long as it's fully shared, because all things can be registered in the old VA way, then there's no need to have N:1 restriction. IOW, gmemfd will still rely on mmu notifier for tearing downs, and the gmem->bindings will always be empty. So if this one would be called "in-place", then I'll have my use case as "shared". I don't want to add any burden to your series, I think I can still make that one "shared-full".. So it's more of a pure comment just in case you also think "in-place" suites more, or any name you think can identify "in-place conversions" use case and "complete sharable" use cases. Please also feel free to copy me for newer posts. I'd be more than happy to know when gmemfd will have a basic fault() function. Thanks,
Hi Peter, On Fri, 28 Feb 2025 at 08:24, Peter Xu <peterx@redhat.com> wrote: > > On Tue, Feb 18, 2025 at 05:24:54PM +0000, Fuad Tabba wrote: > > Add the KVM capability KVM_CAP_GMEM_SHARED_MEM, which indicates > > that the VM supports shared memory in guest_memfd, or that the > > host can create VMs that support shared memory. Supporting shared > > memory implies that memory can be mapped when shared with the > > host. > > > > Signed-off-by: Fuad Tabba <tabba@google.com> > > --- > > include/uapi/linux/kvm.h | 1 + > > virt/kvm/kvm_main.c | 4 ++++ > > 2 files changed, 5 insertions(+) > > > > diff --git a/include/uapi/linux/kvm.h b/include/uapi/linux/kvm.h > > index 45e6d8fca9b9..117937a895da 100644 > > --- a/include/uapi/linux/kvm.h > > +++ b/include/uapi/linux/kvm.h > > @@ -929,6 +929,7 @@ struct kvm_enable_cap { > > #define KVM_CAP_PRE_FAULT_MEMORY 236 > > #define KVM_CAP_X86_APIC_BUS_CYCLES_NS 237 > > #define KVM_CAP_X86_GUEST_MODE 238 > > +#define KVM_CAP_GMEM_SHARED_MEM 239 > > I think SHARED_MEM is ok. Said that, to me the use case in this series is > more about "in-place" rather than "shared". > > In comparison, what I'm recently looking at is a "more" shared mode of > guest-memfd where it works almost like memfd. So all pages will be shared > there. > > That helps me e.g. for the N:1 kvm binding issue I mentioned in another > email (in one of my relies in previous version), in which case I want to > enable gmemfd folios to be mapped more than once in a process. > > That'll work there as long as it's fully shared, because all things can be > registered in the old VA way, then there's no need to have N:1 restriction. > IOW, gmemfd will still rely on mmu notifier for tearing downs, and the > gmem->bindings will always be empty. > > So if this one would be called "in-place", then I'll have my use case as > "shared". I understand what you mean. The naming here is to be consistent with the rest of the series. I don't really have a strong opinion. It means SHARED_IN_PLACE, but then that would be a mouthful. :) > I don't want to add any burden to your series, I think I can still make > that one "shared-full".. So it's more of a pure comment just in case you > also think "in-place" suites more, or any name you think can identify > "in-place conversions" use case and "complete sharable" use cases. > > Please also feel free to copy me for newer posts. I'd be more than happy > to know when gmemfd will have a basic fault() function. I definitely will. Thanks for your comments. Cheers, /fuad > Thanks, > > -- > Peter Xu >
On 28.02.25 18:22, Fuad Tabba wrote: > Hi Peter, > > On Fri, 28 Feb 2025 at 08:24, Peter Xu <peterx@redhat.com> wrote: >> >> On Tue, Feb 18, 2025 at 05:24:54PM +0000, Fuad Tabba wrote: >>> Add the KVM capability KVM_CAP_GMEM_SHARED_MEM, which indicates >>> that the VM supports shared memory in guest_memfd, or that the >>> host can create VMs that support shared memory. Supporting shared >>> memory implies that memory can be mapped when shared with the >>> host. >>> >>> Signed-off-by: Fuad Tabba <tabba@google.com> >>> --- >>> include/uapi/linux/kvm.h | 1 + >>> virt/kvm/kvm_main.c | 4 ++++ >>> 2 files changed, 5 insertions(+) >>> >>> diff --git a/include/uapi/linux/kvm.h b/include/uapi/linux/kvm.h >>> index 45e6d8fca9b9..117937a895da 100644 >>> --- a/include/uapi/linux/kvm.h >>> +++ b/include/uapi/linux/kvm.h >>> @@ -929,6 +929,7 @@ struct kvm_enable_cap { >>> #define KVM_CAP_PRE_FAULT_MEMORY 236 >>> #define KVM_CAP_X86_APIC_BUS_CYCLES_NS 237 >>> #define KVM_CAP_X86_GUEST_MODE 238 >>> +#define KVM_CAP_GMEM_SHARED_MEM 239 >> >> I think SHARED_MEM is ok. Said that, to me the use case in this series is >> more about "in-place" rather than "shared". >> >> In comparison, what I'm recently looking at is a "more" shared mode of >> guest-memfd where it works almost like memfd. So all pages will be shared >> there. >> >> That helps me e.g. for the N:1 kvm binding issue I mentioned in another >> email (in one of my relies in previous version), in which case I want to >> enable gmemfd folios to be mapped more than once in a process. >> >> That'll work there as long as it's fully shared, because all things can be >> registered in the old VA way, then there's no need to have N:1 restriction. >> IOW, gmemfd will still rely on mmu notifier for tearing downs, and the >> gmem->bindings will always be empty. >> >> So if this one would be called "in-place", then I'll have my use case as >> "shared". > > I understand what you mean. The naming here is to be consistent with > the rest of the series. I don't really have a strong opinion. It means > SHARED_IN_PLACE, but then that would be a mouthful. :) I'll note that Patrick is also driving it in "all shared" mode for his direct-map removal series IIRC. So we would have a) All private b) Mixing of private and shared (incl conversion) c) All shared "IN_PLACE" might be the wrong angle to look at it.
diff --git a/include/uapi/linux/kvm.h b/include/uapi/linux/kvm.h index 45e6d8fca9b9..117937a895da 100644 --- a/include/uapi/linux/kvm.h +++ b/include/uapi/linux/kvm.h @@ -929,6 +929,7 @@ struct kvm_enable_cap { #define KVM_CAP_PRE_FAULT_MEMORY 236 #define KVM_CAP_X86_APIC_BUS_CYCLES_NS 237 #define KVM_CAP_X86_GUEST_MODE 238 +#define KVM_CAP_GMEM_SHARED_MEM 239 struct kvm_irq_routing_irqchip { __u32 irqchip; diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c index ba0327e2d0d3..38f0f402ea46 100644 --- a/virt/kvm/kvm_main.c +++ b/virt/kvm/kvm_main.c @@ -4830,6 +4830,10 @@ static int kvm_vm_ioctl_check_extension_generic(struct kvm *kvm, long arg) #ifdef CONFIG_KVM_PRIVATE_MEM case KVM_CAP_GUEST_MEMFD: return !kvm || kvm_arch_has_private_mem(kvm); +#endif +#ifdef CONFIG_KVM_GMEM_SHARED_MEM + case KVM_CAP_GMEM_SHARED_MEM: + return !kvm || kvm_arch_gmem_supports_shared_mem(kvm); #endif default: break;
Add the KVM capability KVM_CAP_GMEM_SHARED_MEM, which indicates that the VM supports shared memory in guest_memfd, or that the host can create VMs that support shared memory. Supporting shared memory implies that memory can be mapped when shared with the host. Signed-off-by: Fuad Tabba <tabba@google.com> --- include/uapi/linux/kvm.h | 1 + virt/kvm/kvm_main.c | 4 ++++ 2 files changed, 5 insertions(+)