WARNING - OLD ARCHIVES

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/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-ia64-devel

Re: [Xen-ia64-devel] RE: [PATCH]: disable handling of legacy privified i

To: "Magenheimer, Dan (HP Labs Fort Collins)" <dan.magenheimer@xxxxxx>
Subject: Re: [Xen-ia64-devel] RE: [PATCH]: disable handling of legacy privified insns
From: Tristan Gingold <Tristan.Gingold@xxxxxxxx>
Date: Tue, 21 Mar 2006 09:13:59 +0100
Cc: xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Tue, 21 Mar 2006 08:11:15 +0000
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <516F50407E01324991DD6D07B0531AD5A648AC@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: <516F50407E01324991DD6D07B0531AD5A648AC@xxxxxxxxxxxxxxxxxxxxxxxxxxxxx>
Sender: xen-ia64-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: KMail/1.5
Le Lundi 20 Mars 2006 17:08, Magenheimer, Dan (HP Labs Fort Collins) a écrit :
Hi,

[...]
> Is there a reason you are proposing to change the design
> of hyperprivops? 
No, I don't want to change the design, I am just trying to understand it 
fully.

> I realize that the few hyperprivops you
> just implemented are a bit ugly because it is necessary
> to save/restore virtual psr.ic and virtual psr.i, but
> these were never previously implemented as hyperprivops
> because they were relatively low frequency.  The virtual
> psr.ic trick works nicely for the high frequency ones.
Sure.

> Do you think the pl=2 approach will yield a significant
> performance advantage?  Or is there some other reason?
I don't see immediat performance advantage.

I was just thinking about privileged operations.
We all agree these are slow and have a bad impact on D cache.
Their handling also suppose that I=D, because the bundle is read using ld8.
We agree this is not a problem with para-virtualized linux; this is more or 
less a theorical issue.  But it makes vcpu_translate strange.

Now suppose we'd like to fix this issue.  We can either fetch the opcode using 
a manually translated mpa.  This would be slow.  Maybe we could make 
measures.  Or we can replace the pivop by a break on the fly.  To do this, we 
must be able to catch break insn and have enough room in the iim space.

This was just a thinking, I have written it down.

Tristan.



_______________________________________________
Xen-ia64-devel mailing list
Xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-ia64-devel

<Prev in Thread] Current Thread [Next in Thread>