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

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

>-----Original Message-----
>From: Magenheimer, Dan (HP Labs Fort Collins)
>Sent: Tuesday, June 14, 2005 10:41 PM
>>
>> 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


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.

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?

Thanks,
Kevin

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