[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


  • To: "Magenheimer, Dan \(HP Labs Fort Collins\)" <dan.magenheimer@xxxxxx>
  • From: "Xu, Anthony" <anthony.xu@xxxxxxxxx>
  • Date: Fri, 4 Nov 2005 15:10:26 +0800
  • Cc: xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
  • Delivery-date: Fri, 04 Nov 2005 07:10:35 +0000
  • List-id: Discussion of the ia64 port of Xen <xen-ia64-devel.lists.xensource.com>
  • Thread-index: AcXf7/qlxt/UBLYXQj6idPbhpb4eQQAKxkpQAAOxG7AACK2+8AANzkbgABfse2A=
  • Thread-topic: 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
>>

Attachment: ar_unat2.patch
Description: ar_unat2.patch

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

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.