[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH] Better support for dma_addr_t variables
From: |
David Gibson |
Subject: |
Re: [Qemu-devel] [PATCH] Better support for dma_addr_t variables |
Date: |
Sun, 1 Apr 2012 19:21:00 +1000 |
User-agent: |
Mutt/1.5.21 (2010-09-15) |
On Sun, Apr 01, 2012 at 12:17:28PM +0300, Michael S. Tsirkin wrote:
> On Tue, Mar 27, 2012 at 01:43:21PM +1100, David Gibson wrote:
> > A while back, we introduced the dma_addr_t type, which is supposed to
> > be used for bus visible memory addresses. At present, this is an
> > alias for target_phys_addr_t, but this will change when we eventually
> > add support for guest visible IOMMUs.
> >
> > There are some instances of target_phys_addr_t in the code now which
> > should really be dma_addr_t, but can't be trivially converted due to
> > missing features which this patch corrects.
> >
> > * We add DMA_ADDR_BITS analagous to TARGET_PHYS_ADDR_BITS. This is
> > important where we need to make a compile-time (#if) based on the
> > size of dma_addr_t.
> >
> > * We add a new helper macro to create device properties which take a
> > dma_addr_t, currently an alias to DEFINE_PROP_TADDR().
> >
> > Signed-off-by: David Gibson <address@hidden>
>
> I don't have any issues with this but let's apply together
> with the patch converting the devices that you mention.
Ok, I'll resend as a two patch series with the xhci conversion, which
is the main one.
> > diff --git a/hw/qdev-dma.h b/hw/qdev-dma.h
> > new file mode 100644
> > index 0000000..e407771
> > --- /dev/null
> > +++ b/hw/qdev-dma.h
> > @@ -0,0 +1,4 @@
> > +#include "qdev-addr.h"
> > +
> > +#define DEFINE_PROP_DMAADDR(_n, _s, _f, _d) \
> > + DEFINE_PROP_TADDR(_n, _s, _f, _d)
>
> Headers need preprocessor guards so that multiple
> inclusions don't trigger errors.
Again, a flaw copied from qdev-addr.h
> It does not matter much but did you consider sticking this
> in dma.h instead of adding a new header?
I'm pretty sure I tried that and ran into some sort of hairy circular
dependency problem which this seemed amongst the easier ways to work
around.
--
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