[Xen-ia64-devel] RE: A patch to remove dcr.63 for running_on_xen indicator

["Dong, Eddie" <eddie.dong@xxxxxxxxx>]

Dan:
        Is not xenlinux-ia64 accessing fixed address for shared memory
like following code from xenlinux-ia64?   This patch just use same
assumption.
        If xenlinux support dynamic configurable share memory address,
this patch can simply be updated too.
        
        The reason to push this patch is that bit 63 of DCR may be not
reserved in future just like PSR.vm bit in VT-i spec. Probing shared
memory is just much safe.
eddie

GLOBAL_ENTRY(xen_get_ivr)
        movl r8=running_on_xen;;
        ld4 r8=[r8];;
        cmp.eq p7,p0=r8,r0;;
(p7)    mov r8=cr.ivr;;
(p7)    br.ret.sptk.many rp
        ;;
        movl r9=XSI_PSR_IC
        ;;
        ld8 r10=[r9]
        ;;
        st8 [r9]=r0
        ;;
        XEN_HYPER_GET_IVR
        ;;
        st8 [r9]=r10
        br.ret.sptk.many rp
        ;;
END(xen_get_ivr)

Magenheimer, Dan (HP Labs Fort Collins) wrote:
> I dug back through my email to find this as I remembered
> having a concern when I first glanced at it...
> 
> Although it is not implemented now for Xen/ia64,
> vBlades allowed the guest to choose the (virtual)
> location of the shared page.   This can be useful
> as some guest OS's may already use the virtual
> addresses currently "reserved" for the shared page
> in the current Xen/ia64 implementation.  Also,
> one can conceive of reasons why different guests
> might have different shared pages (e.g. to allow
> domain0 and domU's to be coresident in virtual
> address space).
> 
> So, I don't think a guest should probe a fixed
> virtual address as the mechanism to determine if
> it is running_on_xen.
> 
>> -----Original Message-----
>> From: Dong, Eddie [mailto:eddie.dong@xxxxxxxxx]
>> Sent: Monday, August 15, 2005 10:21 PM
>> To: Magenheimer, Dan (HP Labs Fort Collins)
>> Cc: xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
>> Subject: A patch to remove dcr.63 for running_on_xen indicator
>> 
>> Dan:
>>      The attached patch is target to remove dcr.63 bit usage to
>> indicate running_on_xen or not, thus avoid future IPF spec violation
>> (reserve bits should be 0 base on spec).
>>      Please comments.
>>      BTW, currnet XENLinux tree (yesterday) can't run on native
>> environment for some reason. So I only test that on XEN environment.
>> Eddie 
>> 
>> 
>> 
>> diff -r 84356b86adf0 arch/ia64/xen/xensetup.S
>> --- a/arch/ia64/xen/xensetup.S       Fri Aug 12 21:15:45 2005
>> +++ b/arch/ia64/xen/xensetup.S       Mon Aug 15 18:44:21 2005 @@
-16,12
>> +16,17 @@ 
>> 
>>      .text
>>  GLOBAL_ENTRY(early_xen_setup)
>> -    mov r8=cr.dcr;;
>> -    extr.u r8=r8,63,1
>> +    rsm psr.ic
>> +    movl r9=XSI_BASE;;
>> +    ld8.s r8=[r9];;
>> +    tnat.nz.unc p6,p7=r8    // p6=1: No share memory
>> +(p6)        mov r8=0
>> +(p7)        mov r8=1                // on XEN
>>      movl r9=running_on_xen;;
>>      st4 [r9]=r8;;
>> -    cmp.ne p7,p0=r8,r0;;
>>  (p7)        movl r10=xen_ivt;;
>>  (p7)        mov cr.iva=r10
>> +    ssm psr.ic
>> +    srlz.d
>>      br.ret.sptk.many rp;;
>>  END(xen_init)


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