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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
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.
Konrad Rzeszutek Wilk
2012-Jul-26 13:54 UTC
Re: Proper place for an overview of Xen virtual space
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
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
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.
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
>>> 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
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