All of lore.kernel.org
 help / color / mirror / Atom feed
* start of day mem layout
@ 2005-03-17 21:11 Richard
  0 siblings, 0 replies; 4+ messages in thread
From: Richard @ 2005-03-17 21:11 UTC (permalink / raw)
  To: xen-devel

Hi,

I am working on updating the mini-os to work on XEN 2.0. I am
currently working on the memory management part of mini-os. I am
trying to undestand the start of day memory layout that the guest
domain (mini-os) gets from XEN when it 1st boots up. From what I
undestand, 4 MB of memory are already mapped and virtual memory
from 0xC000_0000 to 0xC040_0000 (4MB) are accessible. XEN already
allocates a pgd and ONE page table for this 4MB vritual memory
mapping.

I am booting mini-os with 16 MB of memory and these are the
information I get:

shared_info                0xc0001000
pfn_to_mfn                 0xc0010000
Page Global Directory      0xc0014000
Page Table                 0xc0015000
start_info                 0xc0016000

Also, I think my kernel image contains some symbols such as _text,
_etext, _edata, _end. 

 _text                     0xc0000000
_etext                     0xc0007c04
_edata                     0xc000d2c0
_end                       0x819

I try to draw the virtual mem layout below. Sorry if it does not
appear correctly because of different fonts.

               _edata             start_info
               c000d2c0             c0016000
  shared_info    |            PGD    |
   c0001000      |         c0014000  |
       |         |             |     | 
  ------------------------------------------
  |    |    |    |    |        |  |  |
  |    |    |    |    |        |  |  |
  |    |    |    |    |        |  |  |
  ------------------------------------------
  |         |         |           |
  c0000000  |       c0010000    c0015000  
  _text     |      pfn_to_mfn      PT
            |
          _etext         
          c0007c04

I have a few questions. If someone could give some feedback that
would be very appreciated.

I am not sure if those symbols _text, _etext, _edata and _end are
meaningful or not, but is it correct to have the shared_info in the
middle of my kernel image between _text and _etext ?

The default control ring between domain0 and a guest OS is found
at shared_info + 2048 offset, is that still valid ?

Is there anything important after the start_info structure ?
Is address starting at c0016000 + sizeof(start_info) available
to use ?  

Also my _end symbol is found at address 0x819, so I don't quite
udnestand that. Maybe something wrong I am doing in the linking
process of my kernel image.

Thanks
Richard


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click

^ permalink raw reply	[flat|nested] 4+ messages in thread

