On Tue, 5 Nov 2019 00:40:39 +0800
Li Qiang <address@hidden> wrote:
> Hello Alex, Auger and all,
>
> I have a question about the VFIO virtual device BAR.
>
> In vfio_region_setup, it initialize a ‘region->mem’ MR and set its ops to ‘vfio_regions_ops’.
> In ‘vfio_region_mmap’, it maps the physical device’s MMIO to QEMU’s virtual address space
> as a raw MR ‘region->mmaps[i].mem’.
> And also it set the latter MR as a subregion of the first one.
>
> So when the guest accesses the BAR, it will direct go to the physical device’s BAR.
> My question is here:
> When the qemu will use the ‘vfio_regions_ops’ to read/write the BAR?
> Also whey in the last of ‘vfio_region_write/read’ we need to call ‘vbasedev->ops->vfio_eoi(vbasedev);’?
We support:
a) sparse mmaps where the entire BAR is not covered by an mmap
Got.
b) quirks, which layer on top of the mmaps to provide virtualized
access
Do you mean like in 'vfio_probe_ati_bar4_quirk', register a high priority subregion of VFIORegion.mem.
So when the guest write the BAR, vfio_regions_ops will be used. Here 'quirks' do you mean such things?
static void vfio_probe_ati_bar4_quirk(VFIOPCIDevice *vdev, int nr)
{
VFIOQuirk *quirk;
VFIOConfigWindowQuirk *window;
...
memory_region_init_io(window->addr_mem, OBJECT(vdev),
&vfio_generic_window_address_quirk, window,
"vfio-ati-bar4-window-address-quirk", 4);
memory_region_add_subregion_overlap(vdev->bars[nr].region.mem,
window->address_offset,
window->addr_mem, 1);
...
}
c) INTx emulation which disables mmaps MRs in order to detect device
access as a generic mechanism for inferring interrupt
acknowledgment.
In the above two cases, in 'vfio_region_write/read' we always access the physical device's BAR.
So as far as I can understand, the physical device(sometimes) will trigger interrupts. And the responsible of clear it
will be by the 'guest'. So I can't understand why there calls 'vbasedev->ops->vfio_eoi'. Could you please give me an
example.
Thanks,
Li Qiang
The latter being the reason we call vfio_eoi. Thanks,
Alex