> -----Original Message-----
> From: Cédric Le Goater <[email protected]>
> Sent: 12 January 2026 15:16
> To: Shameer Kolothum <[email protected]>; Duan, Zhenzhong
> <[email protected]>; [email protected]; qemu-
> [email protected]
> Cc: [email protected]; [email protected]; [email protected];
> [email protected]; Nicolin Chen <[email protected]>; Nathan Chen
> <[email protected]>; Matt Ochs <[email protected]>; Jason Gunthorpe
> <[email protected]>; Krishnakant Jaju <[email protected]>
> Subject: Re: [PATCH 3/3] hw/vfio/region: Create dmabuf for PCI BAR per
> region
>
> External email: Use caution opening links or attachments
>
>
> On 1/12/26 09:45, Shameer Kolothum wrote:
> >
> >
> >> -----Original Message-----
> >> From: Duan, Zhenzhong <[email protected]>
> >> Sent: 12 January 2026 02:33
> >> To: Shameer Kolothum <[email protected]>; qemu-
> [email protected];
> >> [email protected]
> >> Cc: [email protected]; [email protected]; [email protected];
> >> [email protected]; [email protected]; Nicolin Chen
> >> <[email protected]>; Nathan Chen <[email protected]>; Matt Ochs
> >> <[email protected]>; Jason Gunthorpe <[email protected]>; Krishnakant
> >> Jaju <[email protected]>
> >> Subject: RE: [PATCH 3/3] hw/vfio/region: Create dmabuf for PCI BAR
> >> per region
> >>
> >> External email: Use caution opening links or attachments
> >>
> >>
> >>>>>>> @@ -305,6 +345,21 @@ int vfio_region_mmap(VFIORegion *region)
> >>>>>>> region->mmaps[i].size - 1);
> >>>>>>> }
> >>>>>>>
> >>>>>>> + ret = vfio_region_create_dma_buf(region);
> >>>>>>> + if (ret < 0) {
> >>>>>>> + if (ret == -ENOTTY) {
> >>>>>>> + warn_report_once("VFIO dmabuf not supported in
> >>>>> kernel");
> >>>>>>> + } else {
> >>>>>>> + error_report("%s: failed to create dmabuf: %s",
> >>>>>>> + memory_region_name(region->mem),
> >>>>> strerror(errno));
> >>>>>>> + }
> >>>>>>> + } else {
> >>>>>>> + MemoryRegion *mr = ®ion->mmaps[0].mem;
> >>>>>>
> >>>>>> Do we need to support region->mmaps[1]?
> >>>>>
> >>>>> My understanding is all region->mmaps[] entries for a VFIO region
> >>>>> share the same RAMBlock. And the kernel returns a single dmabuf fd
> >>>>> per region, not per subrange.
> >>>>
> >>>> Not get, can RAMBlock have holes?
> >>>
> >>> Yes, a RAMBlock can effectively have holes, but in this context that
> >>> is not what is happening.
> >>>
> >>> IIUC, for a VFIO PCI BAR region, all region->mmaps[] entries
> >>> correspond to subranges of the same BAR and are backed by the same
> >>> MemoryRegion and therefore the same RAMBlock. The sparse mmap
> layout
> >>> (nr_mmaps > 1) exists to describe which parts of the BAR are
> >>> mappable, not to represent distinct backing memory objects.
> >>>
> >>> So while sparse regions may look like "holes" at the mmap level,
> >>> there are no holes in the RAMBlock abstraction itself. All
> >>> region->mmaps[] entries share the same RAMBlock, which is why
> >>> attaching the returned dmabuf fd to region->mmaps[0].mem.ram_block is
> sufficient, I think.
> >>>
> >>> However, possible I may be missing the case you are concerned about
> here.
> >>> Please let me know.
> >>
> >> I see memory_region_init_ram_device_ptr() is called for each region-
> >>> mmaps[x].mem,
> >> and RAMBlock is allocated in each call.
> >
> > Ah.. I see. It does allocate RAMBlock per mmaps[i].
> >
> >> IIUC, we should set fd and fd_offset in each RAMBlock.
> >
> > Ok. Will update in v2.
> I'd like to send a vfio PR soon and this v2 looks a like good candidate for
> it.
Sure. Will send out the v2 soon and thanks for sending those
update-linux-headers
and the hyperv patches.
Thanks,
Shameer
