* [Qemu-devel] Memory Map
@ 2011-02-24 9:08 Salvatore Lionetti
2011-02-25 16:10 ` Blue Swirl
0 siblings, 1 reply; 6+ messages in thread
From: Salvatore Lionetti @ 2011-02-24 9:08 UTC (permalink / raw)
To: qemu-devel
Hi,
This is what my board do
cpu_register_physical_memory(0, 128*1024*1024, ...)
cpu_register_physical_memory(0xFF800000, 8*1024*1024, ...)
and this layout does not change over the entire live (virtual) of the board.
For the following offset (1st column) and size in bytes (2nd column)
{0x000000, 512},
{0x000200, 16},
{0x000300, 32},
{0x000400, 32},
{0x000500, 64},
{0x000600, 64},
{0x000700, 128},
{0x000800, 30},
{0x000900, 256},
{0x000A00, 44},
{0x000B00, 256},
{0x000C00, 24},
{0x000F00, 20},
{0x001000, 20},
{0x001100, 20},
{0x001400, 168},
{0x001800, 24},
{0x002000, 4096},
{0x003000, 24},
{0x003100, 24},
{0x004500, 36},
{0x005000, 224},
{0x008000, 768},
{0x008300, 16},
i do, for each item,
a = cpu_register_io_memory(r, w, o, DEVICE_NATIVE_ENDIAN)
cpu_register_physical_memory(_base+offset, len, a)
And _base could be reprogrammed at any time. So before to change _base i:
cpu_unregister_io_memory(a)
What i see is that accessing to _base+
_base+0x005000 => Wake up r/w with offset 0
_base+0x000204 => Wake up r/w with offset 0x204
So the question
- Am i wrong something?
- Is possible to map address with last TARGET_PAGE_BITS (es 0x200) bits set?
Have a good day
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [Qemu-devel] Memory Map
2011-02-24 9:08 [Qemu-devel] Memory Map Salvatore Lionetti
@ 2011-02-25 16:10 ` Blue Swirl
2011-03-02 17:11 ` Salvatore Lionetti
0 siblings, 1 reply; 6+ messages in thread
From: Blue Swirl @ 2011-02-25 16:10 UTC (permalink / raw)
To: Salvatore Lionetti; +Cc: qemu-devel
On Thu, Feb 24, 2011 at 11:08 AM, Salvatore Lionetti
<salvatorelionetti@yahoo.it> wrote:
> Hi,
>
> This is what my board do
>
> cpu_register_physical_memory(0, 128*1024*1024, ...)
> cpu_register_physical_memory(0xFF800000, 8*1024*1024, ...)
>
> and this layout does not change over the entire live (virtual) of the board.
>
> For the following offset (1st column) and size in bytes (2nd column)
> {0x000000, 512},
> {0x000200, 16},
> {0x000300, 32},
> {0x000400, 32},
> {0x000500, 64},
> {0x000600, 64},
> {0x000700, 128},
> {0x000800, 30},
> {0x000900, 256},
> {0x000A00, 44},
> {0x000B00, 256},
> {0x000C00, 24},
> {0x000F00, 20},
> {0x001000, 20},
> {0x001100, 20},
> {0x001400, 168},
> {0x001800, 24},
> {0x002000, 4096},
> {0x003000, 24},
> {0x003100, 24},
> {0x004500, 36},
> {0x005000, 224},
> {0x008000, 768},
> {0x008300, 16},
>
> i do, for each item,
>
> a = cpu_register_io_memory(r, w, o, DEVICE_NATIVE_ENDIAN)
> cpu_register_physical_memory(_base+offset, len, a)
>
> And _base could be reprogrammed at any time. So before to change _base i:
>
> cpu_unregister_io_memory(a)
>
> What i see is that accessing to _base+
> _base+0x005000 => Wake up r/w with offset 0
> _base+0x000204 => Wake up r/w with offset 0x204
>
> So the question
> - Am i wrong something?
cpu_unregister_io_memory() is the counterpart of
cpu_register_io_memory(), it does not affect mappings created by
cpu_register_physical_memory(). They should be removed first.
> - Is possible to map address with last TARGET_PAGE_BITS (es 0x200) bits set?
Yes.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [Qemu-devel] Memory Map
2011-02-25 16:10 ` Blue Swirl
@ 2011-03-02 17:11 ` Salvatore Lionetti
2011-03-02 21:13 ` Vincent Palatin
0 siblings, 1 reply; 6+ messages in thread
From: Salvatore Lionetti @ 2011-03-02 17:11 UTC (permalink / raw)
To: Blue Swirl; +Cc: qemu-devel
Hi,
many thanks for your response.
Now i'm i've avoided the unregistering stuff, map done already at desired address space.
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?
--- Ven 25/2/11, Blue Swirl <blauwirbel@gmail.com> ha scritto:
> Da: Blue Swirl <blauwirbel@gmail.com>
> Oggetto: Re: [Qemu-devel] Memory Map
> A: "Salvatore Lionetti" <salvatorelionetti@yahoo.it>
> Cc: qemu-devel@nongnu.org
> Data: Venerdì 25 febbraio 2011, 17:10
> On Thu, Feb 24, 2011 at 11:08 AM,
> Salvatore Lionetti
> <salvatorelionetti@yahoo.it>
> wrote:
> > Hi,
> >
> > This is what my board do
> >
> > cpu_register_physical_memory(0, 128*1024*1024, ...)
> > cpu_register_physical_memory(0xFF800000, 8*1024*1024,
> ...)
> >
> > and this layout does not change over the entire live
> (virtual) of the board.
> >
> > For the following offset (1st column) and size in
> bytes (2nd column)
> > {0x000000, 512},
> > {0x000200, 16},
> > {0x000300, 32},
> > {0x000400, 32},
> > {0x000500, 64},
> > {0x000600, 64},
> > {0x000700, 128},
> > {0x000800, 30},
> > {0x000900, 256},
> > {0x000A00, 44},
> > {0x000B00, 256},
> > {0x000C00, 24},
> > {0x000F00, 20},
> > {0x001000, 20},
> > {0x001100, 20},
> > {0x001400, 168},
> > {0x001800, 24},
> > {0x002000, 4096},
> > {0x003000, 24},
> > {0x003100, 24},
> > {0x004500, 36},
> > {0x005000, 224},
> > {0x008000, 768},
> > {0x008300, 16},
> >
> > i do, for each item,
> >
> > a = cpu_register_io_memory(r, w, o,
> DEVICE_NATIVE_ENDIAN)
> > cpu_register_physical_memory(_base+offset, len, a)
> >
> > And _base could be reprogrammed at any time. So before
> to change _base i:
> >
> > cpu_unregister_io_memory(a)
> >
> > What i see is that accessing to _base+
> > _base+0x005000 => Wake up r/w with offset 0
> > _base+0x000204 => Wake up r/w with offset 0x204
> >
> > So the question
> > - Am i wrong something?
>
> cpu_unregister_io_memory() is the counterpart of
> cpu_register_io_memory(), it does not affect mappings
> created by
> cpu_register_physical_memory(). They should be removed
> first.
>
> > - Is possible to map address with last
> TARGET_PAGE_BITS (es 0x200) bits set?
>
> Yes.
>
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [Qemu-devel] Memory Map
2011-03-02 17:11 ` Salvatore Lionetti
@ 2011-03-02 21:13 ` Vincent Palatin
2011-03-02 21:23 ` [Qemu-devel] [PATCH] fix offset for MMIO subpage access Vincent Palatin
2011-03-03 9:20 ` [Qemu-devel] Memory Map Salvatore Lionetti
0 siblings, 2 replies; 6+ messages in thread
From: Vincent Palatin @ 2011-03-02 21:13 UTC (permalink / raw)
To: Salvatore Lionetti; +Cc: Blue Swirl, qemu-devel
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* [Qemu-devel] [PATCH] fix offset for MMIO subpage access
2011-03-02 21:13 ` Vincent Palatin
@ 2011-03-02 21:23 ` Vincent Palatin
2011-03-03 9:20 ` [Qemu-devel] Memory Map Salvatore Lionetti
1 sibling, 0 replies; 6+ messages in thread
From: Vincent Palatin @ 2011-03-02 21:23 UTC (permalink / raw)
To: qemu-devel; +Cc: Salvatore Lionetti, Vincent Palatin
When using a MMIO subpage not starting on a page boundary, the offset
value given to the access handler is based on the start of the MMU page
not on the subpage base.
As a consequence, if you are mapping the same subpage sized MMIO device
at different addresses, this is somewhat impractical and confusing since
the same register will be called with different "offset" depending on the
base address.
My proposal is to workaround this by recording the offset in region_offset
field.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
---
exec.c | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/exec.c b/exec.c
index d611100..b59e7c9 100644
--- a/exec.c
+++ b/exec.c
@@ -2626,6 +2626,7 @@ void cpu_register_physical_memory_offset(target_phys_addr_t start_addr,
CHECK_SUBPAGE(addr, start_addr, start_addr2, end_addr, end_addr2,
need_subpage);
if (need_subpage) {
+ region_offset -= (start_addr & ~TARGET_PAGE_MASK);
if (!(orig_memory & IO_MEM_SUBPAGE)) {
subpage = subpage_init((addr & TARGET_PAGE_MASK),
&p->phys_offset, orig_memory,
@@ -2658,6 +2659,7 @@ void cpu_register_physical_memory_offset(target_phys_addr_t start_addr,
end_addr2, need_subpage);
if (need_subpage) {
+ region_offset -= (start_addr & ~TARGET_PAGE_MASK);
subpage = subpage_init((addr & TARGET_PAGE_MASK),
&p->phys_offset, IO_MEM_UNASSIGNED,
addr & TARGET_PAGE_MASK);
--
1.7.3.1
^ permalink raw reply related [flat|nested] 6+ messages in thread
* Re: [Qemu-devel] Memory Map
2011-03-02 21:13 ` Vincent Palatin
2011-03-02 21:23 ` [Qemu-devel] [PATCH] fix offset for MMIO subpage access Vincent Palatin
@ 2011-03-03 9:20 ` Salvatore Lionetti
1 sibling, 0 replies; 6+ messages in thread
From: Salvatore Lionetti @ 2011-03-03 9:20 UTC (permalink / raw)
To: Vincent Palatin; +Cc: Blue Swirl, qemu-devel
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
>
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2011-03-03 9:21 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2011-02-24 9:08 [Qemu-devel] Memory Map Salvatore Lionetti
2011-02-25 16:10 ` Blue Swirl
2011-03-02 17:11 ` Salvatore Lionetti
2011-03-02 21:13 ` Vincent Palatin
2011-03-02 21:23 ` [Qemu-devel] [PATCH] fix offset for MMIO subpage access Vincent Palatin
2011-03-03 9:20 ` [Qemu-devel] Memory Map Salvatore Lionetti
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).