Proper place for an overview of Xen virtual space

Proper place for an overview of Xen virtual space

[Petr Tesarik]

[-- Attachment #1: Type: Text/Plain, Size: 297 bytes --]

Hello all,

while working on makedumpfile support of Xen4, I made a side-by-side 
comparison of the Xen3 and Xen4 virtual space on x86_64 (attached). I believe 
that it can be useful to others as well, but I don't know what would be an 
appropriate place for it.

Regards,
Petr Tesarik
SUSE Linux

[-- Attachment #2: Xen Virtual Memory Map --]
[-- Type: text/html, Size: 4650 bytes --]

[-- Attachment #3: Type: text/plain, Size: 126 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: Proper place for an overview of Xen virtual space

[Ian Campbell]

On Thu, 2012-07-26 at 10:29 +0100, Petr Tesarik wrote:
> Hello all,
> 
> while working on makedumpfile support of Xen4, I made a side-by-side 
> comparison of the Xen3 and Xen4 virtual space on x86_64 (attached). I believe 
> that it can be useful to others as well, but I don't know what would be an 
> appropriate place for it.

Somewhere on the wiki perhaps?

BTW I don't think Xen3 and Xen4 are the right labels, perhaps 3.4 and
4.0? The 3->4 major number change was only a number change, it didn't
signal a rearchitecting or anything like that (other than the normal
development between a release). Labelling it Xen3 and Xen4 suggests it
did.

Re: Proper place for an overview of Xen virtual space

[George Dunlap]

On Thu, Jul 26, 2012 at 2:53 PM, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> On Thu, 2012-07-26 at 10:29 +0100, Petr Tesarik wrote:
>> Hello all,
>>
>> while working on makedumpfile support of Xen4, I made a side-by-side
>> comparison of the Xen3 and Xen4 virtual space on x86_64 (attached). I believe
>> that it can be useful to others as well, but I don't know what would be an
>> appropriate place for it.
>
> Somewhere on the wiki perhaps?

The comparison would probably go on the wiki somewhere.  Do we have a
layout for memory in the documentation directory in-tree?  If not,
that might be useful.  But it should be only the current memory
layout, I think; a comparison is best suited to a wiki.

 -George

Re: Proper place for an overview of Xen virtual space

[Ian Campbell]

On Thu, 2012-07-26 at 15:08 +0100, George Dunlap wrote:
> On Thu, Jul 26, 2012 at 2:53 PM, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> > On Thu, 2012-07-26 at 10:29 +0100, Petr Tesarik wrote:
> >> Hello all,
> >>
> >> while working on makedumpfile support of Xen4, I made a side-by-side
> >> comparison of the Xen3 and Xen4 virtual space on x86_64 (attached). I believe
> >> that it can be useful to others as well, but I don't know what would be an
> >> appropriate place for it.
> >
> > Somewhere on the wiki perhaps?
> 
> The comparison would probably go on the wiki somewhere.  Do we have a
> layout for memory in the documentation directory in-tree?  If not,
> that might be useful.  But it should be only the current memory
> layout, I think; a comparison is best suited to a wiki.

There's comments in xen/include/asm-*/config.h with the layout.

Re: Proper place for an overview of Xen virtual space

[Petr Tesarik]

Dne Čt 26. července 2012 15:53:33 Ian Campbell napsal(a):
> On Thu, 2012-07-26 at 10:29 +0100, Petr Tesarik wrote:
> > Hello all,
> > 
> > while working on makedumpfile support of Xen4, I made a side-by-side
> > comparison of the Xen3 and Xen4 virtual space on x86_64 (attached). I
> > believe that it can be useful to others as well, but I don't know what
> > would be an appropriate place for it.
> 
> Somewhere on the wiki perhaps?

Sure, I can add a page there, but nobody will find it unless I link it from 
somewhere, but I'm unable to find a good place for the link.

> BTW I don't think Xen3 and Xen4 are the right labels, perhaps 3.4 and
> 4.0? The 3->4 major number change was only a number change, it didn't
> signal a rearchitecting or anything like that (other than the normal
> development between a release). Labelling it Xen3 and Xen4 suggests it
> did.

And until now I've though this was indeed the case. At least many internal 
structures used by the kdump infrastructure have changed substantially between 
3.4 and 4.0, while they remained the same at least from 3.0.2 to 3.4.

Anyway, why wasn't 4.0 labelled 3.5 if there was no big change?

Petr Tesarik
SUSE Linux

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: Proper place for an overview of Xen virtual space

[Jan Beulich]

>>> On 27.07.12 at 07:41, Petr Tesarik <ptesarik@suse.cz> wrote:
> Anyway, why wasn't 4.0 labelled 3.5 if there was no big change?

It was until pretty late in the release process. Iirc during late 3.4
the transition to 4.0 was already done and then reverted. All of
this more for marketing/PR purposes than for technical reasons
(much like Linux'es 2.6.x -> 3.x transition).

Jan

Re: Proper place for an overview of Xen virtual space

[Ian Campbell]

On Fri, 2012-07-27 at 06:41 +0100, Petr Tesarik wrote:
> Dne Čt 26. července 2012 15:53:33 Ian Campbell napsal(a):
> > On Thu, 2012-07-26 at 10:29 +0100, Petr Tesarik wrote:
> > > Hello all,
> > > 
> > > while working on makedumpfile support of Xen4, I made a side-by-side
> > > comparison of the Xen3 and Xen4 virtual space on x86_64 (attached). I
> > > believe that it can be useful to others as well, but I don't know what
> > > would be an appropriate place for it.
> > 
> > Somewhere on the wiki perhaps?
> 
> Sure, I can add a page there, but nobody will find it unless I link it from 
> somewhere, but I'm unable to find a good place for the link.

It will at least mean I can answer the question "how has the memory map
changed" with a link instead of an actual explanation, and once a few
people have asked it'll start to show up on google etc due to the links
in the ML archives and so on.

You should also ensure to add it to the proper categories on the wiki so
that people searching the wiki can find it.

> Anyway, why wasn't 4.0 labelled 3.5 if there was no big change?

It's just a number and people felt like it was time. Like the Linux
2.6.x->3.x transition.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: Proper place for an overview of Xen virtual space

[Konrad Rzeszutek Wilk]

On Thu, Jul 26, 2012 at 11:29:21AM +0200, Petr Tesarik wrote:
> Hello all,
> 
> while working on makedumpfile support of Xen4, I made a side-by-side 
> comparison of the Xen3 and Xen4 virtual space on x86_64 (attached). I believe 
> that it can be useful to others as well, but I don't know what would be an 
> appropriate place for it.

Nice!

It might be also usefull to add the PGD/PUd indexes so one knows that that
the M2P sits in 261 (and in 256), ioremap is 267, etc..

> 
> Regards,
> Petr Tesarik
> SUSE Linux

> <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
> <html>
> <head>
> <title>Xen Memory Map</title>
> <style type="text/css">
> body { color: black; background-color: white; }
> td { padding: 4px; }
> th { padding: 4px; }
> tr { vertical-align: top; }
> td.hrule { height:1px; padding: 0px; margin: 0px; background-color: black; }
> td.addr { font-family: monospace; padding-right: 16px; }
> td.code { background-color: #000080; color: white; }
> td.compat { background-color: #800000; color: white; }
> td.direct { background-color: #ffff00; }
> td.frametable { background-color: #008080; color: white; }
> td.guest { }
> td.ioremap { background-color: #008000; color: white; }
> td.mpt { background-color: #00ff00; }
> td.pagetable { }
> td.perdomain { }
> td.reserved { background-color: #c0c0c0; }
> td.unavail { background-color: #808080; color: white; }
> </style>
> </head>
> <body>
> <table>
> <thead>
>   <tr><th>Range</th> <th>Xen3</th> <th>Xen4</th></tr>
>   <tr><td class=hrule colspan=3></td></tr>
> </thead>
> <tbody>
> <tr>
>   <td class=addr>0x0000000000000000<br>0x00007fffffffffff</td>
>   <td class=guest colspan=2>[128T] Guest-defined use</td>
> </tr>
> <tr>
>   <td class=addr>0x0000800000000000<br>0xffff7fffffffffff</td>
>   <td class=unavail colspan=2>[16E] Inaccessible</td>
> </tr>
> <tr>
>   <td class=addr>0xffff800000000000<br>0xffff803fffffffff</td>
>   <td class=guest colspan=2>[256G] Read-only machine-to-phys translation table
>   (GUEST ACCESSIBLE)</td>
> </tr>
> <tr>
>   <td class=addr>0xffff804000000000<br>0xffff807fffffffff</td>
>   <td class=reserved colspan=2>[256G] Reserved for future shared info with the
>   guest OS (GUEST ACCESSIBLE)</td>
> </tr>
> <tr>
>   <td class=addr>0xffff808000000000<br>0xffff80ffffffffff</td>
>   <td class=reserved>[512G] Reserved for future use</td>
>   <td class=ioremap>[512G] ioremap for PCI mmconfig space</td>
> </tr>
> <tr>
>   <td class=addr>0xffff810000000000<br>0xffff817fffffffff</td>
>   <td class=pagetable colspan=2>[512G] Guest linear page table</td>
> </tr>
> <tr>
>   <td class=addr>0xffff818000000000<br>0xffff81ffffffffff</td>
>   <td class=pagetable colspan=2>[512G] Shadow linear page table</td>
> </tr>
> <tr>
>   <td class=addr>0xffff820000000000<br>0xffff827fffffffff</td>
>   <td class=perdomain colspan=2>[512G] Per-domain mappings (e.g., GDT, LDT)</td>
> </tr>
> <tr>
>   <td class=addr>0xffff828000000000<br>0xffff8283ffffffff</td>
>   <td class=mpt>[16G] Machine-to-phys translation table</td>
>   <td class=mpt rowspan=7>[256G] Machine-to-phys translation table</td>
> </tr>
> <tr>
>   <td class=addr>0xffff828400000000<br>0xffff8287ffffffff</td>
>   <td class=frametable>[16G] Page-frame information array</td>
> </tr>
> <tr>
>   <td class=addr>0xffff828800000000<br>0xffff828bffffffff</td>
>   <td class=ioremap>[16G] ioremap()/fixmap area</td>
> </tr>
> <tr>
>   <td class=addr>0xffff828c00000000<br>0xffff828c3fffffff</td>
>   <td class=compat>[1G] Compatibility machine-to-phys translation table</td>
> </tr>
> <tr>
>   <td class=addr>0xffff828c40000000<br>0xffff828c7fffffff</td>
>   <td class=compat>[1G] High read-only compat machine-to-phys translation table</td>
> </tr>
> <tr>
>   <td class=addr>0xffff828c80000000<br>0xffff828cbfffffff</td>
>   <td class=code>[1G] Xen text, static data, bss</td>
> </tr>
> <tr>
>   <td class=addr>0xffff828cc0000000<br>0xffff82bfffffffff</td>
>   <td class=reserved rowspan=7>[461G] Reserved for future use</td>
> </tr>
> <tr>
>   <td class=addr>0xffff82c000000000<br>0xffff82c3ffffffff</td>
>   <td class=ioremap>[16G] ioremap()/fixmap area</td>
> </tr>
> <tr>
>   <td class=addr>0xffff82c400000000<br>0xffff82c43fffffff</td>
>   <td class=compat>[1G] Compatibility machine-to-phys translation table</td>
> </tr>
> <tr>
>   <td class=addr>0xffff82c440000000<br>0xffff82c47fffffff</td>
>   <td class=compat>[1G] High read-only compat machine-to-phys translation table</td>
> </tr>
> <tr>
>   <td class=addr>0xffff82c480000000<br>0xffff82c4bfffffff</td>
>   <td class=code>[1G] Xen text, static data, bss</td>
> </tr>
> <tr>
>   <td class=addr>0xffff82c4c0000000<br>0xffff82f5ffffffff</td>
>   <td class=reserved>[197G] Reserved for future use</td>
> </tr>
> <tr>
>   <td class=addr>0xffff82f600000000<br>0xffff82ffffffffff</td>
>   <td class=frametable>[40G] Page-frame information array</td>
> </tr>
> <tr>
>   <td class=addr>0xffff830000000000<br>0xffff83ffffffffff</td>
>   <td class=direct>[1T] 1:1 direct mapping of all physical memory</td>
>   <td class=direct rowspan=2>[5T] 1:1 direct mapping of all physical memory</td>
> </tr>
> <tr>
>   <td class=addr>0xffff840000000000<br>0xffff87ffffffffff</td>
>   <td class=reserved>[4T] Reserved for future use</td>
> </tr>
> <tr>
>   <td class=addr>0xffff880000000000<br>0xffffffffffffffff</td>
>   <td class=guest colspan=2>[120T] Guest-defined use</td>
> </tr>
> </tbody>
> </table>
> </body>
> </html>

> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel