Messages in this thread | | | Date | Wed, 5 May 2021 14:28:53 +1000 | Subject | Re: [PATCH V4 05/18] iommu/ioasid: Redefine IOASID set and allocation APIs | From | Alexey Kardashevskiy <> |
| |
On 05/05/2021 04:15, Jason Gunthorpe wrote: > On Tue, May 04, 2021 at 01:54:55PM +1000, David Gibson wrote: >> On Mon, May 03, 2021 at 01:05:30PM -0300, Jason Gunthorpe wrote: >>> On Thu, Apr 29, 2021 at 01:20:22PM +1000, David Gibson wrote: >>>>> There is a certain appeal to having some >>>>> 'PPC_TCE_CREATE_SPECIAL_IOASID' entry point that has a wack of extra >>>>> information like windows that can be optionally called by the viommu >>>>> driver and it remains well defined and described. >>>> >>>> Windows really aren't ppc specific. They're absolutely there on x86 >>>> and everything else as well - it's just that people are used to having >>>> a window at 0..<something largish> that you can often get away with >>>> treating it sloppily. >>> >>> My point is this detailed control seems to go on to more than just >>> windows. As you say the vIOMMU is emulating specific HW that needs to >>> have kernel interfaces to match it exactly. >> >> It's really not that bad. The case of emulating the PAPR vIOMMU on >> something else is relatively easy, because all updates to the IO page >> tables go through hypercalls. So, as long as the backend IOMMU can >> map all the IOVAs that the guest IOMMU can, then qemu's implementation >> of those hypercalls just needs to put an equivalent mapping in the >> backend, which it can do with a generic VFIO_DMA_MAP. > > So you also want the PAPR vIOMMU driver to run on, say, an ARM IOMMU?
This is a good feature in general when let's say there is a linux supported device which has a proprietary device firmware update tool which only exists as an x86 binary and your hardware is not x86 - running qemu + vfio in full emulation would provide a way to run the tool to update a physical device.
-- Alexey
| |