This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


[Xen-ia64-devel] [Patch] Adapts to uncached offset change for VTI

To: "Magenheimer, Dan \(HP Labs Fort Collins\)" <dan.magenheimer@xxxxxx>, <xen-ia64-devel@xxxxxxxxxxxxxxxxxxx>
Subject: [Xen-ia64-devel] [Patch] Adapts to uncached offset change for VTI
From: "Tian, Kevin" <kevin.tian@xxxxxxxxx>
Date: Thu, 16 Jun 2005 09:41:32 +0800
Delivery-date: Thu, 16 Jun 2005 01:40:38 +0000
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
List-help: <mailto:xen-ia64-devel-request@lists.xensource.com?subject=help>
List-id: DIscussion of the ia64 port of Xen <xen-ia64-devel.lists.xensource.com>
List-post: <mailto:xen-ia64-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-ia64-devel>, <mailto:xen-ia64-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-ia64-devel>, <mailto:xen-ia64-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-ia64-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-topic: [Patch] Adapts to uncached offset change for VTI
Then serial port back to work again. Please apply.

Signed-off-by Kevin Tian <Kevin.tian@xxxxxxxxx>


>-----Original Message-----
>From: Magenheimer, Dan (HP Labs Fort Collins)
>Sent: Thursday, June 16, 2005 12:44 AM
>To: Tian, Kevin; xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
>Subject: RE: [Xen-ia64-devel] Uncached offset: Region 6 -> lower half
>ofVTi-reserved VM space
>> En... clean and safety may be possible win for separate
>> regions. Though careful design can avoid memory attribute
>> confusion in single region, it would bring some trouble for
>> debug if happen unluckily... :)
>> Ideally, Xen HV should have the ability to cover same size of
>> range seen by guest. After hiding 1 bit, guest has totally
>> 60bit virtual space. Though unlikely to see physical address
>> also expanding to 60bit soon, guest has the potentiality to
>> map 60bit physical space by 60bit virtual space in one
>> region. Then if we split Xen HV space to cover both cache and
>> uncache area, that means maximum area to be mapped with same
>> cache property can only be 59bit...
>> Yes, above issue doesn't exist on current hardware, but my
>> concern is just from point of not adding any limitation for
>> future possibilities. How do you think of this point? :)
>> Actually simply from code level, either way for uncached adds
>> almost same line of code.
>I guess I prefer having all Xen addresses contiguous and in
>region 7.  It will be decades before there are physical addresses
>with 59 or 60 bits.
>> One small question, why do we need check Xen space at the end
>> of alternate dtlb miss? Checking psr.cpl has already filtered
>> fault from guest space, hasn't it?
>This covers the case where Xen makes a "user" access that misses.

Attachment: patch_uncached_offset_vti
Description: patch_uncached_offset_vti

Xen-ia64-devel mailing list
<Prev in Thread] Current Thread [Next in Thread>
  • [Xen-ia64-devel] [Patch] Adapts to uncached offset change for VTI, Tian, Kevin <=