Mailing List Archive

Writes to cr0 already are emulated -- the TS bit is virtualised and all
other modified bits are ignored. We could also emulate (ignore) writes
to cr4, if that avoids xen-specific changes in the guest. The change to
do this is utterly trivial. Reads of cr4 are already emulated.

-- Keir

On 23 Dec 2005, at 11:09, Jan Beulich wrote:

> While merging i386's system.h I intended to remove those operations
> that
> the hypervisor doesn't support, namely writing to cr0 or cr4. However,
> even code in xen-specific files makes use of them, so far I found
>
> - write_cr0 in no_387() in include/asm-i386/bugs.h
> - write_cr4 in disable_tsc() in arch/i386/kernel/process-xen.c
> - write_cr0 in set_cx86_memwb() in arch/i386/kernel/cpu/cyrix.c
>
> I'll therefore have to (temporarily) re-add these functions, but will
> make them BUG() instead of attempting the writes, with the expectation
> that the offending uses get fixed in some way. Otherwise, proper
> support
> will need to be added to the hypervisor.
>
> Jan
>
> _______________________________________________
> Xen-merge mailing list
> Xen-merge@lists.xensource.com
> http://lists.xensource.com/xen-merge


_______________________________________________
Xen-merge mailing list
Xen-merge@lists.xensource.com
http://lists.xensource.com/xen-merge

>>> Keir Fraser <Keir.Fraser@cl.cam.ac.uk> 23.12.05 12:39:45 >>>
>Writes to cr0 already are emulated -- the TS bit is virtualised and
all
>other modified bits are ignored. We could also emulate (ignore) writes

>to cr4, if that avoids xen-specific changes in the guest. The change
to
>do this is utterly trivial. Reads of cr4 are already emulated.

Yes, I saw this. However, I wouldn't name this emulation. If, as in the
examples given, the writes are for a purpose where throwing away the
data isn't appropriate, I'd rather see this reported than silently
ignored. At least the TSC-disabling case is clearly a security issue.

Jan

_______________________________________________
Xen-merge mailing list
Xen-merge@lists.xensource.com
http://lists.xensource.com/xen-merge

Best,

On Fri, Dec 23, 2005 at 11:39:45AM +0000, Keir Fraser wrote:
> Writes to cr0 already are emulated -- the TS bit is virtualised and all
> other modified bits are ignored. We could also emulate (ignore) writes
> to cr4, if that avoids xen-specific changes in the guest. The change to
> do this is utterly trivial. Reads of cr4 are already emulated.

Hmm, the nVidia folks use CR4 to enable PAT ...
Is this something we want to support in dom0 ?

On the long term, I hope we'll have PAT replace MTRR in dom0
even without nVidia ...

Best,
--
Kurt Garloff, Head Architect, Director SUSE Labs (act.), Novell Inc.

On 27 Dec 2005, at 18:48, Kurt Garloff wrote:

> On Fri, Dec 23, 2005 at 11:39:45AM +0000, Keir Fraser wrote:
>> Writes to cr0 already are emulated -- the TS bit is virtualised and
>> all
>> other modified bits are ignored. We could also emulate (ignore) writes
>> to cr4, if that avoids xen-specific changes in the guest. The change
>> to
>> do this is utterly trivial. Reads of cr4 are already emulated.
>
> Hmm, the nVidia folks use CR4 to enable PAT ...
> Is this something we want to support in dom0 ?

PAT is always enabled, on processors that support it. There's no enable
flag in CR4. The PAT MSRs have to be rewritten to provide a type code
for write-combining, however, and we'll need to virtualize and/or
pass-through those writes for domain0 (or other suitably privileged
domain) in future.

> On the long term, I hope we'll have PAT replace MTRR in dom0
> even without nVidia ...

'Enabling use of PAT' isn't that hard -- usually that just means
provide a mapping for write-combining memory type. If we allow PAT
codes to be used by other than domain0, however, then we'll want to be
sure we don't allow aliased types (e.g., a page that is mapped both
cacheable and write-combining, in two different places). That kind of
thing can lead to system lockups.

-- Keir


_______________________________________________
Xen-merge mailing list
Xen-merge@lists.xensource.com
http://lists.xensource.com/xen-merge