RE: [Xen-ia64-devel] PATCH: rewrite vcpu_get_psr

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

>From: tgingold@xxxxxxx [mailto:tgingold@xxxxxxx]
>Sent: 2007å5æ11æ 16:18
>To: Xu, Anthony
>Cc: Xen-ia64-devel
>Subject: RE: [Xen-ia64-devel] PATCH: rewrite vcpu_get_psr
>
>Quoting "Xu, Anthony" <anthony.xu@xxxxxxxxx>:
>
>> >Tristan Gingold
>> >Sent: 2007ÃÃ5ÃÃ11ÃÃ 13:23
>> >To: Alex Williamson
>> >Cc: Xen-ia64-devel
>> >Subject: Re: [Xen-ia64-devel] PATCH: rewrite vcpu_get_psr
>> >
>> >> Unfortunately...
>> >It's a little bit puzzling.  I didn't think the performace of mov =psr.l was
>> >to important!
>>
>>
>>
>> +
>> +    if (!PSCB(vcpu, metaphysical_mode))
>> +            newpsr.i64 |= IA64_PSR_DT | IA64_PSR_RT | IA64_PSR_IT;
>>
>> -    if (PSCB(vcpu, metaphysical_mode))
>> -            newpsr.dt = 0;
>>
>> Above old code would be translated to
>>      if (PSCB(vcpu, metaphysical_mode))
>>              newpsr.i64 &= ~IA64_PSR_DT;
>I seriously think the old code was wrong (more precisely incorrect).
>
>I have to re-read Dan's paper and linux code, but in PV mode we only correctly
>support IT=DT=RT.
>
>(the same should be true for VTi BTW and incidently we can
>easily write OS which cannot be virtualized by VTi!)

Machine psr dt it rt are always 1.
While this code segment is used to emulate guest execution of "mov from psr"
From the view of guest OS, vpsr dt it rt can be any value.

In xenodomaim,
There are only two situations.
Virtual mode;  vpsr.it=dt=rt=1.
Physical mode: vpsr.dt=0, vpsr.it=vpsr.rt=1, which happens in linux OS tlb fault
related handlers.

In vti-domain.
We support more situations except for above two.

Vpsr.it=dt=rt=0, this happens when guest calls PAL call, which can be called 
only
in physical mode.

Vpsr.it=rt=0, vpsr.dt=1, this happens at the very beginning of windows boot.



-Anthony



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