Re: [PATCH V4 05/18] iommu/ioasid: Redefine IOASID set and allocation APIs

David Gibson
2021-05-24T07:56:05Z

[-- Attachment #1: Type: text/plain, Size: 1666 bytes --]

On Thu, May 13, 2021 at 10:50:30AM -0300, Jason Gunthorpe wrote:
> On Thu, May 13, 2021 at 04:07:07PM +1000, David Gibson wrote:
> > On Wed, May 05, 2021 at 01:39:02PM -0300, Jason Gunthorpe wrote:
> > > On Wed, May 05, 2021 at 02:28:53PM +1000, Alexey Kardashevskiy wrote:
> > >
> > > > 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.
> > >
> > > That specific use case doesn't really need a vIOMMU though, does it?
> >
> > Possibly not, but the mechanics needed to do vIOMMU on different host
> > IOMMU aren't really different from what you need for a no-vIOMMU
> > guest.
>
> For very simple vIOMMUs this might be true, but this new features of nesting
> PASID, migration, etc, etc all make the vIOMMU complicated and
> emuluating it completely alot harder.

Well, sure, emulating a complex vIOMMU is complex. But "very simple
vIOMMUs" covers the vast majority of currently deployed hardware, and
several are already emulated by qemu.

> Stuffing a vfio-pci into a guest and creating a physical map using a
> single IOASID is comparably trivial.

Note that for PAPR (POWER guest) systems this is not an option: the
PAPR platform *always* has a vIOMMU.

--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]