| Message ID | 20250122152738.1173160-1-tabba@google.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | KVM: Mapping of guest_memfd at the host and a software protected VM type | expand |
On 22.01.25 16:27, Fuad Tabba wrote: > The purpose of this series is to serve as a potential base for > restricted mmap() support for guest_memfd [1]. It would allow > experimentation with what that support would be like, in the safe > environment of a new VM type used for testing. > > This series adds a new VM type for arm64, > KVM_VM_TYPE_ARM_SW_PROTECTED, analogous to the x86 > KVM_X86_SW_PROTECTED_VM. This type is to serve as a development > and testing vehicle for Confidential (CoCo) VMs. > > Similar to the x86 type, this is currently only for development > and testing. It's not meant to be used for "real" VMs, and > especially not in production. The behavior and effective ABI for > software-protected VMs is unstable. > > This series enables mmap() support for guest_memfd specifically > for the new software-protected VM type, only when explicitly > enabled in the config. Hi! IIUC, in this series, there is no "private" vs "shared" distinction, right? So all pages are mappable, and "conversion" does not exist?
On 22.01.25 16:35, David Hildenbrand wrote: > On 22.01.25 16:27, Fuad Tabba wrote: >> The purpose of this series is to serve as a potential base for >> restricted mmap() support for guest_memfd [1]. It would allow >> experimentation with what that support would be like, in the safe >> environment of a new VM type used for testing. >> >> This series adds a new VM type for arm64, >> KVM_VM_TYPE_ARM_SW_PROTECTED, analogous to the x86 >> KVM_X86_SW_PROTECTED_VM. This type is to serve as a development >> and testing vehicle for Confidential (CoCo) VMs. >> >> Similar to the x86 type, this is currently only for development >> and testing. It's not meant to be used for "real" VMs, and >> especially not in production. The behavior and effective ABI for >> software-protected VMs is unstable. >> >> This series enables mmap() support for guest_memfd specifically >> for the new software-protected VM type, only when explicitly >> enabled in the config. > > Hi! > > IIUC, in this series, there is no "private" vs "shared" distinction, > right? So all pages are mappable, and "conversion" does not exist? Ah, I spot: +#define kvm_arch_private_mem_inplace(kvm) \ + (IS_ENABLED(CONFIG_KVM_GMEM_MAPPABLE) && \ + ((kvm)->arch.vm_type & KVM_VM_TYPE_ARM_SW_PROTECTED)) Which makes me wonder, why don't we need the same way of making sure all references/mappings are gone (+ new page type) when doing the shared -> private conversion? Or is this somewhere in here where I didn't spot it yet?
Hi David, On Wed, 22 Jan 2025 at 15:41, David Hildenbrand <david@redhat.com> wrote: > > On 22.01.25 16:35, David Hildenbrand wrote: > > On 22.01.25 16:27, Fuad Tabba wrote: > >> The purpose of this series is to serve as a potential base for > >> restricted mmap() support for guest_memfd [1]. It would allow > >> experimentation with what that support would be like, in the safe > >> environment of a new VM type used for testing. > >> > >> This series adds a new VM type for arm64, > >> KVM_VM_TYPE_ARM_SW_PROTECTED, analogous to the x86 > >> KVM_X86_SW_PROTECTED_VM. This type is to serve as a development > >> and testing vehicle for Confidential (CoCo) VMs. > >> > >> Similar to the x86 type, this is currently only for development > >> and testing. It's not meant to be used for "real" VMs, and > >> especially not in production. The behavior and effective ABI for > >> software-protected VMs is unstable. > >> > >> This series enables mmap() support for guest_memfd specifically > >> for the new software-protected VM type, only when explicitly > >> enabled in the config. > > > > Hi! > > > > IIUC, in this series, there is no "private" vs "shared" distinction, > > right? So all pages are mappable, and "conversion" does not exist? You're right. This is a simplified version of my series that allows mmaping of the new KVM_VM_TYPE_ARM_SW_PROTECTED vms to use for experimentation. Cheers, /fuad > > Ah, I spot: > > +#define kvm_arch_private_mem_inplace(kvm) \ > + (IS_ENABLED(CONFIG_KVM_GMEM_MAPPABLE) && \ > + ((kvm)->arch.vm_type & KVM_VM_TYPE_ARM_SW_PROTECTED)) > > Which makes me wonder, why don't we need the same way of making sure all > references/mappings are gone (+ new page type) when doing the shared -> > private conversion? Or is this somewhere in here where I didn't spot it yet? This is new to this series. The idea, based on a request from Patrick Roy, was to have a VM in arm64 we could use to experiment with. Since it allows the unconditional mmaping, it's only useful for experiments or for non-confidential VMs that want to use guest_memfd. This series isn't meant to replace the other one, more to supplement it and facilitate experimentation while that's going. Cheers, /fuad > -- > Cheers, > > David / dhildenb >
On 22.01.25 18:16, Fuad Tabba wrote: > Hi David, > > On Wed, 22 Jan 2025 at 15:41, David Hildenbrand <david@redhat.com> wrote: >> >> On 22.01.25 16:35, David Hildenbrand wrote: >>> On 22.01.25 16:27, Fuad Tabba wrote: >>>> The purpose of this series is to serve as a potential base for >>>> restricted mmap() support for guest_memfd [1]. It would allow >>>> experimentation with what that support would be like, in the safe >>>> environment of a new VM type used for testing. >>>> >>>> This series adds a new VM type for arm64, >>>> KVM_VM_TYPE_ARM_SW_PROTECTED, analogous to the x86 >>>> KVM_X86_SW_PROTECTED_VM. This type is to serve as a development >>>> and testing vehicle for Confidential (CoCo) VMs. >>>> >>>> Similar to the x86 type, this is currently only for development >>>> and testing. It's not meant to be used for "real" VMs, and >>>> especially not in production. The behavior and effective ABI for >>>> software-protected VMs is unstable. >>>> >>>> This series enables mmap() support for guest_memfd specifically >>>> for the new software-protected VM type, only when explicitly >>>> enabled in the config. >>> >>> Hi! >>> >>> IIUC, in this series, there is no "private" vs "shared" distinction, >>> right? So all pages are mappable, and "conversion" does not exist? > > You're right. This is a simplified version of my series that allows > mmaping of the new KVM_VM_TYPE_ARM_SW_PROTECTED vms to use for > experimentation. > > Cheers, > /fuad > >> >> Ah, I spot: >> >> +#define kvm_arch_private_mem_inplace(kvm) \ >> + (IS_ENABLED(CONFIG_KVM_GMEM_MAPPABLE) && \ >> + ((kvm)->arch.vm_type & KVM_VM_TYPE_ARM_SW_PROTECTED)) >> >> Which makes me wonder, why don't we need the same way of making sure all >> references/mappings are gone (+ new page type) when doing the shared -> >> private conversion? Or is this somewhere in here where I didn't spot it yet? > > This is new to this series. The idea, based on a request from Patrick > Roy, was to have a VM in arm64 we could use to experiment with. Since > it allows the unconditional mmaping, it's only useful for experiments > or for non-confidential VMs that want to use guest_memfd. > > This series isn't meant to replace the other one, more to supplement > it and facilitate experimentation while that's going. Heh, so "kvm_arch_private_mem_inplace" in this series means "no conversion at all" ? :)
On Wed, 22 Jan 2025 at 21:42, David Hildenbrand <david@redhat.com> wrote: > > On 22.01.25 18:16, Fuad Tabba wrote: > > Hi David, > > > > On Wed, 22 Jan 2025 at 15:41, David Hildenbrand <david@redhat.com> wrote: > >> > >> On 22.01.25 16:35, David Hildenbrand wrote: > >>> On 22.01.25 16:27, Fuad Tabba wrote: > >>>> The purpose of this series is to serve as a potential base for > >>>> restricted mmap() support for guest_memfd [1]. It would allow > >>>> experimentation with what that support would be like, in the safe > >>>> environment of a new VM type used for testing. > >>>> > >>>> This series adds a new VM type for arm64, > >>>> KVM_VM_TYPE_ARM_SW_PROTECTED, analogous to the x86 > >>>> KVM_X86_SW_PROTECTED_VM. This type is to serve as a development > >>>> and testing vehicle for Confidential (CoCo) VMs. > >>>> > >>>> Similar to the x86 type, this is currently only for development > >>>> and testing. It's not meant to be used for "real" VMs, and > >>>> especially not in production. The behavior and effective ABI for > >>>> software-protected VMs is unstable. > >>>> > >>>> This series enables mmap() support for guest_memfd specifically > >>>> for the new software-protected VM type, only when explicitly > >>>> enabled in the config. > >>> > >>> Hi! > >>> > >>> IIUC, in this series, there is no "private" vs "shared" distinction, > >>> right? So all pages are mappable, and "conversion" does not exist? > > > > You're right. This is a simplified version of my series that allows > > mmaping of the new KVM_VM_TYPE_ARM_SW_PROTECTED vms to use for > > experimentation. > > > > Cheers, > > /fuad > > > >> > >> Ah, I spot: > >> > >> +#define kvm_arch_private_mem_inplace(kvm) \ > >> + (IS_ENABLED(CONFIG_KVM_GMEM_MAPPABLE) && \ > >> + ((kvm)->arch.vm_type & KVM_VM_TYPE_ARM_SW_PROTECTED)) > >> > >> Which makes me wonder, why don't we need the same way of making sure all > >> references/mappings are gone (+ new page type) when doing the shared -> > >> private conversion? Or is this somewhere in here where I didn't spot it yet? > > > > This is new to this series. The idea, based on a request from Patrick > > Roy, was to have a VM in arm64 we could use to experiment with. Since > > it allows the unconditional mmaping, it's only useful for experiments > > or for non-confidential VMs that want to use guest_memfd. > > > > This series isn't meant to replace the other one, more to supplement > > it and facilitate experimentation while that's going. > > Heh, so "kvm_arch_private_mem_inplace" in this series means "no > conversion at all" ? :) Yes, just for experimenting with the protected software VM. Thanks, /fuad > -- > Cheers, > > David / dhildenb >
On 23.01.25 10:09, Fuad Tabba wrote: > On Wed, 22 Jan 2025 at 21:42, David Hildenbrand <david@redhat.com> wrote: >> >> On 22.01.25 18:16, Fuad Tabba wrote: >>> Hi David, >>> >>> On Wed, 22 Jan 2025 at 15:41, David Hildenbrand <david@redhat.com> wrote: >>>> >>>> On 22.01.25 16:35, David Hildenbrand wrote: >>>>> On 22.01.25 16:27, Fuad Tabba wrote: >>>>>> The purpose of this series is to serve as a potential base for >>>>>> restricted mmap() support for guest_memfd [1]. It would allow >>>>>> experimentation with what that support would be like, in the safe >>>>>> environment of a new VM type used for testing. >>>>>> >>>>>> This series adds a new VM type for arm64, >>>>>> KVM_VM_TYPE_ARM_SW_PROTECTED, analogous to the x86 >>>>>> KVM_X86_SW_PROTECTED_VM. This type is to serve as a development >>>>>> and testing vehicle for Confidential (CoCo) VMs. >>>>>> >>>>>> Similar to the x86 type, this is currently only for development >>>>>> and testing. It's not meant to be used for "real" VMs, and >>>>>> especially not in production. The behavior and effective ABI for >>>>>> software-protected VMs is unstable. >>>>>> >>>>>> This series enables mmap() support for guest_memfd specifically >>>>>> for the new software-protected VM type, only when explicitly >>>>>> enabled in the config. >>>>> >>>>> Hi! >>>>> >>>>> IIUC, in this series, there is no "private" vs "shared" distinction, >>>>> right? So all pages are mappable, and "conversion" does not exist? >>> >>> You're right. This is a simplified version of my series that allows >>> mmaping of the new KVM_VM_TYPE_ARM_SW_PROTECTED vms to use for >>> experimentation. >>> >>> Cheers, >>> /fuad >>> >>>> >>>> Ah, I spot: >>>> >>>> +#define kvm_arch_private_mem_inplace(kvm) \ >>>> + (IS_ENABLED(CONFIG_KVM_GMEM_MAPPABLE) && \ >>>> + ((kvm)->arch.vm_type & KVM_VM_TYPE_ARM_SW_PROTECTED)) >>>> >>>> Which makes me wonder, why don't we need the same way of making sure all >>>> references/mappings are gone (+ new page type) when doing the shared -> >>>> private conversion? Or is this somewhere in here where I didn't spot it yet? >>> >>> This is new to this series. The idea, based on a request from Patrick >>> Roy, was to have a VM in arm64 we could use to experiment with. Since >>> it allows the unconditional mmaping, it's only useful for experiments >>> or for non-confidential VMs that want to use guest_memfd. >>> >>> This series isn't meant to replace the other one, more to supplement >>> it and facilitate experimentation while that's going. >> >> Heh, so "kvm_arch_private_mem_inplace" in this series means "no >> conversion at all" ? :) > > Yes, just for experimenting with the protected software VM. Got it, thanks!
The purpose of this series is to serve as a potential base for restricted mmap() support for guest_memfd [1]. It would allow experimentation with what that support would be like, in the safe environment of a new VM type used for testing. This series adds a new VM type for arm64, KVM_VM_TYPE_ARM_SW_PROTECTED, analogous to the x86 KVM_X86_SW_PROTECTED_VM. This type is to serve as a development and testing vehicle for Confidential (CoCo) VMs. Similar to the x86 type, this is currently only for development and testing. It's not meant to be used for "real" VMs, and especially not in production. The behavior and effective ABI for software-protected VMs is unstable. This series enables mmap() support for guest_memfd specifically for the new software-protected VM type, only when explicitly enabled in the config. The series is based on Linux 6.13-rc7 and much of the code within is a subset of the latest series I sent [1], with the addition of the new software protected vm type. To test this series, there's a kvmtool branch with support for guest_memfd for arm64 and the new runtime options of --guest_memfd and --sw_protected, which marks the VM as software protected [2]. I plan on upstreaming this kvmtool branch after more testing and tidying up. Please let me know if this series is useful as a stand-alone series, or if I should merge it with the other guest_memfd for future respins [1]. Cheers, /fuad [1] https://lore.kernel.org/all/20250117163001.2326672-1-tabba@google.com/ [2] https://android-kvm.googlesource.com/kvmtool/+/refs/heads/tabba/guestmem-6.13 Fuad Tabba (9): KVM: guest_memfd: Allow host to mmap guest_memfd() pages KVM: guest_memfd: Add guest_memfd support to kvm_(read|/write)_guest_page() KVM: guest_memfd: Add KVM capability to check if guest_memfd is host mappable KVM: arm64: Skip VMA checks for slots without userspace address KVM: arm64: Refactor user_mem_abort() calculation of force_pte KVM: arm64: Handle guest_memfd()-backed guest page faults KVM: arm64: Introduce KVM_VM_TYPE_ARM_SW_PROTECTED machine type KVM: guest_memfd: selftests: guest_memfd mmap() test when mapping is allowed KVM: arm64: Enable mapping guest_memfd in arm64 Documentation/virt/kvm/api.rst | 5 + arch/arm64/include/asm/kvm_host.h | 10 ++ arch/arm64/kvm/Kconfig | 1 + arch/arm64/kvm/arm.c | 5 + arch/arm64/kvm/mmu.c | 101 ++++++++++---- arch/x86/include/asm/kvm_host.h | 2 + include/linux/kvm_host.h | 16 +++ include/uapi/linux/kvm.h | 7 + tools/testing/selftests/kvm/Makefile | 1 + .../testing/selftests/kvm/guest_memfd_test.c | 60 ++++++++- tools/testing/selftests/kvm/lib/kvm_util.c | 3 +- virt/kvm/Kconfig | 4 + virt/kvm/guest_memfd.c | 71 ++++++++++ virt/kvm/kvm_main.c | 127 ++++++++++++++---- 14 files changed, 353 insertions(+), 60 deletions(-) base-commit: 5bc55a333a2f7316b58edc7573e8e893f7acb532