[Qemu-devel] memory: Why subpage is introduced?

[Qemu-devel] memory: Why subpage is introduced?

[Zhi Yong Wu]

HI,

For memory management, i have several questions as below:

1.) Why is subpage introduced? what is its goal?

2.) How to render MemoryRegion into one disjoint flatrange list? That
rendering function is a bit difficult to understand. Can anyone simply
explain it?

3.) What are separately the meanings of these flags? such as
IO_MEM_RAM, IO_MEM_ROM, IO_MEM_UNASSIGNED, IO_MEM_*, IO_MEM_ROMD, and
IO_MEM_SUBPAGE.

Can anyone give some helpful comments?


-- 
Regards,

Zhi Yong Wu

Re: [Qemu-devel] memory: Why subpage is introduced?

[Avi Kivity]

On 12/21/2011 02:09 PM, Zhi Yong Wu wrote:
> HI,
>
> For memory management, i have several questions as below:
>
> 1.) Why is subpage introduced? what is its goal?

A TLB entry spans one page; a subpage is a way of dispatching accesses
through that tlb entry to various memory regions.

> 2.) How to render MemoryRegion into one disjoint flatrange list? That
> rendering function is a bit difficult to understand. Can anyone simply
> explain it?

What exactly don't you understand?

>
> 3.) What are separately the meanings of these flags? such as
> IO_MEM_RAM, IO_MEM_ROM, IO_MEM_UNASSIGNED, IO_MEM_*, IO_MEM_ROMD, and
> IO_MEM_SUBPAGE.

RAM = RAM
ROM = ROM
UNASSIGNED = nothing handles this range
ROMD = ROM when read, device (i.e. callbacks) when written
SUBPAGE = dispatch using the lower address bits to obtain final I/O handler.

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

Re: [Qemu-devel] memory: Why subpage is introduced?

[Zhi Yong Wu]

On Wed, Dec 21, 2011 at 9:30 PM, Avi Kivity <avi@redhat.com> wrote:
> On 12/21/2011 02:09 PM, Zhi Yong Wu wrote:
>> HI,
>>
>> For memory management, i have several questions as below:
>>
>> 1.) Why is subpage introduced? what is its goal?
>
> A TLB entry spans one page; a subpage is a way of dispatching accesses
> through that tlb entry to various memory regions.
thanks.
>
>> 2.) How to render MemoryRegion into one disjoint flatrange list? That
>> rendering function is a bit difficult to understand. Can anyone simply
>> explain it?
>
> What exactly don't you understand?
1.) e.g. some fields such as offset_in_region, terminates, offset in
MemoryRegion struct. What are separately their meanings?
2.)  render_memory_region(), how does it render one MemoryRegion into
the global view flatview? Can you simply explain this function's
algorithm logic?

>
>>
>> 3.) What are separately the meanings of these flags? such as
>> IO_MEM_RAM, IO_MEM_ROM, IO_MEM_UNASSIGNED, IO_MEM_*, IO_MEM_ROMD, and
>> IO_MEM_SUBPAGE.
>
> RAM = RAM
> ROM = ROM
> UNASSIGNED = nothing handles this range
> ROMD = ROM when read, device (i.e. callbacks) when written
> SUBPAGE = dispatch using the lower address bits to obtain final I/O handler.
thanks.

By the way, if you are available, can you simply explain what is the
relationship among them and how they work together? such as
MemoryRegion, RamBlock, PhysPageDesc, and MemorySlot.

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



-- 
Regards,

Zhi Yong Wu

Re: [Qemu-devel] memory: Why subpage is introduced?

[Avi Kivity]

On 12/22/2011 01:24 PM, Zhi Yong Wu wrote:
> >
> >> 2.) How to render MemoryRegion into one disjoint flatrange list? That
> >> rendering function is a bit difficult to understand. Can anyone simply
> >> explain it?
> >
> > What exactly don't you understand?
> 1.) e.g. some fields such as offset_in_region, terminates, offset in
> MemoryRegion struct. What are separately their meanings?

Well, read the code, it's not that complicated.  Afterwards you can add
documentation based on your findings.

> 2.)  render_memory_region(), how does it render one MemoryRegion into
> the global view flatview? Can you simply explain this function's
> algorithm logic?

Again, what can I say that the code doesn't?  It recursively descends
the hierarchy and finds out which region goes where.

Also read docs/memory.txt

>
> >
> >>
> >> 3.) What are separately the meanings of these flags? such as
> >> IO_MEM_RAM, IO_MEM_ROM, IO_MEM_UNASSIGNED, IO_MEM_*, IO_MEM_ROMD, and
> >> IO_MEM_SUBPAGE.
> >
> > RAM = RAM
> > ROM = ROM
> > UNASSIGNED = nothing handles this range
> > ROMD = ROM when read, device (i.e. callbacks) when written
> > SUBPAGE = dispatch using the lower address bits to obtain final I/O handler.
> thanks.
>
> By the way, if you are available, can you simply explain what is the
> relationship among them and how they work together? such as
> MemoryRegion, RamBlock, PhysPageDesc, and MemorySlot.
>

Sorry, it's a long and complicated story that is changing now.  You'll
have to educate yourself mostly.

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

Re: [Qemu-devel] memory: Why subpage is introduced?

[Zhi Yong Wu]

anyway, thanks.

On Thu, Dec 22, 2011 at 8:38 PM, Avi Kivity <avi@redhat.com> wrote:
> On 12/22/2011 01:24 PM, Zhi Yong Wu wrote:
>> >
>> >> 2.) How to render MemoryRegion into one disjoint flatrange list? That
>> >> rendering function is a bit difficult to understand. Can anyone simply
>> >> explain it?
>> >
>> > What exactly don't you understand?
>> 1.) e.g. some fields such as offset_in_region, terminates, offset in
>> MemoryRegion struct. What are separately their meanings?
>
> Well, read the code, it's not that complicated.  Afterwards you can add
> documentation based on your findings.
>
>> 2.)  render_memory_region(), how does it render one MemoryRegion into
>> the global view flatview? Can you simply explain this function's
>> algorithm logic?
>
> Again, what can I say that the code doesn't?  It recursively descends
> the hierarchy and finds out which region goes where.
>
> Also read docs/memory.txt
>
>>
>> >
>> >>
>> >> 3.) What are separately the meanings of these flags? such as
>> >> IO_MEM_RAM, IO_MEM_ROM, IO_MEM_UNASSIGNED, IO_MEM_*, IO_MEM_ROMD, and
>> >> IO_MEM_SUBPAGE.
>> >
>> > RAM = RAM
>> > ROM = ROM
>> > UNASSIGNED = nothing handles this range
>> > ROMD = ROM when read, device (i.e. callbacks) when written
>> > SUBPAGE = dispatch using the lower address bits to obtain final I/O handler.
>> thanks.
>>
>> By the way, if you are available, can you simply explain what is the
>> relationship among them and how they work together? such as
>> MemoryRegion, RamBlock, PhysPageDesc, and MemorySlot.
>>
>
> Sorry, it's a long and complicated story that is changing now.  You'll
> have to educate yourself mostly.
>
> --
> error compiling committee.c: too many arguments to function
>



-- 
Regards,

Zhi Yong Wu