TR virtualization vs. DCR

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

TR virtualization vs. DCR

Dong, Eddie

Dan and All:

     Currently both VTI and non-VTI are using machine TC to emulate guest TR, that is a must as machine memory a guest get may be discontiguous and may not be proper aligned. But this introduces another extra issues for guest ld.s.

     A guest ld.s to a TR mapped address will always be success, but in TC emulated TR, it may fail. Hypervisor is OK to handle that if it get control (i.e tlb miss), but in some situation, machine side may meet the exception deferral condition that cause the execution directly get returned with wrong value in target register (NAT is set). It is probably OK with C compiler generated code as there is chk.s to recover, but for an assembly wrote code with ld.s especially in guest kernel, we have problem.

     A right way to deal with that is to let machine side have much tighter deferral condition than guest side so that HV can get trapped always if it is needed and handle them. This introduces the DCR virtualization policy. Current non-VTI approach doesnt write any guest DCR information to machine side, we are just lucky now, while VTI approach is directly writing to machine DCR (dcr.pp is virtualized).
     In order to support this, DCR needs to be virtualized, to minimize this, only dcr.dm bit needs to be virtualized, i.e machine DCR.dm=0 while all other bits are same with guest (dcr.pp is another one need to be virtualized).

     Any comments?

Eddie

 


_______________________________________________
Xen-ia64-devel mailing list
[hidden email]
http://lists.xensource.com/xen-ia64-devel
Reply | Threaded
Open this post in threaded view
|

Re: TR virtualization vs. DCR

Tristan Gingold
Le Mercredi 12 Octobre 2005 10:35, Dong, Eddie a écrit :
> Dan and All:
>
>      Currently both VTI and non-VTI are using machine TC to emulate
> guest TR, that is a must as machine memory a guest get may be
> discontiguous and may not be proper aligned. But this introduces another
> extra issues for guest ld.s.
[...]
I am not aware of any other possibility [virtualize DCR].

Tristan.

PS: Are you trying to run Windows ?


_______________________________________________
Xen-ia64-devel mailing list
[hidden email]
http://lists.xensource.com/xen-ia64-devel
Reply | Threaded
Open this post in threaded view
|

RE: TR virtualization vs. DCR

Dan Magenheimer
In reply to this post by Dong, Eddie
> Le Mercredi 12 Octobre 2005 10:35, Dong, Eddie a écrit :
> > Dan and All:
> >
> >      Currently both VTI and non-VTI are using machine TC to emulate
> > guest TR, that is a must as machine memory a guest get may be
> > discontiguous and may not be proper aligned. But this
> introduces another
> > extra issues for guest ld.s.
> [...]
> I am not aware of any other possibility [virtualize DCR].

One of the options with a paravirtualized interface is to
disallow hardware architecural corner-cases that are rarely
used and very difficult/expensive to virtualize.  For
example, in this case, one possibility is to state that
an OS running on top of Xen must expect different behavior
for the ld.s instruction when loading from memory locations
pinned by a (virtual) TR.

I'm not saying this is the best answer for this problem,
but it is a possibility.

> PS: Are you trying to run Windows ?

I have the same question... the above (ld.s from a TR-pinned
location) doesn't occur in Linux does it?  Are you proposing
a fix to a hypothetical problem, or does some other potential
guest operating system make (frequent) use of this?

Thanks,
Dan

_______________________________________________
Xen-ia64-devel mailing list
[hidden email]
http://lists.xensource.com/xen-ia64-devel
Reply | Threaded
Open this post in threaded view
|

RE: TR virtualization vs. DCR

Dong, Eddie
In reply to this post by Dong, Eddie
Dan and Ttristan:
        Yes, assuming guest OS will not have such kind of corner behavior is one possibility for paravirtualization, but at least setting of guest DCR should go to machine DCR otherwise either result in bad performance (guest want deferral but machine not) or correctness issue (guest want no deferral but machine defers). Also disabling machine spotaneous deferral is a good way to avoid a lot of corner cases.
        We are revising the design holes before starting Windows up.  If we make sure the VMM is architecturally complete, then windows up should happen automatically.  That will be cool.
        Yes, sometime we are taking shortcut, but we need to be aware of the design holes at least among those key developers or document them.
Thx,eddie

Magenheimer, Dan (HP Labs Fort Collins) wrote:

>> Le Mercredi 12 Octobre 2005 10:35, Dong, Eddie a écrit :
>>> Dan and All:
>>>
>>>      Currently both VTI and non-VTI are using machine TC to emulate
>>> guest TR, that is a must as machine memory a guest get may be
>>> discontiguous and may not be proper aligned. But this introduces
>>> another extra issues for guest ld.s.
>> [...]
>> I am not aware of any other possibility [virtualize DCR].
>
> One of the options with a paravirtualized interface is to
> disallow hardware architecural corner-cases that are rarely
> used and very difficult/expensive to virtualize.  For
> example, in this case, one possibility is to state that
> an OS running on top of Xen must expect different behavior
> for the ld.s instruction when loading from memory locations
> pinned by a (virtual) TR.
>
> I'm not saying this is the best answer for this problem,
> but it is a possibility.
>
>> PS: Are you trying to run Windows ?
>
> I have the same question... the above (ld.s from a TR-pinned
> location) doesn't occur in Linux does it?  Are you proposing
> a fix to a hypothetical problem, or does some other potential
> guest operating system make (frequent) use of this?
>
> Thanks,
> Dan


_______________________________________________
Xen-ia64-devel mailing list
[hidden email]
http://lists.xensource.com/xen-ia64-devel