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

RE: [Xen-ia64-devel] Uncached offset: Region 6 -> lower half ofVTi-reserved VM space


  • To: "Tian, Kevin" <kevin.tian@xxxxxxxxx>, <xen-ia64-devel@xxxxxxxxxxxxxxxxxxx>
  • From: "Magenheimer, Dan (HP Labs Fort Collins)" <dan.magenheimer@xxxxxx>
  • Date: Tue, 14 Jun 2005 07:41:20 -0700
  • Delivery-date: Tue, 14 Jun 2005 14:40:15 +0000
  • List-id: DIscussion of the ia64 port of Xen <xen-ia64-devel.lists.xensource.com>
  • Thread-index: AcVwX+CR8RimBlWdTgqhrwBuwdjrAAAQYluQABNGZ1A=
  • Thread-topic: [Xen-ia64-devel] Uncached offset: Region 6 -> lower half ofVTi-reserved VM space

> >I've just pushed a patch to xeno-unstable-ia64.bk which finishes
> >the virtual address changes submitted by Intel (Kevin, I think)
> >some months ago, where the Xen-reserved VA space was changed from
> >     0xf000000000000000-0xf7ffffffffffffff
> >             to
> >     0xe800000000000000-0xf7ffffffffffffff
> >to correspond to one less bit in the guest's virtual address
> >space.
> 
> You change seems clean to understand. Before submitting a 
> patch for VTI,
> I'd like to confirm one thing: whether you want to split cache/uncache
> access in different region, or in same region? It seems 
> cleaner to stay
> with different region, as Linux currently does. Then if still 
> in region
> 6 for "uncached" area, 0xd000000000000000 is just same effect as
> 0xf000000000000000 to hide one bit to guest.

Good point.  One unstated goal was to have a single contiguous
virtual address range for Xen to make virtual address validation
easier.  Is there any advantage (or architectural reason) to
have cached and uncached in separate regions?

Dan

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


 


Rackspace

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