See my comments,
>-----Original Message-----
>From: Magenheimer, Dan (HP Labs Fort Collins) [mailto:dan.magenheimer@xxxxxx]
>Sent: 2005年11月8日 2:07
>To: Xu, Anthony
>Cc: xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
>Subject: RE: ar.unat[patch] fixed this ar.uant issue.[patch] fixed ar.unat
>save/restore issue
>
>Another NaT question...
>
>>I recall that some time ago (around the time of the merge)
>>you submitted some patches related to fixing ar.unat saving
>>and restoring.
>
>Another part of your earlier patch was a change in
>ia64_handle_reflection. I still periodically get the
>message:
>
> NaT fault... attempting to handle as privop
>
>Since your latest fix, Tony's regcheck tool no longer
>reports ar.unat as being saved/restored incorrectly.
>I was hoping that the above message would go away also,
>but it has not. I see it a couple times at boot and
>a couple times for every linux compile (at the end so
>it is probably the linker or some other link-related
>tool). I have also seen programs segfault after printing
>this message. So I went to look at the Xen/ia64 code where
>this is printed.
>
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.
>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.
>2) Since a Instruction NaTPage Consumption fault has higher
> priority than a Privileged Operation fault, I think the
> original printf/priv_emulate code was intended to catch
> this case and properly emulate a privileged instruction
> on a NaTPage. I think it may also be necessary if a Data
> NaTPage Consumption fault is incurred when the privop
> emulation code fetches the instruction. (The code in
> ia64_handle_reflection should probably check the ISR to
> avoid calling priv_emulate for other kinds of NaT
> Consumption though.)
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.
>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.
>Thanks.
>Dan
>
>> -----Original Message-----
>> From: Xu, Anthony [mailto:anthony.xu@xxxxxxxxx]
>> Sent: Friday, November 04, 2005 12:10 AM
>> To: Magenheimer, Dan (HP Labs Fort Collins)
>> Cc: xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
>> Subject: RE: ar.unat[patch] fixed this ar.uant issue.[patch]
>> fixed ar.unat save/restore issue
>>
>> >I am curious about the use of B1NATS in the code
>> >around this patch. Under what circumstances does
>> >this get set/used?
>>
>> 1. emulate bsw1, bsw0
>> 2. emulate rfi.
>> 3. inject fault to guest.
>>
>> There is similar unat code in
>> >fast_tick (default off) and fast_reflect (default on)
>> >and I am wondering if similar unat changes are needed
>> >and whether it is now OK to turn on HANDLE_AR_UNAT
>> >(which is now default off).
>> You are right, in above two cases you should also save
>> ar.unat to XSI_B1NATS_OFS after spilling the guest bank1to
>> share page. I had handled all this in C code. I didn't look
>> into fast hypercall code, It's hard to read due to I am not
>> good at assembly code. The principle of handling ar.unat is
>> obvious; every time you spill banking register you must save
>> corresponding ar.unat after it, every time you fill banking
>> register you must restore corresponding ar.unat before it.
>>
>> We don't need to clear all guest b0 registers and their's nat
>> bit. Because r16~r23 are preserved regs and r24~r31 are
>> scratch regs, we only need to restore r16~r23 rather than
>> clear r16~r23 to 0.
>>
>> Next time you enable some functions like hyper_ssm_i, when
>> you save bank1 regs you should also save bank1 unat.
>>
>> Below patch enables HANDLE_AR_UNAT.
>>
>>
>>
>> Signed-off-by Anthony Xu <Anthony.xu@xxxxxxxxx>
>>
>> Thanks,
>> Anthony.
>>
>>
>>
>>
>> >-----Original Message-----
>> >From: Magenheimer, Dan (HP Labs Fort Collins)
>> [mailto:dan.magenheimer@xxxxxx]
>> >Sent: 2005年11月3日 22:42
>> >To: Xu, Anthony
>> >Cc: xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
>> >Subject: RE: ar.unat[patch] fixed this ar.uant issue.
>> >
>> >Hi Anthony --
>> >
>> >I am curious about the use of B1NATS in the code
>> >around this patch. Under what circumstances does
>> >this get set/used? There is similar unat code in
>> >fast_tick (default off) and fast_reflect (default on)
>> >and I am wondering if similar unat changes are needed
>> >and whether it is now OK to turn on HANDLE_AR_UNAT
>> >(which is now default off).
>> >
>> >Thanks,
>> >Dan
>> >
>> >> -----Original Message-----
>> >> From: Xu, Anthony [mailto:anthony.xu@xxxxxxxxx]
>> >> Sent: Thursday, November 03, 2005 1:08 AM
>> >> To: Magenheimer, Dan (HP Labs Fort Collins)
>> >> Cc: xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
>> >> Subject: RE: ar.unat[patch] fixed this ar.uant issue.
>> >>
>> >> Dan,
>> >> Last time, I used ar.unat register to restore guest general
>> >> register nat bit in hyper_rfi function for eliminating nat
>> >> bit consumption fault,but not restored ar.unat.
>> >>
>> >> Signed-off-by Anthony Xu <Anthony.xu@xxxxxxxxx>
>> >>
>> >> Thanks,
>> >> Anthony.
>> >>
>> >>
>> >>
>> >>
>> >> >-----Original Message-----
>> >> >From: Magenheimer, Dan (HP Labs Fort Collins)
>> >> [mailto:dan.magenheimer@xxxxxx]
>> >> >Sent: 2005年11月3日 11:54
>> >> >To: Xu, Anthony
>> >> >Cc: xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
>> >> >Subject: RE: ar.unat
>> >> >
>> >> >> I can take a look at this, please send me regcheck utilty.
>> >> >>
>> >> >>
>> >> >> Thanks
>> >> >> Anthony
>> >> >
>> >> >Great, thanks! Here's where I got Tony's regcheck tool. If
>> >> >it's not still there, perhaps Tony can post it.
>> >> >
>> >> >By the way, if anyone tries this on a domU, Matt Chapman
>> >> >has a pending fix that resolves a FP save/restore issue.
>> >> >
>> >> >Thanks,
>> >> >Dan
>> >> >
>> >> >> -----Original Message-----
>> >> >> From: linux-ia64-owner@xxxxxxxxxxxxxxx
>> >> >> [mailto:linux-ia64-owner@xxxxxxxxxxxxxxx] On Behalf Of
>> Luck, Tony
>> >> >> Sent: Tuesday, March 01, 2005 4:33 PM
>> >> >> To: linux-ia64@xxxxxxxxxxxxxxx
>> >> >> Subject: RE: [patch 2.6.11-rc3-bk4] Correctly dereference
>> >> >> ia64_mca_data
>> >> >>
>> >> >> Back on February 9th, I wrote:
>> >> >> >I wrote a test program that loads up random values
>> into registers
>> >> >> >(just r1-r31, a bunch of stacked registers, and
>> f2-f127 for now)
>> >> >> >and then checks that all the registers haven't changed value a
>> >> >> >few thousand times, before reloading with a new set of random
>> >> >> >values.
>> >> >>
>> >> >> A few people asked whether I could post the program ... it took
>> >> >> a while to get sign-off ... but that gave me time to
>> add "branch",
>> >> >> "predicate" and half a dozen "application" registers to the mix,
>> >> >> plus make it print the name of the register that was
>> nuked (instead
>> >> >> of a number that required manual translation).
>> >> >>
>> >> >> I've tested it by using a debugger to zap one of each class
>> >> >> of register
>> >> >> that is being monitored to check that it works.
>> >> >>
>> >> >>
>> http://www.kernel.org/pub/linux/kernel/people/aegl/ia64regcheck.tgz
>> >> >>
>> >> >> Usage ... compile, and run a few copies. If they all
>> >> "exit(0)" (which
>> >> >> may take a couple of days) the test passed. Otherwise you
>> >> should see
>> >> >> the name of the register printed to stderr, and exit code 1.
>> >> >>
>> >> >> Apart from the MCA case, I haven't seen it report a problem
>> >> >> yet ... but
>> >> >> I've only run a few hours.
>> >> >>
>> >> >> -Tony
>> >>
>>
_______________________________________________
Xen-ia64-devel mailing list
Xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-ia64-devel
|
Home