* RE: start of day mem layout
@ 2005-03-17 21:31 Ian Pratt
  2005-03-17 22:01 ` Richard
  0 siblings, 1 reply; 4+ messages in thread
From: Ian Pratt @ 2005-03-17 21:31 UTC (permalink / raw)
  To: Richard, xen-devel; +Cc: ian.pratt

> I am working on updating the mini-os to work on XEN 2.0. I am
> currently working on the memory management part of mini-os. I am
> trying to undestand the start of day memory layout that the guest
> domain (mini-os) gets from XEN when it 1st boots up. From what I
> undestand, 4 MB of memory are already mapped and virtual memory
> from 0xC000_0000 to 0xC040_0000 (4MB) are accessible. XEN already
> allocates a pgd and ONE page table for this 4MB vritual memory
> mapping.
 
A worthy effort, thanks for doing this.

I can't remember this stuff off-hand, but hopefully someone who's done a
port recently will speak up.

Ian


> I am booting mini-os with 16 MB of memory and these are the
> information I get:
> 
> shared_info                0xc0001000
> pfn_to_mfn                 0xc0010000
> Page Global Directory      0xc0014000
> Page Table                 0xc0015000
> start_info                 0xc0016000
> 
> Also, I think my kernel image contains some symbols such as _text,
> _etext, _edata, _end. 
> 
>  _text                     0xc0000000
> _etext                     0xc0007c04
> _edata                     0xc000d2c0
> _end                       0x819
> 
> I try to draw the virtual mem layout below. Sorry if it does not
> appear correctly because of different fonts.
> 
>                _edata             start_info
>                c000d2c0             c0016000
>   shared_info    |            PGD    |
>    c0001000      |         c0014000  |
>        |         |             |     | 
>   ------------------------------------------
>   |    |    |    |    |        |  |  |
>   |    |    |    |    |        |  |  |
>   |    |    |    |    |        |  |  |
>   ------------------------------------------
>   |         |         |           |
>   c0000000  |       c0010000    c0015000  
>   _text     |      pfn_to_mfn      PT
>             |
>           _etext         
>           c0007c04
> 
> I have a few questions. If someone could give some feedback that
> would be very appreciated.
> 
> I am not sure if those symbols _text, _etext, _edata and _end are
> meaningful or not, but is it correct to have the shared_info in the
> middle of my kernel image between _text and _etext ?
> 
> The default control ring between domain0 and a guest OS is found
> at shared_info + 2048 offset, is that still valid ?
> 
> Is there anything important after the start_info structure ?
> Is address starting at c0016000 + sizeof(start_info) available
> to use ?  
> 
> Also my _end symbol is found at address 0x819, so I don't quite
> udnestand that. Maybe something wrong I am doing in the linking
> process of my kernel image.
> 
> Thanks
> Richard
> 
> 
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from 
> real users.
> Discover which products truly live up to the hype. Start reading now.
> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/xen-devel
> 


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95&alloc_id\x14396&op=click

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: start of day mem layout
  2005-03-17 21:31 start of day mem layout Ian Pratt
@ 2005-03-17 22:01 ` Richard
  2005-03-18  5:03   ` Mark Williamson
  0 siblings, 1 reply; 4+ messages in thread
From: Richard @ 2005-03-17 22:01 UTC (permalink / raw)
  To: Ian Pratt; +Cc: xen-devel, ian.pratt

Hi Ian,

Thanks for the response.
Just out of curiosity, the mini-os code was targeted at what version
of XEN ? I would say a very early one right ? perhaps even before XEN
1.3 ?

Thanks
Richard

On Thu, 17 Mar 2005 21:31:31 -0000, Ian Pratt <m+Ian.Pratt@cl.cam.ac.uk> wrote:
> > I am working on updating the mini-os to work on XEN 2.0. I am
> > currently working on the memory management part of mini-os. I am
> > trying to undestand the start of day memory layout that the guest
> > domain (mini-os) gets from XEN when it 1st boots up. From what I
> > undestand, 4 MB of memory are already mapped and virtual memory
> > from 0xC000_0000 to 0xC040_0000 (4MB) are accessible. XEN already
> > allocates a pgd and ONE page table for this 4MB vritual memory
> > mapping.
> 
> A worthy effort, thanks for doing this.
> 
> I can't remember this stuff off-hand, but hopefully someone who's done a
> port recently will speak up.
> 
> Ian
> 
> 
> > I am booting mini-os with 16 MB of memory and these are the
> > information I get:
> >
> > shared_info                0xc0001000
> > pfn_to_mfn                 0xc0010000
> > Page Global Directory      0xc0014000
> > Page Table                 0xc0015000
> > start_info                 0xc0016000
> >
> > Also, I think my kernel image contains some symbols such as _text,
> > _etext, _edata, _end.
> >
> >  _text                     0xc0000000
> > _etext                     0xc0007c04
> > _edata                     0xc000d2c0
> > _end                       0x819
> >
> > I try to draw the virtual mem layout below. Sorry if it does not
> > appear correctly because of different fonts.
> >
> >                _edata             start_info
> >                c000d2c0             c0016000
> >   shared_info    |            PGD    |
> >    c0001000      |         c0014000  |
> >        |         |             |     |
> >   ------------------------------------------
> >   |    |    |    |    |        |  |  |
> >   |    |    |    |    |        |  |  |
> >   |    |    |    |    |        |  |  |
> >   ------------------------------------------
> >   |         |         |           |
> >   c0000000  |       c0010000    c0015000
> >   _text     |      pfn_to_mfn      PT
> >             |
> >           _etext
> >           c0007c04
> >
> > I have a few questions. If someone could give some feedback that
> > would be very appreciated.
> >
> > I am not sure if those symbols _text, _etext, _edata and _end are
> > meaningful or not, but is it correct to have the shared_info in the
> > middle of my kernel image between _text and _etext ?
> >
> > The default control ring between domain0 and a guest OS is found
> > at shared_info + 2048 offset, is that still valid ?
> >
> > Is there anything important after the start_info structure ?
> > Is address starting at c0016000 + sizeof(start_info) available
> > to use ?
> >
> > Also my _end symbol is found at address 0x819, so I don't quite
> > udnestand that. Maybe something wrong I am doing in the linking
> > process of my kernel image.
> >
> > Thanks
> > Richard
> >
> >
> > -------------------------------------------------------
> > SF email is sponsored by - The IT Product Guide
> > Read honest & candid reviews on hundreds of IT Products from
> > real users.
> > Discover which products truly live up to the hype. Start reading now.
> > http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/xen-devel
> >
>


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: start of day mem layout
  2005-03-17 22:01 ` Richard
