| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
RE: [Xen-devel] In VMCS, HOST_CR0.TS is always set 1. Why?
|
To: |
"Keir Fraser" <Keir.Fraser@xxxxxxxxxxxx>, <steven@xxxxxxxxxxxxx>, <xen-devel@xxxxxxxxxxxxxxxxxxx> |
|
Subject: |
RE: [Xen-devel] In VMCS, HOST_CR0.TS is always set 1. Why? |
|
From: |
"Cui, Dexuan" <dexuan.cui@xxxxxxxxx> |
|
Date: |
Wed, 14 Nov 2007 19:44:28 +0800 |
|
Cc: |
"Dong, Eddie" <eddie.dong@xxxxxxxxx> |
|
Delivery-date: |
Wed, 14 Nov 2007 03:46:49 -0800 |
|
Envelope-to: |
www-data@xxxxxxxxxxxxxxxxxx |
|
In-reply-to: |
<C3608943.186F6%Keir.Fraser@xxxxxxxxxxxx> |
|
List-help: |
<mailto:xen-devel-request@lists.xensource.com?subject=help> |
|
List-id: |
Xen developer discussion <xen-devel.lists.xensource.com> |
|
List-post: |
<mailto:xen-devel@lists.xensource.com> |
|
List-subscribe: |
<http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> |
|
List-unsubscribe: |
<http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> |
|
References: |
<FE7BBCFBB500984A9A7922EBC95F516E70F546@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> <C3608943.186F6%Keir.Fraser@xxxxxxxxxxxx> |
|
Sender: |
xen-devel-bounces@xxxxxxxxxxxxxxxxxxx |
|
Thread-index: |
AcgmqTOKyZ7EfwTJRzWoK6/R3m1zigABm3qbAAD3TqA= |
|
Thread-topic: |
[Xen-devel] In VMCS, HOST_CR0.TS is always set 1. Why? |
I see.
Thanks for the clear explanation!
-- Dexuan
Keir Fraser wrote:
> On 14/11/07 10:29, "Cui, Dexuan" <dexuan.cui@xxxxxxxxx> wrote:
>
>>> /* Host control registers. */
>>> - __vmwrite(HOST_CR0, read_cr0());
>>> + __vmwrite(HOST_CR0, read_cr0() | X86_CR0_TS);
>>> __vmwrite(HOST_CR4, read_cr4());
>>>
>>> /* Host CS:RIP. */
>>
>> Hi Steven,
>> The description of the changeset says "This fixes a number of subtle
>> FP corruption issues within PV domains when running alongside VMX
>> ones" -- can you tell me what the subtle issues are?
>
> At the time we construct the vmcs, the dom0 process may already have
> dirtied the fpu in this timeslice and hence CR0.TS is clear. If that
> is the case then every time this VMCS is vmexited we will load CR0
> with TS cleared. Not really a problem while that VMX guest is
> running, but if we context-switch to a PV guest, and the VMX guest
> has not dirtied the FPU, then our context-switch logic will assume
> that CR0.TS must be set and so not explicitly set it. So then the PV
> guest runs and will be able to access the FPU without having its
> state restored (because CR0.TS already == 0).
>
> -- Keir
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
| |
|
Home