lkml.org 
[lkml]   [2009]   [May]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [GIT PULL] xen /proc/mtrr implementation

* Jeremy Fitzhardinge <jeremy@goop.org> wrote:

> Ingo Molnar wrote:
>> Here Xen invades an already fragile piece of upstream code
>> (/proc/mtrr) that is obsolete and on the way out. If you want a
>> solution you should add PAT support to Xen and you should use recent
>> upstream kernels. Or you should emulate /proc/mtrr in _Xen the
>> hypervisor_, if you really care that much - without increasing the
>> amount of crap in Linux.
>>
>
> That's a gross mis-characterisation of what we're talking about here.
>
> arch/x86 already defines an mtrr_ops, which defines how to
> manipulate the MTRR registers. There are currently several
> implementations of that interface. In Xen the MTRR registers
> belong to the hypervisor, but it allows a privileged kernel to
> modify them via hypercalls. I simply added a new, straightforward
> mtrr_ops implementation to do that. It adds about 120 lines of
> new code, in a single mtrr/xen.c file.
>
> That's it. I could add any number of bizarre convolutions to
> achieve the same effect, but given that there's an existing
> interface that is exactly designed for what we want to achieve, I
> have to admit it didn't occur to me to do anything else.

Exactly what is 'bizarre' about using the API defined by the _CPU_
already, without adding any ad-hoc hypecall? Catch the dom0 WRMSRs,
filter out the MTRR indices - that's it.

Ingo


\
 
 \ /
  Last update: 2009-05-19 12:03    [W:1.415 / U:0.652 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site