[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <e1630046-8889-4452-9f8f-07695ba07772@redhat.com>
Date: Thu, 6 Feb 2025 19:22:09 +0100
From: David Hildenbrand <david@...hat.com>
To: Albert Esteve <aesteve@...hat.com>, Stefan Hajnoczi <stefanha@...hat.com>
Cc: Vivek Goyal <vgoyal@...hat.com>, Dan Williams <dan.j.williams@...el.com>,
Alistair Popple <apopple@...dia.com>, akpm@...ux-foundation.org,
linux-mm@...ck.org, alison.schofield@...el.com, lina@...hilina.net,
zhang.lyra@...il.com, gerald.schaefer@...ux.ibm.com,
vishal.l.verma@...el.com, dave.jiang@...el.com, logang@...tatee.com,
bhelgaas@...gle.com, jack@...e.cz, jgg@...pe.ca, catalin.marinas@....com,
will@...nel.org, mpe@...erman.id.au, npiggin@...il.com,
dave.hansen@...ux.intel.com, ira.weiny@...el.com, willy@...radead.org,
djwong@...nel.org, tytso@....edu, linmiaohe@...wei.com, peterx@...hat.com,
linux-doc@...r.kernel.org, linux-kernel@...r.kernel.org,
linux-arm-kernel@...ts.infradead.org, linuxppc-dev@...ts.ozlabs.org,
nvdimm@...ts.linux.dev, linux-cxl@...r.kernel.org,
linux-fsdevel@...r.kernel.org, linux-ext4@...r.kernel.org,
linux-xfs@...r.kernel.org, jhubbard@...dia.com, hch@....de,
david@...morbit.com, chenhuacai@...nel.org, kernel@...0n.name,
loongarch@...ts.linux.dev, Hanna Czenczek <hreitz@...hat.com>,
German Maglione <gmaglione@...hat.com>
Subject: Re: [PATCH v6 01/26] fuse: Fix dax truncate/punch_hole fault path
On 06.02.25 15:59, Albert Esteve wrote:
> Hi!
>
> On Thu, Feb 6, 2025 at 3:30 PM Stefan Hajnoczi <stefanha@...hat.com> wrote:
>>
>> On Thu, Feb 06, 2025 at 08:37:07AM -0500, Vivek Goyal wrote:
>>> And then there are challenges at QEMU level. virtiofsd needs additional
>>> vhost-user commands to implement DAX and these never went upstream in
>>> QEMU. I hope these challenges are sorted at some point of time.
>>
>> Albert Esteve has been working on QEMU support:
>> https://lore.kernel.org/qemu-devel/20240912145335.129447-1-aesteve@redhat.com/
>>
>> He has a viable solution. I think the remaining issue is how to best
>> structure the memory regions. The reason for slow progress is not
>> because it can't be done, it's probably just because this is a
>> background task.
>
> It is partially that, indeed. But what has me blocked for now on posting the
> next version is that I was reworking a bit the MMAP strategy.
> Following David comments, I am relying more on RAMBlocks and
> subregions for mmaps. But this turned out more difficult than anticipated.
Yeah, if that turns out to be too painful, we could start with the
previous approach and work on that later. I also did not expect that to
become that complicated.
--
Cheers,
David / dhildenb
Powered by blists - more mailing lists