[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] start of day mem layout


  • To: Ian Pratt <m+Ian.Pratt@xxxxxxxxxxxx>
  • From: Richard <judicator3@xxxxxxxxx>
  • Date: Thu, 17 Mar 2005 17:01:06 -0500
  • Cc: xen-devel@xxxxxxxxxxxxxxxxxxxxx, ian.pratt@xxxxxxxxxxxx
  • Delivery-date: Thu, 17 Mar 2005 22:40:41 +0000
  • Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=q6U9VAliiIBn4mjxy2jz1WBWB4a9FF8aqzGcrw/pWJVaEWliOQHR+Y8SQInFWrBRegf0ahKucYg/pEwB6/Nhm2jzsHMQgTegHwycVPBqnoSxdcIAQBLP3QK+bu2X1lOCA/w0X/uDQwzwksh4OttUPY7MG4x/HFzJu0cEVKXF59c=
  • List-id: List for Xen developers <xen-devel.lists.sourceforge.net>

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@xxxxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxxx
> > 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@xxxxxxxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.