qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH] Memory API bugfix - abolish addrrrange_end()


From: David Gibson
Subject: Re: [Qemu-devel] [PATCH] Memory API bugfix - abolish addrrrange_end()
Date: Tue, 18 Oct 2011 12:38:48 +1100
User-agent: Mutt/1.5.21 (2010-09-15)

On Mon, Oct 17, 2011 at 12:34:19PM +0200, Avi Kivity wrote:
> On 10/17/2011 07:31 AM, David Gibson wrote:
> > > 
> > > In terms of how the code looks, it's seriously more ugly (see the
> > > patches I sent out).  Conceptually it's cleaner, since we're not dodging
> > > the issue that we need to deal with a full 64-bit domain.
> >
> > We don't have to dodge that issue.  I know how to remove the
> > requirement for intermediate negative values, I just haven't made up a
> > patch yet.  With that we can change to uint64 and cover the full 64
> > bit range.  In fact I think I can make it so that size==0 represents
> > size=2^64 and even handle the full 64-bit, inclusive range properly.
> 
> That means you can't do a real size == 0.

Yeah... a memory range with size 0 has no effect by definition, I
think we can do without it.

> > > But my main concern is maintainability.  The 64-bit blanket is to short,
> > > if we keep pulling it in various directions we'll just expose ourselves
> > > in new ways.
> >
> > Nonsense, dealing with full X-bit range calculations in X-bit types is
> > a fairly standard problem.  The kernel does it in VMA handling for
> > one.  It just requires thinking about overflow cases.
> 
> We discovered three bugs already (you found two, and I had one during
> development).  Even if it can probably be done with extreme care, but is
> it worth spending all that development time on?
> 
> I'm not sure there is a parallel with vmas, since we're offsetting in
> both the positive and negative directions.

I think the so-called "negative offsetting" is just an artifact of our
implementation.  I don't see that it's any different from having a VMA
whose file offset is larger than its memory address.

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