| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
[Xen-devel] Re: [GIT PULL] xen /proc/mtrr implementation
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
|
|
|
| |
|
Home