This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


Re: [Xen-ia64-devel] One unstablity in fast syscall path

To: "Magenheimer, Dan (HP Labs Fort Collins)" <dan.magenheimer@xxxxxx>, "Isaku Yamahata" <yamahata@xxxxxxxxxxxxx>
Subject: Re: [Xen-ia64-devel] One unstablity in fast syscall path
From: Tristan Gingold <Tristan.Gingold@xxxxxxxx>
Date: Thu, 15 Jun 2006 09:46:52 +0200
Cc: xen-ia64-devel <xen-ia64-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Thu, 15 Jun 2006 00:42:39 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <516F50407E01324991DD6D07B0531AD5BC59F3@xxxxxxxxxxxxxxxxxxxxxxxxxxxxx>
List-help: <mailto:xen-ia64-devel-request@lists.xensource.com?subject=help>
List-id: Discussion of the ia64 port of Xen <xen-ia64-devel.lists.xensource.com>
List-post: <mailto:xen-ia64-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-ia64-devel>, <mailto:xen-ia64-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-ia64-devel>, <mailto:xen-ia64-devel-request@lists.xensource.com?subject=unsubscribe>
References: <516F50407E01324991DD6D07B0531AD5BC59F3@xxxxxxxxxxxxxxxxxxxxxxxxxxxxx>
Sender: xen-ia64-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: KMail/1.5
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?
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.


Xen-ia64-devel mailing list