On 07/15/2010 11:45 AM, Eduard - Gabriel Munteanu wrote:
On Thu, Jul 15, 2010 at 07:45:06AM -0500, Anthony Liguori wrote:
No. PCI devices should never call cpu_physical_memory*.
PCI devices should call pci_memory*.
ISA devices should call isa_memory*.
All device memory accesses should go
On Thu, Jul 15, 2010 at 10:17:10AM -0700, Chris Wright wrote:
> * Avi Kivity (a...@redhat.com) wrote:
> >
> > For emulated device, it seems like we can ignore ATS completely, no?
>
> Not if you want to emulate an ATS capable device ;)
>
> Eariler upthread I said:
>
> IOW, if qemu ever had a d
* Avi Kivity (a...@redhat.com) wrote:
> On 07/15/2010 08:17 PM, Chris Wright wrote:
> >
> >>For emulated device, it seems like we can ignore ATS completely, no?
> >Not if you want to emulate an ATS capable device ;)
>
> What I meant was that the whole request translation, invalidate, dma
> using a
On Thu, Jul 15, 2010 at 08:02:05PM +0300, Avi Kivity wrote:
> For emulated device, it seems like we can ignore ATS completely, no?
An important use-case for emulation is software testing and caching of
iommu's is an important part that needs to be handled in software. For
this purpose it makes se
On 07/15/2010 08:17 PM, Chris Wright wrote:
For emulated device, it seems like we can ignore ATS completely, no?
Not if you want to emulate an ATS capable device ;)
What I meant was that the whole request translation, invalidate, dma
using a translated address thing is invisible t
* Avi Kivity (a...@redhat.com) wrote:
> On 07/15/2010 07:52 PM, Chris Wright wrote:
> >
> >>Really? Can you provide an documentation to support this claim?
> >>My impression is that there is no difference between translated and
> >>untranslated devices, and the translation is explicitly disabled by
* Chris Wright (chr...@sous-sol.org) wrote:
> * Paul Brook (p...@codesourcery.com) wrote:
> > > > 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.
> > >
>
On 07/15/2010 07:52 PM, Chris Wright wrote:
Really? Can you provide an documentation to support this claim?
My impression is that there is no difference between translated and
untranslated devices, and the translation is explicitly disabled by software.
ATS allows an I/O device to reques
* Paul Brook (p...@codesourcery.com) wrote:
> > > 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
On Thu, Jul 15, 2010 at 07:45:06AM -0500, Anthony Liguori wrote:
>
> No. PCI devices should never call cpu_physical_memory*.
>
> PCI devices should call pci_memory*.
>
> ISA devices should call isa_memory*.
>
> All device memory accesses should go through their respective buses.
> There can
On Thu, Jul 15, 2010 at 11:49:20AM +0100, Paul Brook wrote:
> > An IOMMU is not necessarily part of a bus bridge. By concept an IOMMU
> > can also be implemented on a plugin-card translating only that card.
> > Real implementations that I am aware of always implement the IOMMU in
> > the PCI root
On Thu, Jul 15, 2010 at 07:45:06AM -0500, Anthony Liguori wrote:
> On 07/15/2010 04:10 AM, Joerg Roedel wrote:
>> If this means a seperate interface for device dma accesses and not fold
>> that functionality into the cpu_physical_memory* interface I agree too :-)
>>
> No. PCI devices should never
> >>> Depending how the we decide to handle IOMMU invalidation, it may also
> >>> be necessary to augment the memory_map API to allow the system to
> >>> request a mapping be revoked. However this issue is not specific to
> >>> the IOMMU implementation. Such bugs are already present on any system
On 07/15/2010 04:10 AM, Joerg Roedel wrote:
On Wed, Jul 14, 2010 at 04:29:18PM -0500, Anthony Liguori wrote:
On 07/14/2010 03:13 PM, Paul Brook wrote:
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
On 07/15/2010 05:33 AM, Paul Brook wrote:
Depending how the we decide to handle IOMMU invalidation, it may also be
necessary to augment the memory_map API to allow the system to request a
mapping be revoked. However this issue is not specific to the IOMMU
implementation. Such bugs are already pr
> 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.
>
> They don't really care. iommu_get() et al. are convenience functions
> which can and do return NULL whe
> On Wed, Jul 14, 2010 at 09:13:44PM +0100, Paul Brook wrote:
> > A device performs a memory access on its local bus. It has no knowledge
> > of how that access is routed to its destination. The device should not
> > be aware of any IOMMUs, in the same way that it doesn't know whether it
> > happe
> > Depending how the we decide to handle IOMMU invalidation, it may also be
> > necessary to augment the memory_map API to allow the system to request a
> > mapping be revoked. However this issue is not specific to the IOMMU
> > implementation. Such bugs are already present on any system that all
> > 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 un
On Wed, Jul 14, 2010 at 09:13:44PM +0100, Paul Brook wrote:
> A device performs a memory access on its local bus. It has no knowledge of
> how
> that access is routed to its destination. The device should not be aware of
> any IOMMUs, in the same way that it doesn't know whether it happens to
On Wed, Jul 14, 2010 at 04:29:18PM -0500, Anthony Liguori wrote:
> On 07/14/2010 03:13 PM, Paul Brook wrote:
>> 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
On Wed, Jul 14, 2010 at 09:13:44PM +0100, Paul Brook wrote:
> 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.
>
> Depending how the we decide to h
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.
They don't really care. iommu_get() et al. are convenience functions
which can and do return NULL when there's no I
* Anthony Liguori (anth...@codemonkey.ws) 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 rea
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 IO
> 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
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
> Memory accesses must go through the IOMMU layer.
No. Devices should not know or care whether an IOMMU is present.
You should be adding a DeviceState argument to cpu_physical_memory_{rw,map}.
This should then handle IOMMU translation transparently.
You also need to accomodate the the case wher
28 matches
Mail list logo
