> From: Jason Gunthorpe
> Sent: Tuesday, August 6, 2024 7:23 AM
>
> On Mon, Aug 05, 2024 at 02:24:42AM +, Tian, Kevin wrote:
> >
> > According to [3],
> >
> > "
> > With SNP, when pages are marked as guest-owned in the RMP table,
> > they are assigned to a specific guest/ASID, as well as
On Mon, Aug 05, 2024 at 02:24:42AM +, Tian, Kevin wrote:
>
> According to [3],
>
> "
> With SNP, when pages are marked as guest-owned in the RMP table,
> they are assigned to a specific guest/ASID, as well as a specific GFN
> with in the guest. Any attempts to map it in the RMP table to
> From: Jason Gunthorpe
> Sent: Friday, August 2, 2024 7:22 PM
>
> On Fri, Aug 02, 2024 at 08:26:48AM +, Tian, Kevin wrote:
> > > From: Jason Gunthorpe
> > > Sent: Thursday, June 20, 2024 10:34 PM
> > >
> > > On Thu, Jun 20, 2024 at 04:14:23PM +0200, David Hildenbrand wrote:
> > >
> > > > 1)
On Fri, Aug 02, 2024 at 08:26:48AM +, Tian, Kevin wrote:
> > From: Jason Gunthorpe
> > Sent: Thursday, June 20, 2024 10:34 PM
> >
> > On Thu, Jun 20, 2024 at 04:14:23PM +0200, David Hildenbrand wrote:
> >
> > > 1) How would the device be able to grab/access "private memory", if not
> > >
> From: Jason Gunthorpe
> Sent: Thursday, June 20, 2024 10:34 PM
>
> On Thu, Jun 20, 2024 at 04:14:23PM +0200, David Hildenbrand wrote:
>
> > 1) How would the device be able to grab/access "private memory", if not
> >via the user page tables?
>
> The approaches I'm aware of require the secu
On Tue, Jul 16, 2024 at 10:34:55AM -0700, Sean Christopherson wrote:
> On Tue, Jul 16, 2024, Jason Gunthorpe wrote:
> > On Tue, Jul 16, 2024 at 09:03:00AM -0700, Sean Christopherson wrote:
> >
> > > > + To support huge pages, guest_memfd will take ownership of the
> > > > hugepages, and
> > > >
On Tue, Jul 16, 2024, Jason Gunthorpe wrote:
> On Tue, Jul 16, 2024 at 09:03:00AM -0700, Sean Christopherson wrote:
>
> > > + To support huge pages, guest_memfd will take ownership of the
> > > hugepages, and
> > > provide interested parties (userspace, KVM, iommu) with pages to be
> > > used.
On Tue, Jul 16, 2024 at 09:03:00AM -0700, Sean Christopherson wrote:
> > + To support huge pages, guest_memfd will take ownership of the hugepages,
> > and
> > provide interested parties (userspace, KVM, iommu) with pages to be used.
> > + guest_memfd will track usage of (sub)pages, for both
Thanks for doing the dirty work!
On Fri, Jul 12, 2024, Ackerley Tng wrote:
> Here’s an update from the Linux MM Alignment Session on July 10 2024, 9-10am
> PDT:
>
> The current direction is:
>
> + Allow mmap() of ranges that cover both shared and private memory, but
> disallow
> faulting in o
Here’s an update from the Linux MM Alignment Session on July 10 2024, 9-10am
PDT:
The current direction is:
+ Allow mmap() of ranges that cover both shared and private memory, but disallow
faulting in of private pages
+ On access to private pages, userspace will get some error, perhaps SIGBUS
On Mon, Jun 24, 2024 at 2:50 PM David Rientjes wrote:
>
> On Mon, 24 Jun 2024, Sean Christopherson wrote:
>
> > On Fri, Jun 21, 2024, Elliot Berman wrote:
> > > On Fri, Jun 21, 2024 at 11:16:31AM +0100, Fuad Tabba wrote:
> > > > On Fri, Jun 21, 2024 at 10:10 AM David Hildenbrand
> > > > wrote:
>
On Mon, 24 Jun 2024, Sean Christopherson wrote:
> On Fri, Jun 21, 2024, Elliot Berman wrote:
> > On Fri, Jun 21, 2024 at 11:16:31AM +0100, Fuad Tabba wrote:
> > > On Fri, Jun 21, 2024 at 10:10 AM David Hildenbrand
> > > wrote:
> > > > On 21.06.24 10:54, Fuad Tabba wrote:
> > > > > On Fri, Jun 21
On Fri, Jun 21, 2024, Elliot Berman wrote:
> On Fri, Jun 21, 2024 at 11:16:31AM +0100, Fuad Tabba wrote:
> > On Fri, Jun 21, 2024 at 10:10 AM David Hildenbrand wrote:
> > > On 21.06.24 10:54, Fuad Tabba wrote:
> > > > On Fri, Jun 21, 2024 at 9:44 AM David Hildenbrand
> > > > wrote:
> > > >>
> >
On Fri, Jun 21, 2024 at 11:16:31AM +0100, Fuad Tabba wrote:
> Hi David,
>
> On Fri, Jun 21, 2024 at 10:10 AM David Hildenbrand wrote:
> >
> > On 21.06.24 10:54, Fuad Tabba wrote:
> > > Hi David,
> > >
> > > On Fri, Jun 21, 2024 at 9:44 AM David Hildenbrand
> > > wrote:
> > >>
> > Again fro
On Fri, Jun 21, 2024 at 09:25:10AM +, Quentin Perret wrote:
> On Friday 21 Jun 2024 at 10:02:08 (+0200), David Hildenbrand wrote:
> > Sure, there might be cases like "pKVM can handle access to private pages in
> > user page mappings", "AMD-SNP will not crash the host if writing to private
> > p
On Thu, Jun 20, 2024 at 04:54:00PM -0700, Sean Christopherson wrote:
> Heh, and then we'd end up turning memfd into guest_memfd. As I see it, being
> able to safely map TDX/SNP/pKVM private memory is a happy side effect that is
> possible because guest_memfd isn't subordinate to the primary MMU,
On Fri, Jun 21, 2024 at 07:32:40AM +, Quentin Perret wrote:
> > No, I'm interested in what pKVM is doing that needs this to be so much
> > different than the CC case..
>
> The underlying technology for implementing CC is obviously very
> different (MMU-based for pKVM, encryption-based for the
Hi David,
On Fri, Jun 21, 2024 at 10:10 AM David Hildenbrand wrote:
>
> On 21.06.24 10:54, Fuad Tabba wrote:
> > Hi David,
> >
> > On Fri, Jun 21, 2024 at 9:44 AM David Hildenbrand wrote:
> >>
> Again from that thread, one of most important aspects guest_memfd is
> that VMAs
> ar
On 21.06.24 11:25, Quentin Perret wrote:
On Friday 21 Jun 2024 at 10:02:08 (+0200), David Hildenbrand wrote:
Thanks for the information. IMHO we really should try to find a common
ground here, and FOLL_EXCLUSIVE is likely not it :)
That's OK, IMO at least :-).
Thanks for reviving this discus
On Friday 21 Jun 2024 at 10:02:08 (+0200), David Hildenbrand wrote:
> Thanks for the information. IMHO we really should try to find a common
> ground here, and FOLL_EXCLUSIVE is likely not it :)
That's OK, IMO at least :-).
> Thanks for reviving this discussion with your patch set!
>
> pKVM is i
On 21.06.24 10:54, Fuad Tabba wrote:
Hi David,
On Fri, Jun 21, 2024 at 9:44 AM David Hildenbrand wrote:
Again from that thread, one of most important aspects guest_memfd is that VMAs
are not required. Stating the obvious, lack of VMAs makes it really hard to
drive
swap, reclaim, migration,
Hi David,
On Fri, Jun 21, 2024 at 9:44 AM David Hildenbrand wrote:
>
> >> Again from that thread, one of most important aspects guest_memfd is that
> >> VMAs
> >> are not required. Stating the obvious, lack of VMAs makes it really hard
> >> to drive
> >> swap, reclaim, migration, etc. from cod
Again from that thread, one of most important aspects guest_memfd is that VMAs
are not required. Stating the obvious, lack of VMAs makes it really hard to
drive
swap, reclaim, migration, etc. from code that fundamentally operates on VMAs.
: More broadly, no VMAs are required. The lack of sta
Hi Sean,
On Thu, Jun 20, 2024 at 4:37 PM Sean Christopherson wrote:
>
> On Wed, Jun 19, 2024, Fuad Tabba wrote:
> > Hi Jason,
> >
> > On Wed, Jun 19, 2024 at 12:51 PM Jason Gunthorpe wrote:
> > >
> > > On Wed, Jun 19, 2024 at 10:11:35AM +0100, Fuad Tabba wrote:
> > >
> > > > To be honest, person
On 21.06.24 09:32, Quentin Perret wrote:
On Thursday 20 Jun 2024 at 20:18:14 (-0300), Jason Gunthorpe wrote:
On Thu, Jun 20, 2024 at 03:47:23PM -0700, Elliot Berman wrote:
On Thu, Jun 20, 2024 at 11:29:56AM -0300, Jason Gunthorpe wrote:
On Thu, Jun 20, 2024 at 04:01:08PM +0200, David Hildenbra
On 21.06.24 01:54, Sean Christopherson wrote:
On Thu, Jun 20, 2024, Jason Gunthorpe wrote:
On Thu, Jun 20, 2024 at 01:30:29PM -0700, Sean Christopherson wrote:
I.e. except for blatant bugs, e.g. use-after-free, we need to be able to
guarantee
with 100% accuracy that there are no outstanding ma
On Thursday 20 Jun 2024 at 20:18:14 (-0300), Jason Gunthorpe wrote:
> On Thu, Jun 20, 2024 at 03:47:23PM -0700, Elliot Berman wrote:
> > On Thu, Jun 20, 2024 at 11:29:56AM -0300, Jason Gunthorpe wrote:
> > > On Thu, Jun 20, 2024 at 04:01:08PM +0200, David Hildenbrand wrote:
> > > > Regarding huge p
On Thu, Jun 20, 2024, Jason Gunthorpe wrote:
> On Thu, Jun 20, 2024 at 01:30:29PM -0700, Sean Christopherson wrote:
> > I.e. except for blatant bugs, e.g. use-after-free, we need to be able to
> > guarantee
> > with 100% accuracy that there are no outstanding mappings when converting a
> > page
>
On Thu, Jun 20, 2024 at 03:47:23PM -0700, Elliot Berman wrote:
> On Thu, Jun 20, 2024 at 11:29:56AM -0300, Jason Gunthorpe wrote:
> > On Thu, Jun 20, 2024 at 04:01:08PM +0200, David Hildenbrand wrote:
> > > Regarding huge pages: assume the huge page (e.g., 1 GiB hugetlb) is
> > > shared,
> > > now
On Thu, Jun 20, 2024 at 01:30:29PM -0700, Sean Christopherson wrote:
> I.e. except for blatant bugs, e.g. use-after-free, we need to be able to
> guarantee
> with 100% accuracy that there are no outstanding mappings when converting a
> page
> from shared=>private. Crossing our fingers and hoping
On Thu, Jun 20, 2024 at 08:53:07PM +0200, David Hildenbrand wrote:
> On 20.06.24 18:36, Jason Gunthorpe wrote:
> > On Thu, Jun 20, 2024 at 04:45:08PM +0200, David Hildenbrand wrote:
> >
> > > If we could disallow pinning any shared pages, that would make life a lot
> > > easier, but I think there
> This is the step that concerns me. "Relatively short time" is, well,
> relative.
> Hmm, though I suppose if userspace managed to map a shared page into something
> that pins the page, and can't force an unpin, e.g. by stopping I/O?, then
> either
> there's a host userspace bug or a guest bu
On Thu, Jun 20, 2024 at 11:29:56AM -0300, Jason Gunthorpe wrote:
> On Thu, Jun 20, 2024 at 04:01:08PM +0200, David Hildenbrand wrote:
> > Regarding huge pages: assume the huge page (e.g., 1 GiB hugetlb) is shared,
> > now the VM requests to make one subpage private.
>
> I think the general CC mod
On Thu, Jun 20, 2024, David Hildenbrand wrote:
> On 20.06.24 22:30, Sean Christopherson wrote:
> > On Thu, Jun 20, 2024, David Hildenbrand wrote:
> > > On 20.06.24 18:36, Jason Gunthorpe wrote:
> > > > On Thu, Jun 20, 2024 at 04:45:08PM +0200, David Hildenbrand wrote:
> > > >
> > > > > If we could
On 20.06.24 22:30, Sean Christopherson wrote:
On Thu, Jun 20, 2024, David Hildenbrand wrote:
On 20.06.24 18:36, Jason Gunthorpe wrote:
On Thu, Jun 20, 2024 at 04:45:08PM +0200, David Hildenbrand wrote:
If we could disallow pinning any shared pages, that would make life a lot
easier, but I thi
On Thu, Jun 20, 2024, David Hildenbrand wrote:
> On 20.06.24 18:36, Jason Gunthorpe wrote:
> > On Thu, Jun 20, 2024 at 04:45:08PM +0200, David Hildenbrand wrote:
> >
> > > If we could disallow pinning any shared pages, that would make life a lot
> > > easier, but I think there were reasons for why
On 20.06.24 18:04, Sean Christopherson wrote:
On Thu, Jun 20, 2024, David Hildenbrand wrote:
On 20.06.24 16:29, Jason Gunthorpe wrote:
On Thu, Jun 20, 2024 at 04:01:08PM +0200, David Hildenbrand wrote:
On 20.06.24 15:55, Jason Gunthorpe wrote:
On Thu, Jun 20, 2024 at 09:32:11AM +0100, Fuad Ta
On 20.06.24 18:36, Jason Gunthorpe wrote:
On Thu, Jun 20, 2024 at 04:45:08PM +0200, David Hildenbrand wrote:
If we could disallow pinning any shared pages, that would make life a lot
easier, but I think there were reasons for why we might require it. To
convert shared->private, simply unmap tha
On Thu, Jun 20, 2024 at 04:45:08PM +0200, David Hildenbrand wrote:
> If we could disallow pinning any shared pages, that would make life a lot
> easier, but I think there were reasons for why we might require it. To
> convert shared->private, simply unmap that folio (only the shared parts
> could
Hi David,
On Thu, Jun 20, 2024 at 04:14:23PM +0200, David Hildenbrand wrote:
> On 20.06.24 15:08, Mostafa Saleh wrote:
> > Hi David,
> >
> > On Wed, Jun 19, 2024 at 09:37:58AM +0200, David Hildenbrand wrote:
> > > Hi,
> > >
> > > On 19.06.24 04:44, John Hubbard wrote:
> > > > On 6/18/24 5:05 PM,
On Thu, Jun 20, 2024, David Hildenbrand wrote:
> On 20.06.24 16:29, Jason Gunthorpe wrote:
> > On Thu, Jun 20, 2024 at 04:01:08PM +0200, David Hildenbrand wrote:
> > > On 20.06.24 15:55, Jason Gunthorpe wrote:
> > > > On Thu, Jun 20, 2024 at 09:32:11AM +0100, Fuad Tabba wrote:
> > > Regarding huge
On Wed, Jun 19, 2024, Fuad Tabba wrote:
> Hi Jason,
>
> On Wed, Jun 19, 2024 at 12:51 PM Jason Gunthorpe wrote:
> >
> > On Wed, Jun 19, 2024 at 10:11:35AM +0100, Fuad Tabba wrote:
> >
> > > To be honest, personally (speaking only for myself, not necessarily
> > > for Elliot and not for anyone els
On 20.06.24 16:29, Jason Gunthorpe wrote:
On Thu, Jun 20, 2024 at 04:01:08PM +0200, David Hildenbrand wrote:
On 20.06.24 15:55, Jason Gunthorpe wrote:
On Thu, Jun 20, 2024 at 09:32:11AM +0100, Fuad Tabba wrote:
Hi,
On Thu, Jun 20, 2024 at 5:11 AM Christoph Hellwig wrote:
On Wed, Jun 19, 20
On Thu, Jun 20, 2024 at 04:14:23PM +0200, David Hildenbrand wrote:
> 1) How would the device be able to grab/access "private memory", if not
>via the user page tables?
The approaches I'm aware of require the secure world to own the IOMMU
and generate the IOMMU page tables. So we will not use
On Thu, Jun 20, 2024 at 04:01:08PM +0200, David Hildenbrand wrote:
> On 20.06.24 15:55, Jason Gunthorpe wrote:
> > On Thu, Jun 20, 2024 at 09:32:11AM +0100, Fuad Tabba wrote:
> > > Hi,
> > >
> > > On Thu, Jun 20, 2024 at 5:11 AM Christoph Hellwig
> > > wrote:
> > > >
> > > > On Wed, Jun 19, 202
On 20.06.24 15:08, Mostafa Saleh wrote:
Hi David,
On Wed, Jun 19, 2024 at 09:37:58AM +0200, David Hildenbrand wrote:
Hi,
On 19.06.24 04:44, John Hubbard wrote:
On 6/18/24 5:05 PM, Elliot Berman wrote:
In arm64 pKVM and QuIC's Gunyah protected VM model, we want to support
grabbing shmem user
On Thu, Jun 20, 2024 at 11:00:45AM +0200, David Hildenbrand wrote:
> > Not sure if IOMMU + private makes that much sense really, but I think
> > I might not really understand what you mean by this.
>
> A device might be able to access private memory. In the TDX world, this
> would mean that a devi
On 20.06.24 15:55, Jason Gunthorpe wrote:
On Thu, Jun 20, 2024 at 09:32:11AM +0100, Fuad Tabba wrote:
Hi,
On Thu, Jun 20, 2024 at 5:11 AM Christoph Hellwig wrote:
On Wed, Jun 19, 2024 at 08:51:35AM -0300, Jason Gunthorpe wrote:
If you can't agree with the guest_memfd people on how to get th
On Thu, Jun 20, 2024 at 09:32:11AM +0100, Fuad Tabba wrote:
> Hi,
>
> On Thu, Jun 20, 2024 at 5:11 AM Christoph Hellwig wrote:
> >
> > On Wed, Jun 19, 2024 at 08:51:35AM -0300, Jason Gunthorpe wrote:
> > > If you can't agree with the guest_memfd people on how to get there
> > > then maybe you nee
Hi David,
On Wed, Jun 19, 2024 at 09:37:58AM +0200, David Hildenbrand wrote:
> Hi,
>
> On 19.06.24 04:44, John Hubbard wrote:
> > On 6/18/24 5:05 PM, Elliot Berman wrote:
> > > In arm64 pKVM and QuIC's Gunyah protected VM model, we want to support
> > > grabbing shmem user pages instead of using
Yes, and I think we might have to revive that discussion, unfortunately.
I started thinking about this, but did not reach a conclusion. Sharing
my thoughts.
The minimum we might need to make use of guest_memfd (v1 or v2 ;) ) not
just for private memory should be:
(1) Have private + shared parts
Hi David,
On Wed, Jun 19, 2024 at 1:16 PM David Hildenbrand wrote:
>
> On 19.06.24 11:11, Fuad Tabba wrote:
> > Hi John and David,
> >
> > Thank you for your comments.
> >
> > On Wed, Jun 19, 2024 at 8:38 AM David Hildenbrand wrote:
> >>
> >> Hi,
> >>
> >> On 19.06.24 04:44, John Hubbard wrote:
Hi,
On Thu, Jun 20, 2024 at 5:11 AM Christoph Hellwig wrote:
>
> On Wed, Jun 19, 2024 at 08:51:35AM -0300, Jason Gunthorpe wrote:
> > If you can't agree with the guest_memfd people on how to get there
> > then maybe you need a guest_memfd2 for this slightly different special
> > stuff instead of
On Wed, Jun 19, 2024 at 08:51:35AM -0300, Jason Gunthorpe wrote:
> If you can't agree with the guest_memfd people on how to get there
> then maybe you need a guest_memfd2 for this slightly different special
> stuff instead of intruding on the core mm so much. (though that would
> be sad)
Or we're
On Wed, Jun 19, 2024 at 01:01:14PM +0100, Fuad Tabba wrote:
> Hi Jason,
>
> On Wed, Jun 19, 2024 at 12:51 PM Jason Gunthorpe wrote:
> >
> > On Wed, Jun 19, 2024 at 10:11:35AM +0100, Fuad Tabba wrote:
> >
> > > To be honest, personally (speaking only for myself, not necessarily
> > > for Elliot an
If the memory can't be accessed by the CPU then it shouldn't be mapped
into a PTE in the first place. The fact you made userspace faults
(only) work is nifty but still an ugly hack to get around the fact you
shouldn't be mapping in the first place.
We already have ZONE_DEVICE/DEVICE_PRIVATE to ha
On 19.06.24 11:11, Fuad Tabba wrote:
Hi John and David,
Thank you for your comments.
On Wed, Jun 19, 2024 at 8:38 AM David Hildenbrand wrote:
Hi,
On 19.06.24 04:44, John Hubbard wrote:
On 6/18/24 5:05 PM, Elliot Berman wrote:
In arm64 pKVM and QuIC's Gunyah protected VM model, we want to
Hi Jason,
On Wed, Jun 19, 2024 at 12:51 PM Jason Gunthorpe wrote:
>
> On Wed, Jun 19, 2024 at 10:11:35AM +0100, Fuad Tabba wrote:
>
> > To be honest, personally (speaking only for myself, not necessarily
> > for Elliot and not for anyone else in the pKVM team), I still would
> > prefer to use gue
On Wed, Jun 19, 2024 at 10:11:35AM +0100, Fuad Tabba wrote:
> To be honest, personally (speaking only for myself, not necessarily
> for Elliot and not for anyone else in the pKVM team), I still would
> prefer to use guest_memfd(). I think that having one solution for
> confidential computing that
Hi John and David,
Thank you for your comments.
On Wed, Jun 19, 2024 at 8:38 AM David Hildenbrand wrote:
>
> Hi,
>
> On 19.06.24 04:44, John Hubbard wrote:
> > On 6/18/24 5:05 PM, Elliot Berman wrote:
> >> In arm64 pKVM and QuIC's Gunyah protected VM model, we want to support
> >> grabbing shmem
Hi,
On 19.06.24 04:44, John Hubbard wrote:
On 6/18/24 5:05 PM, Elliot Berman wrote:
In arm64 pKVM and QuIC's Gunyah protected VM model, we want to support
grabbing shmem user pages instead of using KVM's guestmemfd. These
hypervisors provide a different isolation model than the CoCo
implementat
On 6/18/24 5:05 PM, Elliot Berman wrote:
In arm64 pKVM and QuIC's Gunyah protected VM model, we want to support
grabbing shmem user pages instead of using KVM's guestmemfd. These
hypervisors provide a different isolation model than the CoCo
implementations from x86. KVM's guest_memfd is focused o
b4 wasn't happy with my copy/paste of the CC list from Fuad's series
[1]. CC'ing them here.
[1]: https://lore.kernel.org/all/20240222161047.402609-1-ta...@google.com/
On Tue, Jun 18, 2024 at 05:05:06PM -0700, Elliot Berman wrote:
> In arm64 pKVM and QuIC's Gunyah protected VM model, we want to su
63 matches
Mail list logo
