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

["Magenheimer, Dan (HP Labs Fort Collins)" <dan.magenheimer@xxxxxx>]

> 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
Xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-ia64-devel