I have two questions regarding x86_64 xen boot code - 1. It looks like Xen base virtual address is 0xFFFF830000000000. That''s why Page table needs to have mirror mapping for lower and higher virtual address. If the base virtual address would have been 0 (__PAGE_OFFSET), code in file x86_64.S would have been much easy to understand and maintain. So, is there a specific reason to choose this high virtual address? 2. Why do we need to subtract FIRST_RESERVED_GDT_BYTE (14 pages) from address of gdt_table when calculating the base address for GDT table? How does this subtraction give the right address for GDT table? _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Answer to both questions is that we want to keep out of the way of paravirtual guest OS addressing. Guests want to use virtual addresses from 0x0, so Xen has to be raised up out of the way. Similarly, guests may expect to use GDT entries starting from entry 0 upwards, and hence Xen gets pushed up to the last two pages of a full-size GDT. Both of these shifts are required because Xen shares its own virtual-memory structures (GDT, page tables) with the guest, for efficient switching between guest context and hypervisor context. -- Keir On 8/3/08 23:07, "Agarwal, Lomesh" <lomesh.agarwal@intel.com> wrote:> I have two questions regarding x86_64 xen boot code - > 1. It looks like Xen base virtual address is 0xFFFF830000000000. That''s > why Page table needs to have mirror mapping for lower and higher virtual > address. If the base virtual address would have been 0 (__PAGE_OFFSET), > code in file x86_64.S would have been much easy to understand and > maintain. So, is there a specific reason to choose this high virtual > address? > 2. Why do we need to subtract FIRST_RESERVED_GDT_BYTE (14 pages) from > address of gdt_table when calculating the base address for GDT table? > How does this subtraction give the right address for GDT table? > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Agarwal, Lomesh
2008-Mar-10 16:26 UTC
RE: [Xen-devel] question about xen virtual base address
If there are more than one PV guests then how does Xen share its virtual address with all of the PV guests? BTW how does this sharing translate to performance gain? -----Original Message----- From: Keir Fraser [mailto:keir.fraser@eu.citrix.com] Sent: Sunday, March 09, 2008 8:31 AM To: Agarwal, Lomesh; xen-devel@lists.xensource.com Subject: Re: [Xen-devel] question about xen virtual base address Answer to both questions is that we want to keep out of the way of paravirtual guest OS addressing. Guests want to use virtual addresses from 0x0, so Xen has to be raised up out of the way. Similarly, guests may expect to use GDT entries starting from entry 0 upwards, and hence Xen gets pushed up to the last two pages of a full-size GDT. Both of these shifts are required because Xen shares its own virtual-memory structures (GDT, page tables) with the guest, for efficient switching between guest context and hypervisor context. -- Keir On 8/3/08 23:07, "Agarwal, Lomesh" <lomesh.agarwal@intel.com> wrote:> I have two questions regarding x86_64 xen boot code - > 1. It looks like Xen base virtual address is 0xFFFF830000000000.That''s> why Page table needs to have mirror mapping for lower and highervirtual> address. If the base virtual address would have been 0(__PAGE_OFFSET),> code in file x86_64.S would have been much easy to understand and > maintain. So, is there a specific reason to choose this high virtual > address? > 2. Why do we need to subtract FIRST_RESERVED_GDT_BYTE (14 pages) from > address of gdt_table when calculating the base address for GDT table? > How does this subtraction give the right address for GDT table? > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Daniel Stodden
2008-Mar-10 17:08 UTC
RE: [Xen-devel] question about xen virtual base address
On Mon, 2008-03-10 at 09:26 -0700, Agarwal, Lomesh wrote:> If there are more than one PV guests then how does Xen share its virtual > address with all of the PV guests? > BTW how does this sharing translate to performance gain?You could -- in theory -- put the entire VMM or at least a large part of it into a separate virtual address space and switch address spaces upon each entry and return. That avoids ''address space compression'', but it''s very costly, especially since a TLB flush would be required. So instead one lets a process, its guest kernel and the VMM share one virtual address space. As with regular OSes: one address space per guest process. Control transfers between process, kernel and VMM does not switch between virtual memories, but only privileges, stacks, and EIP. -> much faster. The top of the virtual address range dedicated to the VMM is the same, typically mapped by the same PT set. Likewise, all processes in a guest system (whether guest or native) share the same kernel range. Only the process part is unique. The address space only has to change when switching guests or processes within those guests. That''s not the whole story regarding memory virtualization, but about the general idea.> -----Original Message----- > From: Keir Fraser [mailto:keir.fraser@eu.citrix.com] > Sent: Sunday, March 09, 2008 8:31 AM > To: Agarwal, Lomesh; xen-devel@lists.xensource.com > Subject: Re: [Xen-devel] question about xen virtual base address > > Answer to both questions is that we want to keep out of the way of > paravirtual guest OS addressing. Guests want to use virtual addresses > from > 0x0, so Xen has to be raised up out of the way. Similarly, guests may > expect > to use GDT entries starting from entry 0 upwards, and hence Xen gets > pushed > up to the last two pages of a full-size GDT. Both of these shifts are > required because Xen shares its own virtual-memory structures (GDT, page > tables) with the guest, for efficient switching between guest context > and > hypervisor context. > > -- Keir > > On 8/3/08 23:07, "Agarwal, Lomesh" <lomesh.agarwal@intel.com> wrote: > > > I have two questions regarding x86_64 xen boot code - > > 1. It looks like Xen base virtual address is 0xFFFF830000000000. > That''s > > why Page table needs to have mirror mapping for lower and higher > virtual > > address. If the base virtual address would have been 0 > (__PAGE_OFFSET), > > code in file x86_64.S would have been much easy to understand and > > maintain. So, is there a specific reason to choose this high virtual > > address? > > 2. Why do we need to subtract FIRST_RESERVED_GDT_BYTE (14 pages) from > > address of gdt_table when calculating the base address for GDT table? > > How does this subtraction give the right address for GDT table? > > > > _______________________________________________ > > Xen-devel mailing list > > Xen-devel@lists.xensource.com > > http://lists.xensource.com/xen-devel > > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel-- Daniel Stodden LRR - Lehrstuhl für Rechnertechnik und Rechnerorganisation Institut für Informatik der TU München D-85748 Garching http://www.lrr.in.tum.de/~stodden mailto:stodden@cs.tum.edu PGP Fingerprint: F5A4 1575 4C56 E26A 0B33 3D80 457E 82AE B0D8 735B _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Agarwal, Lomesh
2008-Mar-10 21:44 UTC
RE: [Xen-devel] question about xen virtual base address
I don''t understand how are GDT table entries for Xen created? Init. Code subtracts 14 pages from gdt_table address for GDT table address. Who populates entries at that address? -----Original Message----- From: Keir Fraser [mailto:keir.fraser@eu.citrix.com] Sent: Sunday, March 09, 2008 8:31 AM To: Agarwal, Lomesh; xen-devel@lists.xensource.com Subject: Re: [Xen-devel] question about xen virtual base address Answer to both questions is that we want to keep out of the way of paravirtual guest OS addressing. Guests want to use virtual addresses from 0x0, so Xen has to be raised up out of the way. Similarly, guests may expect to use GDT entries starting from entry 0 upwards, and hence Xen gets pushed up to the last two pages of a full-size GDT. Both of these shifts are required because Xen shares its own virtual-memory structures (GDT, page tables) with the guest, for efficient switching between guest context and hypervisor context. -- Keir On 8/3/08 23:07, "Agarwal, Lomesh" <lomesh.agarwal@intel.com> wrote:> I have two questions regarding x86_64 xen boot code - > 1. It looks like Xen base virtual address is 0xFFFF830000000000.That''s> why Page table needs to have mirror mapping for lower and highervirtual> address. If the base virtual address would have been 0(__PAGE_OFFSET),> code in file x86_64.S would have been much easy to understand and > maintain. So, is there a specific reason to choose this high virtual > address? > 2. Why do we need to subtract FIRST_RESERVED_GDT_BYTE (14 pages) from > address of gdt_table when calculating the base address for GDT table? > How does this subtraction give the right address for GDT table? > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel