> > > diff --git a/hw/vfio/common.c b/hw/vfio/common.c
> > > index 4374cc6176..d9d3b1277a 100644
> > > --- a/hw/vfio/common.c
> > > +++ b/hw/vfio/common.c
> > > @@ -430,6 +430,9 @@ static void
> > vfio_listener_region_add(MemoryListener *listener,
> > > VFIOHostDMAWindow *hostwin;
> > >
> > Indeed. Could we decide whether or not to register an address space with
> > VFIO in a more intelligent manner? E.g. the following simplistic patch
> > solves
> > our problem:
> >
> > diff --git a/hw/vfio/common.c b/hw/vfio/common.c
> > index 4374cc6176..d9d3b1277a 100644
> > ---
On Fri, 31 May 2019 15:28:07 +
Thanos Makatos wrote:
> > > When configuring device pass-through via VFIO to a VM, I noticed that
> > > QEMU tries to register (DMA_MAP) all memory regions of a guest (not
> > > only RAM). That includes firmware regions like "pc.rom".
> Would a
> > When configuring device pass-through via VFIO to a VM, I noticed that
> > QEMU tries to register (DMA_MAP) all memory regions of a guest (not
> > only RAM). That includes firmware regions like "pc.rom".
Would a
> > physical device ever need access to those?
>
> Probably not,
On Fri, 31 May 2019 13:32:29 +
Thanos Makatos wrote:
> When configuring device pass-through via VFIO to a VM, I noticed that
> QEMU tries to register (DMA_MAP) all memory regions of a guest (not
> only RAM). That includes firmware regions like "pc.rom". Would a
> physical device ever need
When configuring device pass-through via VFIO to a VM, I noticed that QEMU
tries to register (DMA_MAP) all memory regions of a guest (not only RAM). That
includes firmware regions like "pc.rom". Would a physical device ever need
access to those? Am I missing something?
