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

["Magenheimer, Dan (HP Labs Fort Collins)" <dan.magenheimer@xxxxxx>]

> 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

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