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

["Tian, Kevin" <kevin.tian@xxxxxxxxx>]

Then serial port back to work again. Please apply.

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

Thanks,
Kevin

>-----Original Message-----
>From: Magenheimer, Dan (HP Labs Fort Collins)
>[mailto:dan.magenheimer@xxxxxx]
>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.
>
>Dan

Attachment: patch_uncached_offset_vti
Description: patch_uncached_offset_vti

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