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:
signature.asc
Description: PGP signature
