[Xen-devel] Re: [GIT PULL] xen /proc/mtrr implementation

[Jeremy Fitzhardinge <jeremy@xxxxxxxx>]

Ingo Molnar wrote:
> Right now there's no MTRR support under Xen guests and the Xen 
> hypervisor was able to survive, right? Why should we do it under 
> dom0?
>   
Because dom0 has direct hardware access, and is running real device 
drivers.  domU guests don't see physical memory, and so MTRR has no 
relevance for them.
> The MTRR code is extremely fragile, we dont really need an added 
> layer there. _Especially_ since /proc/mtrr is an obsolete API.
>   
There's no added layer there.  I'm just adding another implementation of 
mtrr_ops.
/proc/mtrr is in wide use today.  It may be planned for obsolescence, 
but there's no way you can claim its obsolete today (my completely 
up-to-date F10 X server is using it, for example).  We don't break 
oldish usermode ABIs in new kernels.
Besides, the MTRR code is also a kernel-internal API, used by DRM and 
other drivers to configure the system MTRR state.  Those drivers will 
either perform badly or outright fail if they can't set the appropriate 
cachability properties.  That is not obsolete in any way.
> If you want to allow a guest to do MTRR ops, you can do it by 
> catching the native kernel accesses to the MTRR space. There's no 
> guest side support needed for that.
>   
MTRR can't be virtualized like that.  It can't be meaningfully 
multiplexed, and must be set in a uniform way on all physical CPUs.  
Guests run on virtual CPUs, and don't have any knowledge of what the 
mapping of VCPU to PCPU is, or even any visibility of all PCPUs.
It is not a piece of per-guest state; it is system-wide property, 
maintained by Xen.  These patches add the mechanism for dom0 (=hardware 
control domain) to tell Xen what state they should be in.
   J

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