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: Mon, 19 Jun 2006 15:51:21 +0200
Cc: xen-ia64-devel <xen-ia64-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Mon, 19 Jun 2006 06:47:06 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <516F50407E01324991DD6D07B0531AD5BC5F38@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: <516F50407E01324991DD6D07B0531AD5BC5F38@xxxxxxxxxxxxxxxxxxxxxxxxxxxxx>
Sender: xen-ia64-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: KMail/1.5
Le Lundi 19 Juin 2006 15:35, Magenheimer, Dan (HP Labs Fort Collins) a écrit :
> > > > 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.
> No the hardware does not provide the opcode directly, though
> perhaps it will in future (post-Montecito) implementations.
> I believe that PAL is doing the same thing that Xen is
> doing to fetch the opcode, except since it is doing it
> sooner, there is a higher probability that it will be
> successful.  And I suspect that it may be doing the
> "slow path" every time as it is probably not capable
> of handling (and recovering from) TLB misses.  I'm not
> sure I would call this an advantage.
I suspected this behavior too.  So, this is only a *potential* advantage ;-)

> Perhaps Intel can comment more here... I'm not sure what
> info is public.
Yes, I suppose this info is not public...


Xen-ia64-devel mailing list