Hi Shivank,
On Mon, 2 Jun 2025 at 11:44, Shivank Garg wrote:
>
>
>
> On 5/27/2025 11:32 PM, Fuad Tabba wrote:
> > This patch enables support for shared memory in guest_memfd, including
> > mapping that memory at the host userspace. This support is gated by the
On Mon, Mar 11, 2024 at 9:26 AM Fuad Tabba wrote:
>
> Hi,
>
> On Fri, Mar 8, 2024 at 9:05 PM Manwaring, Derek wrote:
> >
> > On 2024-03-08 at 10:46-0700, David Woodhouse wrote:
> > > On Fri, 2024-03-08 at 09:35 -0800, David Matlack wrote:
> > > > I
Hi,
On Fri, Mar 8, 2024 at 9:05 PM Manwaring, Derek wrote:
>
> On 2024-03-08 at 10:46-0700, David Woodhouse wrote:
> > On Fri, 2024-03-08 at 09:35 -0800, David Matlack wrote:
> > > I think what James is looking for (and what we are also interested
> > > in), is _eliminating_ the ability to access
rticular, we
> weren't getting the priority of HSTR_EL2 traps right -- these should
> take priority over UNDEF-at-EL traps but not over UNDEF-at-EL0 traps.
> The rest of the series is FEAT_FGT itself.
Thanks for this. I'd tested v1, which allowed me to run KVM/SME tests
wi
Hi Sean,
On Sat, Jan 14, 2023 at 12:38 AM Sean Christopherson wrote:
>
> On Fri, Dec 02, 2022, Chao Peng wrote:
> > This patch series implements KVM guest private memory for confidential
> > computing scenarios like Intel TDX[1]. If a TDX host accesses
> > TDX-protected guest memory, machine chec
kvm_arch_has_private_mem() which should be rewritten by
> architecture code.
>
> Co-developed-by: Yu Zhang
> Signed-off-by: Yu Zhang
> Signed-off-by: Chao Peng
> Reviewed-by: Fuad Tabba
With the code to port it to pKVM/arm64:
Tested-by: Fuad Tabba
Cheers,
/fuad
> ---
return xa_to_value(xa_load(&kvm->mem_attr_array, gfn)) &
> + KVM_MEMORY_ATTRIBUTE_PRIVATE;
> +}
> +#else
> +static inline bool kvm_mem_is_private(struct kvm *kvm, gfn_t gfn)
> +{
> + return false;
> +}
> +
> +#endif /* CONFIG_HAVE_KVM_MEMORY_ATTRIBUTES */
> +
> +#ifdef CONFIG_HAVE_KVM_RESTRICTED_MEM
> +static inline int kvm_restricted_mem_get_pfn(struct kvm_memory_slot *slot,
> + gfn_t gfn, kvm_pfn_t *pfn, int *order)
> +{
> + int ret;
> + struct page *page;
> + pgoff_t index = gfn - slot->base_gfn +
> + (slot->restricted_offset >> PAGE_SHIFT);
> +
> + ret = restrictedmem_get_page(slot->restricted_file, index,
> +&page, order);
> + *pfn = page_to_pfn(page);
> + return ret;
> +}
> +#endif /* CONFIG_HAVE_KVM_RESTRICTED_MEM */
> +
> #endif
> --
> 2.25.1
>
With my limited understanding of x86 code:
Reviewed-by: Fuad Tabba
The common code in kvm_host.h was used in the port to arm64, and the
x86 fault handling code was used as a guide to how it should be done
in pKVM (with similar code added there). So with these caveats in
mind:
Tested-by: Fuad Tabba
Cheers,
/fuad
Hi,
On Thu, Dec 8, 2022 at 11:18 AM Chao Peng wrote:
>
> On Wed, Dec 07, 2022 at 05:16:34PM +, Fuad Tabba wrote:
> > Hi,
> >
> > On Fri, Dec 2, 2022 at 6:19 AM Chao Peng
> > wrote:
> > >
> > > Unmap the existing guest mappings when memo
Hi,
On Fri, Dec 2, 2022 at 6:19 AM Chao Peng wrote:
>
> Unmap the existing guest mappings when memory attribute is changed
> between shared and private. This is needed because shared pages and
> private pages are from different backends, unmapping existing ones
> gives a chance for page fault han
Hi,
On Tue, Dec 6, 2022 at 12:01 PM Chao Peng wrote:
>
> On Mon, Dec 05, 2022 at 09:23:49AM +, Fuad Tabba wrote:
> > Hi Chao,
> >
> > On Fri, Dec 2, 2022 at 6:19 AM Chao Peng
> > wrote:
> > >
> > > Currently in mmu_notifier invalidate pa
by: Sean Christopherson
> Co-developed-by: Yu Zhang
> Signed-off-by: Yu Zhang
> Signed-off-by: Chao Peng
> Reviewed-by: Fuad Tabba
> ---
> Documentation/virt/kvm/api.rst | 22 ++
> include/uapi/linux/kvm.h | 8
> 2 files changed
if (!PAGE_ALIGNED(attrs->address) || !PAGE_ALIGNED(attrs->size))
> + return -EINVAL;
> +
> + start = attrs->address >> PAGE_SHIFT;
> + end = (attrs->address + attrs->size - 1 + PAGE_SIZE) >> PAGE_SHIFT;
Would using existing helpe
; By default memfd_restricted() prevents userspace read, write and mmap.
> By defining new bit in the 'flags', it can be extended to support other
> restricted semantics in the future.
>
> The system call is currently wired up for x86 arch.
Reviewed-by: Fuad Tabba
After wiring
Hi Chao,
On Tue, Dec 6, 2022 at 11:58 AM Chao Peng wrote:
>
> On Mon, Dec 05, 2022 at 09:03:11AM +, Fuad Tabba wrote:
> > Hi Chao,
> >
> > On Fri, Dec 2, 2022 at 6:18 AM Chao Peng
> > wrote:
> > >
> > > In memory encryption usage, guest me
Hi Chao,
On Fri, Dec 2, 2022 at 6:19 AM Chao Peng wrote:
>
> Currently in mmu_notifier invalidate path, hva range is recorded and
> then checked against by mmu_notifier_retry_hva() in the page fault
> handling path. However, for the to be introduced private memory, a page
> fault may not have a h
a new config HAVE_KVM_RESTRICTED_MEM is added
> and right now it is selected on X86_64 only.
>
> To make future maintenance easy, internally use a binary compatible
> alias struct kvm_user_mem_region to handle both the normal and the
> '_ext' variants.
>
> Co-develo
tls operate on this
> field and unmap existing mappings if any.
>
> Signed-off-by: Chao Peng
> ---
Reviewed-by: Fuad Tabba
Cheers,
/fuad
> Documentation/virt/kvm/api.rst | 17 ++-
> arch/x86/kvm/Kconfig | 1 +
> include/linux/kvm_host.h | 10 +-
>
t; ---
> include/linux/kvm_host.h | 3 +-
> virt/kvm/kvm_main.c | 174 +++++--
> 2 files changed, 171 insertions(+), 6 deletions(-)
Reviewed-by: Fuad Tabba
Thanks,
/fuad
>
> diff --git a/include/linux/kvm_host.h b/include/linux/kvm_host.h
> index 69300fc6d572..e27d62c30484 100
> accept hva in current code.
>
> Signed-off-by: Chao Peng
> ---
Based on reading this code and my limited knowledge of the x86 MMU code:
Reviewed-by: Fuad Tabba
Cheers,
/fuad
> arch/x86/kvm/mmu/mmu.c | 2 +-
> include/linux/kvm_host.h | 18 +++-
> virt/kv
d the
> '_ext' variants.
>
> Co-developed-by: Yu Zhang
> Signed-off-by: Yu Zhang
> Signed-off-by: Chao Peng
Reviewed-by: Fuad Tabba
I have tested the V8 version of this patch on arm64/qemu (which has
the fix to copy_from_user include
by: Sean Christopherson
> Co-developed-by: Yu Zhang
> Signed-off-by: Yu Zhang
> Signed-off-by: Chao Peng
> ---
Reviewed-by: Fuad Tabba
I have tested the V8 version of this patch on arm64/qemu, and
considering this hasn't changed:
Tested-by: Fuad Tabba
Cheers,
/fuad
>
n future this might be changed.
>
> By default memfd_restricted() prevents userspace read, write and mmap.
> By defining new bit in the 'flags', it can be extended to support other
> restricted semantics in the future.
>
> The system call is currently wired up for x86 arc
On Wed, Oct 19, 2022 at 5:09 PM Sean Christopherson wrote:
>
> On Wed, Oct 19, 2022, Fuad Tabba wrote:
> > > > > This sounds good. Thank you.
> > > >
> > > > I like the idea of a separate Kconfig, e.g.
> > > > CONFIG_KVM_GENERIC_PRIVATE_ME
Hi,
On Tue, Oct 18, 2022 at 1:34 AM Sean Christopherson wrote:
>
> On Fri, Sep 30, 2022, Fuad Tabba wrote:
> > > > > > pKVM would also need a way to make an fd accessible again
> > > > > > when shared back, which I think isn't possible with this
> > > This sounds good. Thank you.
> >
> > I like the idea of a separate Kconfig, e.g. CONFIG_KVM_GENERIC_PRIVATE_MEM
> > or
> > something. I highly doubt there will be any non-x86 users for multiple
> > years,
> > if ever, but it would allow testing the private memory stuff on ARM (and
> > any
Hi,
> > > Using both private_fd and userspace_addr is only needed in TDX and other
> > > confidential computing scenarios, pKVM may only use private_fd if the fd
> > > can also be mmaped as a whole to userspace as Sean suggested.
> >
> > That does work in practice, for now at least, and is what I
Hi,
> >
> > Actually, for pKVM, there is no need for the guest memory to be
> > GUP'able at all if we use the new inaccessible_get_pfn().
>
> If pKVM can use inaccessible_get_pfn() to get pfn and can avoid GUP (I
> think that is the major concern?), do you see any other gap from
> existing API?
A
Hi,
> > > +#ifdef CONFIG_HAVE_KVM_PRIVATE_MEM
> > > +#define KVM_MEM_ATTR_SHARED0x0001
> > > +static int kvm_vm_ioctl_set_mem_attr(struct kvm *kvm, gpa_t gpa, gpa_t
> > > size,
> > > +bool is_private)
> > > +{
> >
> > I wonder if this ioctl should be implem
Hi,
On Thu, Sep 15, 2022 at 3:38 PM Chao Peng wrote:
>
> If CONFIG_HAVE_KVM_PRIVATE_MEM=y, userspace can register/unregister the
> guest private memory regions through KVM_MEMORY_ENCRYPT_{UN,}REG_REGION
> ioctls. The patch reuses existing SEV ioctl number but differs that the
> address in the reg
Hi,
On Thu, Sep 15, 2022 at 3:37 PM Chao Peng wrote:
>
> Expose KVM_MEM_PRIVATE and memslot fields private_fd/offset to
> userspace. KVM will register/unregister private memslot to fd-based
> memory backing store and response to invalidation event from
> inaccessible_notifier to zap the existing
Hi,
I'm not sure if this patch or the last one might be the best place for
it, but I think it would be useful to have a KVM_CAP associated with
this. I am working on getting kvmtool to work with this, and I haven't
found a clean way of getting it to discover whether mem_private is
supported.
Than
Hi,
<...>
> diff --git a/mm/memfd_inaccessible.c b/mm/memfd_inaccessible.c
> new file mode 100644
> index ..2d33cbdd9282
> --- /dev/null
> +++ b/mm/memfd_inaccessible.c
<...>
> +struct file *memfd_mkinaccessible(struct file *memfd)
> +{
> + struct inaccessible_data *data;
> +
Hi,
On Mon, Oct 3, 2022 at 12:01 PM Kirill A. Shutemov wrote:
>
> On Mon, Oct 03, 2022 at 08:33:13AM +0100, Fuad Tabba wrote:
> > > I think it is "don't do that" category. inaccessible_register_notifier()
> > > caller has to know what file it operates on, n
Hi
On Fri, Sep 30, 2022 at 5:23 PM Kirill A . Shutemov
wrote:
>
> On Fri, Sep 30, 2022 at 05:14:00PM +0100, Fuad Tabba wrote:
> > Hi,
> >
> > <...>
> >
> > > diff --git a/mm/memfd_inaccessible.c b/mm/memfd_inaccessible.c
> > > new f
Hi,
On Tue, Sep 27, 2022 at 11:47 PM Sean Christopherson wrote:
>
> On Mon, Sep 26, 2022, Fuad Tabba wrote:
> > Hi,
> >
> > On Mon, Sep 26, 2022 at 3:28 PM Chao Peng
> > wrote:
> > >
> > > On Fri, Sep 23, 2022 at 04:19:46PM +0100, Fuad
Hi,
<...>
> diff --git a/mm/memfd_inaccessible.c b/mm/memfd_inaccessible.c
> new file mode 100644
> index ..2d33cbdd9282
> --- /dev/null
> +++ b/mm/memfd_inaccessible.c
> @@ -0,0 +1,219 @@
> +// SPDX-License-Identifier: GPL-2.0
> +#include "linux/sbitmap.h"
> +#include
> +#include
>
Hi,
On Mon, Sep 26, 2022 at 3:28 PM Chao Peng wrote:
>
> On Fri, Sep 23, 2022 at 04:19:46PM +0100, Fuad Tabba wrote:
> > > Regarding pKVM's use case, with the shim approach I believe this can be
> > > done by
> > > allowing userspace mmap()
Hi Chao,
On Thu, Sep 15, 2022 at 3:38 PM Chao Peng wrote:
>
> If CONFIG_HAVE_KVM_PRIVATE_MEM=y, userspace can register/unregister the
> guest private memory regions through KVM_MEMORY_ENCRYPT_{UN,}REG_REGION
> ioctls. The patch reuses existing SEV ioctl number but differs that the
> address in th
Hi Chao,
On Thu, Sep 15, 2022 at 3:35 PM Chao Peng wrote:
>
> In memory encryption usage, guest memory may be encrypted with special
> key and can be accessed only by the VM itself. We call such memory
> private memory. It's valueless and sometimes can cause problem to allow
> userspace to access
Hi,
On Fri, Sep 23, 2022 at 1:53 AM Kirill A . Shutemov
wrote:
>
> On Thu, Sep 22, 2022 at 07:49:18PM +, Sean Christopherson wrote:
> > On Thu, Sep 22, 2022, Wang, Wei W wrote:
> > > On Thursday, September 15, 2022 10:29 PM, Chao Peng wrote:
> > > > +int inaccessible_get_pfn(struct file *file
Hi,
<...>
> > Regarding pKVM's use case, with the shim approach I believe this can be
> > done by
> > allowing userspace mmap() the "hidden" memfd, but with a ton of restrictions
> > piled on top.
> >
> > My first thought was to make the uAPI a set of KVM ioctls so that KVM
> > could tightly
> >
Hi,
On Mon, Sep 19, 2022 at 8:10 PM Sean Christopherson wrote:
>
> +Will, Marc and Fuad (apologies if I missed other pKVM folks)
>
> On Mon, Sep 19, 2022, David Hildenbrand wrote:
> > On 15.09.22 16:29, Chao Peng wrote:
> > > From: "Kirill A. Shutemov"
> > >
> > > KVM can use memfd-provided memo
Hi Chao,
Thank you for your reply.
On Mon, Aug 29, 2022 at 4:23 PM Chao Peng wrote:
>
> On Fri, Aug 26, 2022 at 04:19:25PM +0100, Fuad Tabba wrote:
> > Hi,
> >
> > On Wed, Jul 6, 2022 at 9:24 AM Chao Peng
> > wrote:
> > >
> > > This is the v
Hi,
On Wed, Jul 6, 2022 at 9:24 AM Chao Peng wrote:
>
> This is the v7 of this series which tries to implement the fd-based KVM
> guest private memory. The patches are based on latest kvm/queue branch
> commit:
>
> b9b71f43683a (kvm/queue) KVM: x86/mmu: Buffer nested MMU
> split_desc_cache only
Hi Chao,
On Wed, Jul 6, 2022 at 9:27 AM Chao Peng wrote:
>
> If CONFIG_HAVE_KVM_PRIVATE_MEM=y, userspace can register/unregister the
> guest private memory regions through KVM_MEMORY_ENCRYPT_{UN,}REG_REGION
> ioctls. The patch reuses existing SEV ioctl but differs that the
> address in the region
Hi Chao,
On Wed, Jul 6, 2022 at 9:25 AM Chao Peng wrote:
>
> Normally, a write to unallocated space of a file or the hole of a sparse
> file automatically causes space allocation, for memfd, this equals to
> memory allocation. This new seal prevents such automatically allocating,
> either this is
Hi Marc,
On Tue, Jun 22, 2021 at 11:25 AM Marc Zyngier wrote:
>
> Hi Fuad,
>
> On Tue, 22 Jun 2021 09:56:22 +0100,
> Fuad Tabba wrote:
> >
> > Hi,
> >
> >
> > On Mon, Jun 21, 2021 at 12:18 PM Steven Price wrote:
> > >
> > > The V
Hi Marc,
On Tue, Jun 22, 2021 at 11:35 AM Marc Zyngier wrote:
>
> On Tue, 22 Jun 2021 10:42:42 +0100,
> Fuad Tabba wrote:
> >
> > Hi,
> >
> >
> > On Mon, Jun 21, 2021 at 12:18 PM Steven Price wrote:
> > >
> > > A new capabil
Hi,
> diff --git a/arch/arm64/include/asm/kvm_mte.h
> b/arch/arm64/include/asm/kvm_mte.h
> new file mode 100644
> index ..88dd1199670b
> --- /dev/null
> +++ b/arch/arm64/include/asm/kvm_mte.h
> @@ -0,0 +1,66 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +/*
> + * Copyright (C) 2020-2
Hi,
On Mon, Jun 21, 2021 at 12:18 PM Steven Price wrote:
>
> A new capability (KVM_CAP_ARM_MTE) identifies that the kernel supports
> granting a guest access to the tags, and provides a mechanism for the
> VMM to enable it.
>
> A new ioctl (KVM_ARM_MTE_COPY_TAGS) provides a simple way for a VMM
Hi,
On Mon, Jun 21, 2021 at 12:18 PM Steven Price wrote:
>
> The VMM may not wish to have it's own mapping of guest memory mapped
> with PROT_MTE because this causes problems if the VMM has tag checking
> enabled (the guest controls the tags in physical RAM and it's unlikely
> the tags are corre
Hi,
On Mon, Jun 21, 2021 at 12:18 PM Steven Price wrote:
>
> It's now safe for the VMM to enable MTE in a guest, so expose the
> capability to user space.
>
> Reviewed-by: Catalin Marinas
> Signed-off-by: Steven Price
> ---
> arch/arm64/kvm/arm.c | 9 +
> arch/arm64/kvm/reset.c
Hi,
On Mon, Jun 21, 2021 at 12:18 PM Steven Price wrote:
>
> Add a new VM feature 'KVM_ARM_CAP_MTE' which enables memory tagging
> for a VM. This will expose the feature to the guest and automatically
> tag memory pages touched by the VM as PG_mte_tagged (and clear the tag
> storage) to ensure th
53 matches
Mail list logo
