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: "Tristan Gingold" <Tristan.Gingold@xxxxxxxx>, "Isaku Yamahata" <yamahata@xxxxxxxxxxxxx>
Subject: RE: [Xen-ia64-devel] One unstablity in fast syscall path
From: "Magenheimer, Dan (HP Labs Fort Collins)" <dan.magenheimer@xxxxxx>
Date: Wed, 14 Jun 2006 10:38:38 -0700
Cc: xen-ia64-devel <xen-ia64-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Wed, 14 Jun 2006 10:39:09 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <200606141020.26188.Tristan.Gingold@xxxxxxxx>
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>
Sender: xen-ia64-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AcaPjT7dmz6j3cSzSheNHBDc4K2LdQAS5gBg
Thread-topic: [Xen-ia64-devel] One unstablity in fast syscall path
> > 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.

> > 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?


Xen-ia64-devel mailing list