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
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
with qemu (which requi
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
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
> ---
ibutes(struct kvm *kvm,
> }
> #endif /* __KVM_HAVE_ARCH_SET_MEMORY_ATTRIBUTES */
>
> +#ifdef CONFIG_HAVE_KVM_MEMORY_ATTRIBUTES
> +static inline bool kvm_mem_is_private(struct kvm *kvm, gfn_t gfn)
> +{
> + return xa_to_value(xa_load(>mem_attr_array, gfn)) &
> +
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
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
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
t; 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, 30 insertions(+)
>
> d
> +
> + start = attrs->address >> PAGE_SHIFT;
> + end = (attrs->address + attrs->size - 1 + PAGE_SIZE) >> PAGE_SHIFT;
Would using existing helpers be better for getting the frame numbers?
Also, the code checks that the address and size are page aligned, so
the
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 the system call for arm64
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, gues
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
TED_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-developed-by: Yu Zhang
> Signed-of
e 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 +-
> virt/kvm/K
/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 100644
> --- a/inclu
t; 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/kvm/kvm
t;
> 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 included in this patch), and considering
this h
t; 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
> Documentation/virt/kvm/api.rst |
ight 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 arch.
>
> Signed-off-b
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 patch
> > > 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
> >
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?
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
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
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.
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, no?
&g
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() t
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
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
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
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
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
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
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
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)
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
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
52 matches
Mail list logo
