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

From: Gerd Hoffmann
Date: Tue May 19 2009 - 09:23:19 EST


On 05/19/09 14:26, Ingo Molnar wrote:
* Gerd Hoffmann<kraxel@xxxxxxxxxx> wrote:

On 05/19/09 13:08, Ingo Molnar wrote:
Or, alternatively, the hypervisor can expose its own administrative
interface to manage MTRRs.
Guess what? Xen does exactly that. And the xen mtrr_ops
implementation uses that interface ...

No, that is not an 'administrative interface' - that is a guest
kernel level hack that complicates Linux, extends its effective ABI
dependencies and which has to be maintained there from that point
on.

There's really just three proper technical solutions here:

- either catch the lowlevel CPU hw ops (the MSR modifications, which
isnt really all that different from the mtrr_ops approach so it
shouldnt pose undue difficulties to the Xen hypervisor).

Devil is in the details.

The dom0 kernel might not see all physical cpus on the system. So Xen can't leave the job of looping over all cpus to the dom0 kernel, Xen has to apply the changes made by the (priviledged) guest kernel on any (virtual) cpu to all (physical) cpus in the machine.

Which in turn means the "lowlevel cpu hw op" would work in a slightly different way on Xen and native. Nasty.

That will
be maximally transparent and compatible, with zero changes needed
to the Linux kernel.

No, the linux kernel probably should do the wrmsr on one cpu only then.

- or introduce its own hypercall API based administration API,
without bothering the guest kernel with crap. Trivially patch Xorg
to make use of it and that's it.

I have serious doubts that this is going to fly with KMS.

Oops, the third "proper technical solutions" is missing.

cheers,
Gerd

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/