RE: [Xen-ia64-devel] [PATCH] unify vtlb and vhpt

[Kouya Shimura <kouya@xxxxxxxxxxxxxx>]

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