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
6 messages in com.xensource.lists.xen-ia64-develRE: [Xen-ia64-devel] Uncached offset:...
.Other