qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH 1/9] Add stub functions for PCI device models to


From: David Gibson
Subject: Re: [Qemu-devel] [PATCH 1/9] Add stub functions for PCI device models to do PCI DMA
Date: Wed, 12 Oct 2011 14:11:37 +1100
User-agent: Mutt/1.5.21 (2010-09-15)

On Sun, Oct 02, 2011 at 12:52:39PM +0200, Michael S. Tsirkin wrote:
> On Sun, Oct 02, 2011 at 12:29:08PM +0200, Avi Kivity wrote:
> > On 10/02/2011 12:25 PM, Michael S. Tsirkin wrote:
> > >On Mon, Sep 05, 2011 at 02:34:56PM +1000, David Gibson wrote:
> > >>  This patch adds functions to pci.[ch] to perform PCI DMA operations.  At
> > >>  present, these are just stubs which perform directly cpu physical memory
> > >>  accesses.
> > >>
> > >>  Using these stubs, however, distinguishes PCI device DMA transactions 
> > >> from
> > >>  other accesses to physical memory, which will allow PCI IOMMU support to
> > >>  be added in one place, rather than updating every PCI driver at that 
> > >> time.
> > >>
> > >>  That is, it allows us to update individual PCI drivers to support an 
> > >> IOMMU
> > >>  without having yet determined the details of how the IOMMU emulation 
> > >> will
> > >>  operate.  This will let us remove the most bitrot-sensitive part of an
> > >>  IOMMU patch in advance.
> > >>
> > >>  Signed-off-by: David Gibson<address@hidden>
> > >
> > >So something I just thought about:
> > >
> > >all wrappers now go through cpu_physical_memory_rw.
> > >This is a problem as e.g. virtio assumes that
> > >accesses such as stw are atomic. cpu_physical_memory_rw
> > >is a memcpy which makes no such guarantees.
> > >
> > 
> > Let's change cpu_physical_memory_rw() to provide that guarantee for
> > aligned two and four byte accesses.  Having separate paths just for
> > that is not maintainable.
> 
> Well, we also have stX_phys convert to target native endian-ness
> (nop for KVM but not necessarily for qemu).

Yes.. as do the stX_pci_dma() helpers.  They assume LE, rather than
having two variants, because PCI is an LE spec, and all normal PCI
devices work in LE.  If we need to model some perverse BE PCI device,
it can reswap itself.

-- 
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



reply via email to

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