qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] Re: [RFC PATCH 4/7] ide: IOMMU support


From: Chris Wright
Subject: Re: [Qemu-devel] Re: [RFC PATCH 4/7] ide: IOMMU support
Date: Wed, 14 Jul 2010 15:24:01 -0700
User-agent: Mutt/1.5.20 (2009-08-17)

* Anthony Liguori (address@hidden) wrote:
> On 07/14/2010 03:13 PM, Paul Brook wrote:
> >>On Wed, Jul 14, 2010 at 02:53:03PM +0100, Paul Brook wrote:
> >>>>Memory accesses must go through the IOMMU layer.
> >>>No. Devices should not know or care whether an IOMMU is present.
> >>There are real devices that care very much about an IOMMU. Basically all
> >>devices supporting ATS care about that. So I don't see a problem if the
> >>device emulation code of qemu also cares about present IOMMUs.
> >>
> >>>You should be adding a DeviceState argument to
> >>>cpu_physical_memory_{rw,map}. This should then handle IOMMU translation
> >>>transparently.
> >>That's not a good idea imho. With an IOMMU the device no longer accesses
> >>cpu physical memory. It accesses device virtual memory. Using
> >>cpu_physical_memory* functions in device code becomes misleading when
> >>the device virtual address space differs from cpu physical.
> >Well, ok, the function name needs fixing too.  However I think the only thing
> >missing from the current API is that it does not provide a way to determine
> >which device is performing the access.
> 
> I agree with Paul.

I do too.

> The right approach IMHO is to convert devices to use bus-specific
> functions to access memory.  The bus specific functions should have
> a device argument as the first parameter.

As for ATS, the internal api to handle the device's dma reqeust needs
a notion of a translated vs. an untranslated request.  IOW, if qemu ever
had a device with ATS support, the device would use its local cache to
translate the dma address and then submit a translated request to the
pci bus (effectively doing a raw cpu physical memory* in that case).

thanks,
-chris



reply via email to

[Prev in Thread] Current Thread [Next in Thread]