RE: [Xen-ia64-devel]Question about priv_ptc_e

["Xu, Anthony" <anthony.xu@xxxxxxxxx>]

>From: Magenheimer, Dan (HP Labs Fort Collins) 
>Sent: 2006年3月14日 23:16
>To: Xu, Anthony; Tristan Gingold
>Cc: xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
>Subject: RE: [Xen-ia64-devel]Question about priv_ptc_e
>
>> >There are several of these that need to be changed,
>> >so let's change all of them the same way at the same time.
>>
>> It is still being used.
>> At least, Dom0 uses pte.e to emulate fc.
>> GLOBAL_ENTRY(xen_fc)
>>     261     movl r8=running_on_xen;;
>>     262     ld4 r8=[r8];;
>>     263     cmp.eq p7,p0=r8,r0;;
>>     264 (p7)    fc r32;;
>>     265 (p7)    br.ret.sptk.many rp
>>     266     ;;
>>     267     ptc.e r96       // this is a "privified" fc r32
>>     268     ;;
>>     269     br.ret.sptk.many rp
>>     270 END(xen_fc)
>
>Good catch.  In fact, there are uses of this for several
>instructions still in xenlinux/ia64.  Grep -sparse
>for "privif" to see all(?) of them.  I think these never
>got translated to HYPERPRIVOPs because there was no
>performance need.  But they should be fixed to avoid
>the possibility of a bug.
>
>Yes, I had forgotten about that.  FC has a parameter
>so would require 128 different break immediate values
>to encode the full set of possible FC instructions.
>

If we use xen_fc style to emulate fc, we don't need to worry
about instruction parameters, we can use fixed register to pass
parameter, that means we can use one break immediate value
for one instruction. So seems we can use break to emulate these 
instructions like fc, thash and ttag. I prefer using break, which 
can gain performance, because VMM doesn't need to fetch opcode and
do decode work.

Thanks,
Anthony


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