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


[Xen-ia64-devel] RE: a potential issue in set/get-rse-reg function

To: "Xu, Anthony" <anthony.xu@xxxxxxxxx>
Subject: [Xen-ia64-devel] RE: a potential issue in set/get-rse-reg function
From: "Magenheimer, Dan (HP Labs Fort Collins)" <dan.magenheimer@xxxxxx>
Date: Tue, 13 Sep 2005 06:05:07 -0700
Cc: xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Tue, 13 Sep 2005 13:03:40 +0000
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
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: AcW4QpVmi9T1OrvAQmOVqmucMzXuawAHdtgg
Thread-topic: a potential issue in set/get-rse-reg function
> In current implementation, Guest stack register of current 
> guest function can be saved in hypervisor backing store 
> or/and guest backing store, if some saved in guest backing 
> store, set/get-rse-reg will directly access guest backing 
> store, at this time, tlb miss may happen. But tlb miss 
> handler only search guest vhpt not guest page table, that 
> means it is possible hypervisor can't handle this tlb miss 
> and inject tlb miss to guest kernel, at this situation, I 
> think hypervisor can't inject tlb miss to guest kernel. 
> One explicit solution is in ivt.S set rse to lazy mode before 
> do 'cover' to make sure guest stack register of current guest 
> function are all saved in hypervisor backing store. Yes this 
> solution will penalize performance, but just a little, 
> because there are only about ten assembly instructions 
> between 'cover' and 'mov ar.rse=0' in current implementation.

What do you mean by "hypervisor can't inject tlb miss to
guest kernel?"  Is it because virtual psr.ic is off?  If so,
an OS should not be storing to location that might cause
a miss when psr.ic is off unless the location is pinned
by a TR.  Or is this a Linux bug too?  (I'm not looking
at the code right now... is the guest backing store
on the guest kernel stack (which is pinned by a virtual TR)
or the guest's user stack?)

> What's your opinion?

Well, since you asked my opinion...

I don't think we should be fixing theoretical architecture
bugs that don't occur on any released implementation, nor on
the next implementation that isn't even shipping yet (e.g. eager
mode).  I'd suggest adding a comment, or perhaps a check
and warning/error after the pal rse_info call that says
eager mode has not been tested.  Changing such a fundamental
and frequently executed part of the code may introduce
other latent difficult bugs, and we already have plenty of bugs
to track down that will break real users today.

But that's just my opinion ;-)

Xen-ia64-devel mailing list

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