[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>]

Thanks very much for looking at this.  From your explanation,
I understand it a little better now.

> 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.

Architecturally, bank0.r16-r23 are preserved but since Linux
doesn't make use of this (nor did HP-UX last time I asked,
though they were considering it... does Windows?), the
paravirtualization interface didn't guarantee this.  Your
solution (preserving them) is the better long-term solution.

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