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:

quoted

On Wed, May 05, 2021 at 01:39:02PM -0300, Jason Gunthorpe wrote:

quoted

On Wed, May 05, 2021 at 02:28:53PM +1000, Alexey Kardashevskiy wrote:

quoted

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