[Xen-ia64-devel] RE: ar.unat[patch] fixed this ar.uant issue.[patch] fixed ar.unat save/restore issue

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

> I have not seen nat consumptions and segmentations faults for 
> a long time, in your build test and ltp test. Otherwise, I'll 
> definitely try to fix that.

After applying your NaT fix to the fast_reflect path, I
have not yet seen the problem again.  So I suspect that
your fix on the fast_rfi path plus your fast_reflect patch
fixed the problem.
 
> >It doesn't look right to me.  There are two issues:
> >
> >1) Your patch added a "return"... I think this means that
> >   NaT faults will never get reflected to a guest (even
> >   Register NaT Consumption faults).
> 
> Yes, you are right, we should inject Nat Consumption faults 
> to guest, but as I know there should be not NaT consumption 
> faults in linux, so I simply added a "return". I think the 
> best way is to add "panic" at this place, this will enforce 
> us to debug this issue rather than temporarily work around.

Hmmm...  I recall that a NaT page was once used in Linux to catch
null pointer derefernces.  I don't know if one still is used
for that.  Anyone else know?

Also, isn't it possible for a Register NaT Consumption fault
to occur if hand-coded assembly uses speculation?

> I have been being curious why use emulate function to handle 
> NaT consumption.
> Now I understand, thank you for your detailed explain. Maybe 
> we need to put more comments in the confusing place like this.

Agreed.  I will try to put a comment in next time I touch
that code.

> >You know more about NaT's than I do... could you recheck
> >this code in ia64_handle_reflection please?  Do you have
> >any test code that provokes any of these NaT faults?
> 
> It' is very kind of you to say that, unfortunately I have not 
> seen those issues. What I suspect is dom0 does bank switch on 
> shared page but not consider ar.unat.
> 
> Anyway, I'll try to provoke this fault, If I find, I'll 
> definitely fix it.

OK, I will let you know if I see it again too.

Dan

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