On 18.10.24 09:15, Patrick Roy wrote:
On Thu, 2024-10-17 at 20:18 +0100, Jason Gunthorpe wrote:
On Thu, Oct 17, 2024 at 03:11:10PM -0400, Peter Xu wrote:
On Thu, Oct 17, 2024 at 02:10:10PM -0300, Jason Gunthorpe wrote:
If so, maybe that's a non-issue for non-CoCo, where the VM object /
gmemf
On Thu, 2024-10-17 at 20:18 +0100, Jason Gunthorpe wrote:
> On Thu, Oct 17, 2024 at 03:11:10PM -0400, Peter Xu wrote:
>> On Thu, Oct 17, 2024 at 02:10:10PM -0300, Jason Gunthorpe wrote:
If so, maybe that's a non-issue for non-CoCo, where the VM object /
gmemfd object (when created) can
On 17.10.24 21:18, Jason Gunthorpe wrote:
On Thu, Oct 17, 2024 at 03:11:10PM -0400, Peter Xu wrote:
On Thu, Oct 17, 2024 at 02:10:10PM -0300, Jason Gunthorpe wrote:
If so, maybe that's a non-issue for non-CoCo, where the VM object /
gmemfd object (when created) can have a flag marking that it's
On Thu, Oct 17, 2024 at 03:11:10PM -0400, Peter Xu wrote:
> On Thu, Oct 17, 2024 at 02:10:10PM -0300, Jason Gunthorpe wrote:
> > > If so, maybe that's a non-issue for non-CoCo, where the VM object /
> > > gmemfd object (when created) can have a flag marking that it's
> > > always shared and can nev
On Thu, Oct 17, 2024 at 02:10:10PM -0300, Jason Gunthorpe wrote:
> > If so, maybe that's a non-issue for non-CoCo, where the VM object /
> > gmemfd object (when created) can have a flag marking that it's
> > always shared and can never be converted to private for any page
> > within.
>
> What is n
On Thu, Oct 17, 2024 at 10:46 PM Jason Gunthorpe wrote:
>
> On Thu, Oct 17, 2024 at 07:11:46PM +0200, David Hildenbrand wrote:
> > On 17.10.24 18:47, Jason Gunthorpe wrote:
> > > On Thu, Oct 17, 2024 at 10:58:29AM -0400, Peter Xu wrote:
> > >
> > > > My question was more torwards whether gmemfd co
On 17.10.24 19:16, Jason Gunthorpe wrote:
On Thu, Oct 17, 2024 at 07:11:46PM +0200, David Hildenbrand wrote:
On 17.10.24 18:47, Jason Gunthorpe wrote:
On Thu, Oct 17, 2024 at 10:58:29AM -0400, Peter Xu wrote:
My question was more torwards whether gmemfd could still expose the
possibility to b
On 17.10.24 18:47, Jason Gunthorpe wrote:
On Thu, Oct 17, 2024 at 10:58:29AM -0400, Peter Xu wrote:
My question was more torwards whether gmemfd could still expose the
possibility to be used in VA forms to other modules that may not support
fd+offsets yet.
I keep hearing they don't want to su
On Thu, Oct 17, 2024 at 07:11:46PM +0200, David Hildenbrand wrote:
> On 17.10.24 18:47, Jason Gunthorpe wrote:
> > On Thu, Oct 17, 2024 at 10:58:29AM -0400, Peter Xu wrote:
> >
> > > My question was more torwards whether gmemfd could still expose the
> > > possibility to be used in VA forms to oth
On Thu, Oct 17, 2024 at 01:47:13PM -0300, Jason Gunthorpe wrote:
> On Thu, Oct 17, 2024 at 10:58:29AM -0400, Peter Xu wrote:
>
> > My question was more torwards whether gmemfd could still expose the
> > possibility to be used in VA forms to other modules that may not support
> > fd+offsets yet.
>
On Thu, Oct 17, 2024 at 01:05:34PM -0400, Peter Xu wrote:
> On Thu, Oct 17, 2024 at 01:47:13PM -0300, Jason Gunthorpe wrote:
> > On Thu, Oct 17, 2024 at 10:58:29AM -0400, Peter Xu wrote:
> >
> > > My question was more torwards whether gmemfd could still expose the
> > > possibility to be used in V
On Thu, Oct 17, 2024 at 10:58:29AM -0400, Peter Xu wrote:
> My question was more torwards whether gmemfd could still expose the
> possibility to be used in VA forms to other modules that may not support
> fd+offsets yet.
I keep hearing they don't want to support page pinning on a guestmemfd
mappi
On 16.10.24 22:16, Peter Xu wrote:
On Wed, Oct 16, 2024 at 10:45:43AM +0200, David Hildenbrand wrote:
On 16.10.24 01:42, Ackerley Tng wrote:
Peter Xu writes:
On Fri, Oct 11, 2024 at 11:32:11PM +, Ackerley Tng wrote:
Peter Xu writes:
On Tue, Sep 10, 2024 at 11:43:57PM +, Ackerley
On Wed, Oct 16, 2024 at 08:54:24PM -0300, Jason Gunthorpe wrote:
> On Wed, Oct 16, 2024 at 07:49:31PM -0400, Peter Xu wrote:
> > On Wed, Oct 16, 2024 at 07:51:57PM -0300, Jason Gunthorpe wrote:
> > > On Wed, Oct 16, 2024 at 04:16:17PM -0400, Peter Xu wrote:
> > > >
> > > > Is there chance that whe
On 17.10.24 01:49, Peter Xu wrote:
On Wed, Oct 16, 2024 at 07:51:57PM -0300, Jason Gunthorpe wrote:
On Wed, Oct 16, 2024 at 04:16:17PM -0400, Peter Xu wrote:
Is there chance that when !CoCo will be supported, then external modules
(e.g. VFIO) can reuse the old user mappings, just like before g
On Wed, Oct 16, 2024 at 07:49:31PM -0400, Peter Xu wrote:
> On Wed, Oct 16, 2024 at 07:51:57PM -0300, Jason Gunthorpe wrote:
> > On Wed, Oct 16, 2024 at 04:16:17PM -0400, Peter Xu wrote:
> > >
> > > Is there chance that when !CoCo will be supported, then external modules
> > > (e.g. VFIO) can reus
On Wed, Oct 16, 2024 at 07:51:57PM -0300, Jason Gunthorpe wrote:
> On Wed, Oct 16, 2024 at 04:16:17PM -0400, Peter Xu wrote:
> >
> > Is there chance that when !CoCo will be supported, then external modules
> > (e.g. VFIO) can reuse the old user mappings, just like before gmemfd?
> >
> > To suppor
On Wed, Oct 16, 2024 at 04:16:17PM -0400, Peter Xu wrote:
>
> Is there chance that when !CoCo will be supported, then external modules
> (e.g. VFIO) can reuse the old user mappings, just like before gmemfd?
>
> To support CoCo, I understand gmem+offset is required all over the places.
> However i
On Wed, Oct 16, 2024 at 10:45:43AM +0200, David Hildenbrand wrote:
> On 16.10.24 01:42, Ackerley Tng wrote:
> > Peter Xu writes:
> >
> > > On Fri, Oct 11, 2024 at 11:32:11PM +, Ackerley Tng wrote:
> > > > Peter Xu writes:
> > > >
> > > > > On Tue, Sep 10, 2024 at 11:43:57PM +, Ackerley
On Wed, Oct 16, 2024 at 01:54:32PM +0200, David Hildenbrand wrote:
> Likely should be doable. All we need is the generalized concept of a folio
> with HVO, and a way to move these folios between owners (e.g.,
> global<->hugetlb, global<->guest_memfd).
+1
HVO seems to become a sticking point in t
On 16.10.24 12:48, Vishal Annapurve wrote:
On Wed, Oct 16, 2024 at 2:20 PM David Hildenbrand wrote:
I also don't know how you treat things like folio_test_hugetlb() on
possible assumptions that the VMA must be a hugetlb vma. I'd confess I
didn't yet check the rest of the patchset yet - readi
On Wed, Oct 16, 2024 at 2:20 PM David Hildenbrand wrote:
>
> >> I also don't know how you treat things like folio_test_hugetlb() on
> >> possible assumptions that the VMA must be a hugetlb vma. I'd confess I
> >> didn't yet check the rest of the patchset yet - reading a large series
> >> without
I also don't know how you treat things like folio_test_hugetlb() on
possible assumptions that the VMA must be a hugetlb vma. I'd confess I
didn't yet check the rest of the patchset yet - reading a large series
without a git tree is sometimes challenging to me.
I'm thinking to basically never i
On 16.10.24 01:42, Ackerley Tng wrote:
Peter Xu writes:
On Fri, Oct 11, 2024 at 11:32:11PM +, Ackerley Tng wrote:
Peter Xu writes:
On Tue, Sep 10, 2024 at 11:43:57PM +, Ackerley Tng wrote:
The faultability xarray is stored on the inode since faultability is a
property of the guest
Peter Xu writes:
> On Fri, Oct 11, 2024 at 11:32:11PM +, Ackerley Tng wrote:
>> Peter Xu writes:
>>
>> > On Tue, Sep 10, 2024 at 11:43:57PM +, Ackerley Tng wrote:
>> >> The faultability xarray is stored on the inode since faultability is a
>> >> property of the guest_memfd's memory cont
On Fri, Oct 11, 2024 at 11:32:11PM +, Ackerley Tng wrote:
> Peter Xu writes:
>
> > On Tue, Sep 10, 2024 at 11:43:57PM +, Ackerley Tng wrote:
> >> The faultability xarray is stored on the inode since faultability is a
> >> property of the guest_memfd's memory contents.
> >>
> >> In this R
Peter Xu writes:
> On Tue, Sep 10, 2024 at 11:43:57PM +, Ackerley Tng wrote:
>> The faultability xarray is stored on the inode since faultability is a
>> property of the guest_memfd's memory contents.
>>
>> In this RFC, presence of an entry in the xarray indicates faultable,
>> but this coul
On Tue, Sep 10, 2024 at 11:43:57PM +, Ackerley Tng wrote:
> The faultability xarray is stored on the inode since faultability is a
> property of the guest_memfd's memory contents.
>
> In this RFC, presence of an entry in the xarray indicates faultable,
> but this could be flipped so that prese
The faultability xarray is stored on the inode since faultability is a
property of the guest_memfd's memory contents.
In this RFC, presence of an entry in the xarray indicates faultable,
but this could be flipped so that presence indicates unfaultable. For
flexibility, a special value "FAULT" is u
29 matches
Mail list logo
