Hi Eddie,
First of all, I don't touch a vTR at all.
And then, from the HW point of view, nothing is changed.
Because a vTLB is not located in VHPT area where the hardware
page walker can access. It's located only in collision chain area.
With this patch, [id]tlb miss hanlder must distinguish a vTLB from a
VHPT in collision chain area. That is an overhead.
Of course, respective hash/tag values might come into collision.
To distinguish it, ITIR{1}(reserved field) is used.
And that guarantees a vTLB never be inserted into a machine TC.
(a Reserved Register/Field fault is raised)
The following is an abstract of this patch:
Before:
==========================================================
struct thash_data_t vTLB[VTLB_SIZE];
struct thash_data_t *
search_vtlb(int addr) {
long hash = thash(addr);
struct thash_data_t *p;
p = &vTLB[hash];
do {
if (match(p, addr))
return *p;
p = p->next;
} while(p)
return NULL;
}
===========================================================
After:
===========================================================
struct thash_data_t *vTLB[VTLB_SIZE]; // *pointer*, common as VHPT
struct thash_data_t *
search_vtlb(int addr) {
long hash = thash(addr);
struct thash_data_t *p;
p = vTLB[hash]; // actually, p = VHPT[hash]->next;
while(p) {
if (match(p, addr) && is_vTLB(p)) // extra check is need
return *p;
p = p->next;
}
return NULL;
}
===========================================================
Thanks,
Kouya
Dong, Eddie writes:
> Kouya Shimura wrote:
> > Hi,
> >
> > Currently a HVM domain has vtlb and vhpt individually.
> > This patch unifies them. A vtlb entry is recorded in
> > vhpt collision chain area.
>
> Mmmm, I am not sure if it is correct in theory. If we put
> vTLB in VHPT, which means hash/tag can be used to
> uniquely identify a vTLB. This require (original design of) VHPT HW
> to rely on region size. If the region size changed, the whole
> VHPT need to be purged (at least for that region), other wise
> a VHPT entry could be interpreted as different translation.
>
> That means a region size change need to purge vTR in VHPT
> table. Do we still need additional data structure to keep those
> vTR?
>
> Also if regions size is for example 32K, and we have vTC1 & vTC2
> whose va is within 32K page (offset 0 & 16K), but size is only 16KB.
> Putting them in VHPT makes those 2 entries have same hash/tag
> since rid/vpn is same. Can this be handled?
>
> >
> > - improve flexibility. currently vtlb size is fixed but some
> > applications like ie32el consume much vtlb.
> > - utilize vhpt collision chain area. it looks sparse.
> > - reduce TLB miss for access to a vtlb entry. since vhpt is
> > mapped on a TR.
> > - speedup ptc.e emulation slightly.
> >
> > On the other hand, there would be a slight overhead in
> > searching a TLB entry.
> > In my testing, any performance degradation can't be seen.
> >
> Thanks, eddie
_______________________________________________
Xen-ia64-devel mailing list
Xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-ia64-devel
|
Home