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

RE: [Xen-devel] Re: Xen-devel Digest, Vol 25, Issue 93


  • To: "PUCCETTI Armand" <armand.puccetti@xxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxx
  • From: "Petersson, Mats" <Mats.Petersson@xxxxxxx>
  • Date: Mon, 12 Mar 2007 17:19:08 +0100
  • Delivery-date: Mon, 12 Mar 2007 09:18:28 -0700
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>
  • Thread-index: AcdkwQgTMoNF2D7XSwCSADsblWep1wAAECQw
  • Thread-topic: [Xen-devel] Re: Xen-devel Digest, Vol 25, Issue 93

> -----Original Message-----
> From: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx 
> [mailto:xen-devel-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of 
> PUCCETTI Armand
> Sent: 12 March 2007 16:11
> To: xen-devel@xxxxxxxxxxxxxxxxxxx
> Subject: [Xen-devel] Re: Xen-devel Digest, Vol 25, Issue 93
> 
> 
> >> When the system boots, the processor is normally in 
> "real-mode", and
> >> it's definitely not got paging enabled. So we have to "make 
> >> the guest OS
> >> believe this is the case". But at the same time, the guest 
> OS is most
> >> likely not loaded at address zero in memory, so we need 
> paging enabled
> >> to remap the GUEST PHYSICAL address to match the machine physical
> >> address. So we have a "linear map" to translate the 
> "address zero" to
> >> the "start of guest memory", and so on for every page of 
> memory in the
> >> guest.
> >>
> >> This is not hard to do, since the AMD-V/VT feature of the processor
> >> expects the paging-bit to be different between what the 
> guest "thinks"
> >> and the actual case. In the AMD-V, there's even support to 
> >> run real-mode
> >> with paging enabled, so all the BIOS-code and such will be 
> running in
> >> this mode. VT has to do a bunch of tricky stuff to work around that
> >> problem.
> >>
> >> Ok fine, does this argument holds true for even non-VT and 
> >> non-Pacifica enabled processors?
> >> I doubt it.
> >>     
> >
> > Not precisely. I'm talking only about HVM mode, which is "full
> > virtualization". PV-mode uses a different paging interface, which at
> > least for most parts, comprise of changing the whole area 
> of code in the
> > kernel that updates the page-tables, by adding code that is 
> aware of the
> > THREE types of address (guest-virtual, guest-physical and
> > machine-physical). This means that there's no real need for the
> > "read-only page-tables" and "shadow-mode" - the page-table 
> just contains
> > the right value for the machine-physical address. [That's not to say
> > that read-only page-tables can't be used in a PV system too 
> - I'm not
> > 100% sure how the page-table management works in the PV mode]. 
> >   
> That is very interesting info on the paging system. Mats, 
> could you please
> explain a bit the working of the PV paging? How do the the guest+host 
> page tables work
> together? What does the guest page table point to, i.e. 
> how+when is it 
> mapped onto the host page table?
> 
> I have seen in the code that there are different cases of guest+host 
> paging table heights. Why?

I'm sorry, I don't quite know this. I believe that the page-table has to
be the same number of levels in both Xen and the PV guest. 

There's been some recent work to implement 32-bit PV on 64-bit HV, which
I think changes this by allowing a 32-bit PAE guest to run on a 64-bit
hypervisor. Someone else who works more on PV is probably better to
answer this... 

In HVM, you definitely have 32-bit both PAE and non-PAE on 64-bit HV,
which obviously means different number of page-table levels (2, 3 or 4
respectively for non-PAE, PAE and 64-bit). 

--
Mats


> 
> thanks. Armand



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel


 


Rackspace

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