On Fri, 13 Jan 2023 12:39:18 +0000 Jean-Philippe Brucker <jean-phili...@linaro.org> wrote:
> Hi, > > On Mon, Jan 09, 2023 at 10:11:19PM +0100, Eric Auger wrote: > > > Jean, do you have any idea about how to fix that? Do you think we have a > > > trouble in the acpi/viot setup or virtio-iommu probe sequence. It looks > > > like virtio probe and attach commands are called too early, before the > > > bus is actually correctly numbered. > > > > So after further investigations looks this is not a problem of bus > > number, which is good at the time of the virtio cmd calls but rather a > > problem related to the devfn (0 was used when creating the IOMMU MR) > > whereas the virtio-iommu cmds looks for the non aliased devfn. With that > > fixed, the probe and attach at least succeeds. The device still does not > > work for me but I will continue my investigations and send a tentative fix. > > > > If I remember correctly VIOT can deal with bus numbers because bridges are > assigned a range by QEMU, but I haven't tested that in detail, and I don't > know how it holds with conventional PCI bridges. In my reading of the virtio-iommu spec, I noted that it specifies the bus numbers *at the time of OS handoff*, so it essentially washes its hands of the OS renumbering buses while leaving subtle dependencies on initial numbering in the guest and QEMU implementations. On bare metal, a conventional bridge aliases the devices downstream of it. We reflect that in QEMU by aliasing those devices to the AddressSpace of the bridge. IIRC, Linux guests will use a for-each-dma-alias function when programming IOMMU translation tables to populate the bridge alias, where a physical IOMMU would essentially only see that bridge RID. Thanks, Alex
