| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
Re: [Xen-devel] In VMCS, HOST_CR0.TS is always set 1. Why?
|
To: |
"Cui, Dexuan" <dexuan.cui@xxxxxxxxx>, <steven@xxxxxxxxxxxxx>, <xen-devel@xxxxxxxxxxxxxxxxxxx> |
|
Subject: |
Re: [Xen-devel] In VMCS, HOST_CR0.TS is always set 1. Why? |
|
From: |
Keir Fraser <Keir.Fraser@xxxxxxxxxxxx> |
|
Date: |
Wed, 14 Nov 2007 11:15:15 +0000 |
|
Cc: |
"Dong, Eddie" <eddie.dong@xxxxxxxxx> |
|
Delivery-date: |
Wed, 14 Nov 2007 03:16:05 -0800 |
|
Envelope-to: |
www-data@xxxxxxxxxxxxxxxxxx |
|
In-reply-to: |
<FE7BBCFBB500984A9A7922EBC95F516E70F546@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> |
|
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> |
|
Sender: |
xen-devel-bounces@xxxxxxxxxxxxxxxxxxx |
|
Thread-index: |
AcgmqTOKyZ7EfwTJRzWoK6/R3m1zigABm3qb |
|
Thread-topic: |
[Xen-devel] In VMCS, HOST_CR0.TS is always set 1. Why? |
|
User-agent: |
Microsoft-Entourage/11.3.6.070618 |
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