qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PULL 0/3] 128-bit support for the memory API


From: Avi Kivity
Subject: Re: [Qemu-devel] [PULL 0/3] 128-bit support for the memory API
Date: Sun, 30 Oct 2011 17:10:51 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:7.0) Gecko/20110927 Thunderbird/7.0

On 10/30/2011 04:59 PM, Blue Swirl wrote:
> >
> > There is no direct use of signed arithmetic in the API (just in the
> > implementation).  Aliases can cause a region to move in either the
> > positive or negative direction, and this requires either signed
> > arithmetic or special casing the two directions.
> >
> > Signed arithmetic is not the only motivation - overflow is another.
> > Nothing prevents a user from placing a 64-bit 4k BAR at address
> > ffff_ffff_ffff_f000; we could move to base/limit representation, but
> > that will likely cause its own bugs.  Finally, we should be able to
> > represent both a 0-sized region and a 2^64 sized region.
>
> It looks like 64 bit saturating arithmetic could also work. 

Depends when you saturate.  The standard example (vga) takes a alias of
(say) 0xe01a0000 and aliases it into 0x000a0000.  So you need to adjust
addresses downwards by -0xe0100000.  That brings the start of the real
region (0xe0000000) into the negative territory.  Saturating it there
would break it.

> It should
> also be possible to work only with (start, end) address pairs and
> never with start + size, then 2^64 shouldn't be an issue.

Then 0 becomes an issue (end < start).

-- 
error compiling committee.c: too many arguments to function




reply via email to

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