[Top][All Lists]
[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
Re: [Qemu-devel] [PULL 0/3] 128-bit support for the memory API, Anthony Liguori, 2011/10/31