Re: [Qemu-devel] Memory Map

[Salvatore Lionetti <salvatorelionetti@yahoo.it>]

Sure, i'm very interested in.
I've used another implementation that still require large amount of data to be allocated (but with O(1) search time)

Have a good day




--- Mer 2/3/11, Vincent Palatin <vpalatin@chromium.org> ha scritto:

> Da: Vincent Palatin <vpalatin@chromium.org>
> Oggetto: Re: [Qemu-devel] Memory Map
> A: "Salvatore Lionetti" <salvatorelionetti@yahoo.it>
> Cc: "Blue Swirl" <blauwirbel@gmail.com>, qemu-devel@nongnu.org
> Data: Mercoledì 2 marzo 2011, 22:13
> Hi,
> 
> On Wed, Mar 2, 2011 at 12:11, Salvatore Lionetti
> <salvatorelionetti@yahoo.it>
> wrote:
> > Still now, some memory region is called with
> base+offset.
> >
> > So:
> >
> > [0x204] <= value (write from uP register)
> > cause
> > read(opaque, offset=204, value)
> >
> > while
> > [0x504] <= value (write from uP register)
> > cause
> > read(opaque, offset=4, value)
> >
> > The two opaque are different as expected.
> >
> > Where i am wrong?
> 
> If you mean 0x5004 and not 0x504 (as stated in your
> previous email),
> IMO it is a current limitation of the Qemu feature called
> "subpage"
> (which is used when you are mapping a memory area smaller
> than the MMU
> page size as in your example).
> 
> When using subpages in the current code, the "offset"
> becomes the
> distance to the MMU page boundary instead of the distance
> to the base
> address of the peripheral. This is somewhat impractical and
> confusing
> when you are mapping the same subpage sized MMIO device at
> different
> addresses.
> As the emulation I'm working on has a lot of subpage sized
> peripherals, I have written a patch to workaround this
> limitation. I
> will send it to the list for comment if you want to try
> it.
> 
> -- 
> Vincent
>