@ 2005-03-18  5:03   ` Mark Williamson
  0 siblings, 0 replies; 4+ messages in thread
From: Mark Williamson @ 2005-03-18  5:03 UTC (permalink / raw)
  To: xen-devel, Richard; +Cc: Ian Pratt, ian.pratt

> Thanks for the response.
> Just out of curiosity, the mini-os code was targeted at what version
> of XEN ? I would say a very early one right ? perhaps even before XEN
> 1.3 ?

I think it might have been there with the 1.0 release.  It was, I think, 
working around the 1.2 timeframe.  Don't know if it ever got updated during 
the 1.3/2.0 development cycle.

Cheers,
Mark

> Thanks
> Richard
>
> On Thu, 17 Mar 2005 21:31:31 -0000, Ian Pratt <m+Ian.Pratt@cl.cam.ac.uk> 
wrote:
> > > I am working on updating the mini-os to work on XEN 2.0. I am
> > > currently working on the memory management part of mini-os. I am
> > > trying to undestand the start of day memory layout that the guest
> > > domain (mini-os) gets from XEN when it 1st boots up. From what I
> > > undestand, 4 MB of memory are already mapped and virtual memory
> > > from 0xC000_0000 to 0xC040_0000 (4MB) are accessible. XEN already
> > > allocates a pgd and ONE page table for this 4MB vritual memory
> > > mapping.
> >
> > A worthy effort, thanks for doing this.
> >
> > I can't remember this stuff off-hand, but hopefully someone who's done a
> > port recently will speak up.
> >
> > Ian
> >
> > > I am booting mini-os with 16 MB of memory and these are the
> > > information I get:
> > >
> > > shared_info                0xc0001000
> > > pfn_to_mfn                 0xc0010000
> > > Page Global Directory      0xc0014000
> > > Page Table                 0xc0015000
> > > start_info                 0xc0016000
> > >
> > > Also, I think my kernel image contains some symbols such as _text,
> > > _etext, _edata, _end.
> > >
> > >  _text                     0xc0000000
> > > _etext                     0xc0007c04
> > > _edata                     0xc000d2c0
> > > _end                       0x819
> > >
> > > I try to draw the virtual mem layout below. Sorry if it does not
> > > appear correctly because of different fonts.
> > >
> > >                _edata             start_info
> > >                c000d2c0             c0016000
> > >   shared_info    |            PGD    |
> > >    c0001000      |         c0014000  |
> > >
> > >   ------------------------------------------
> > >
> > >
> > >
> > >   ------------------------------------------
> > >
> > >   c0000000  |       c0010000    c0015000
> > >   _text     |      pfn_to_mfn      PT
> > >
> > >           _etext
> > >           c0007c04
> > >
> > > I have a few questions. If someone could give some feedback that
> > > would be very appreciated.
> > >
> > > I am not sure if those symbols _text, _etext, _edata and _end are
> > > meaningful or not, but is it correct to have the shared_info in the
> > > middle of my kernel image between _text and _etext ?
> > >
> > > The default control ring between domain0 and a guest OS is found
> > > at shared_info + 2048 offset, is that still valid ?
> > >
> > > Is there anything important after the start_info structure ?
> > > Is address starting at c0016000 + sizeof(start_info) available
> > > to use ?
> > >
> > > Also my _end symbol is found at address 0x819, so I don't quite
> > > udnestand that. Maybe something wrong I am doing in the linking
> > > process of my kernel image.
> > >
> > > Thanks
> > > Richard
> > >
> > >
> > > -------------------------------------------------------
> > > SF email is sponsored by - The IT Product Guide
> > > Read honest & candid reviews on hundreds of IT Products from
> > > real users.
> > > Discover which products truly live up to the hype. Start reading now.
> > > http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
> > > _______________________________________________
> > > Xen-devel mailing list
> > > Xen-devel@lists.sourceforge.net
> > > https://lists.sourceforge.net/lists/listinfo/xen-devel
>
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real users.
> Discover which products truly live up to the hype. Start reading now.
> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/xen-devel


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2005-03-18  5:03 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2005-03-17 21:31 start of day mem layout Ian Pratt
2005-03-17 22:01 ` Richard
2005-03-18  5:03   ` Mark Williamson
  -- strict thread matches above, loose matches on Subject: below --
2005-03-17 21:11 Richard

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.