| |
|
 |
|
 |
|
|
|
| |
|
|
xen-ia64-devel
Re: [Xen-ia64-devel] One unstablity in fast syscall path
Le Mercredi 14 Juin 2006 19:38, Magenheimer, Dan (HP Labs Fort Collins) a
écrit :
> > > I have a question on priv_handle_op().
> > > I changed the function so that xen/ia64 reflects itlb miss
> >
> > to a domain
> >
> > > when xen/ia64 fails to read a bundle.
> > > Xen/ia64 reflected dtlb miss before my change.
> > >
> > > Is it correct to reflect dtlb miss?
>
> No this was just a hack that worked. It does need
> to be fixed. This was the intent of the one-entry
> itlb but it never got fully implemented.
On the other side, merging I & D seems to be very effecient for reading
bundles. Perhaps we need performance figures.
> > > I guess you already encountered the same problem
> > > and gave the consideration on it.
> >
> > Just a small comment here:
> > before your patch itlb was useless: it was never read.
> > This works because Linux assume I space == D space. But this
> > may be wrong for
> > other OS.
>
> Very true.
>
> > It was of course wrong to read the bundle directly in the D
> > space, but for
> > sure it was faster than doing manually the translation.
>
> Is it possible to do the translation in Xen without either
> requesting information from the guest (deliver a TLB miss)
> or hope that the information is cached?
>
> > On this point VTi may have a real advantage over paravirtualization.
>
> Could you explain further?
Yes.
The virtualization handler has the opcode in GR25.
I don't know the amount of PAL code involved, but the hardware might provides
the opcode directly from the pipeline. The VM doesn't have to do the fecth,
which is time and cache consuming.
Tristan.
_______________________________________________
Xen-ia64-devel mailing list
Xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-ia64-devel
|
|
|
| |
|
Home