Re: [GIT PULL] xen /proc/mtrr implementation

From: Jeremy Fitzhardinge
Date: Mon May 18 2009 - 00:57:57 EST


Eric W. Biederman wrote:
There are only 3 states that are interesting. WB UC and WC. Since
Xen controls the page tables anyway. I expect it can even remap
it feels like it.

It would be awkward. A paravirtualized guest has direct access to the real pagetables, and so would notice if Xen swizzled around the PAT bits when it reads back a pagetable entry. We don't currently have any paravirtualized hooks for adjusting the PTE flags, because there hasn't been any need, and it would probably be pretty costly (lots of read+bit-tests would turn into a function call). On the other hand, there's probably only a few places (if any) in the kernel which actually inspect the PAT status of an established PTE, so we could put in some special case mapping there. It becomes a maintenance burden to 1) track down all the right places, and then 2) make sure any new instances get handled properly. So, not a preferred solution, I think.

But our planned approach is to simply make Xen use the same PAT layout as Linux, and go from there. We still need to sort out the details of how to handle other Xen guests which use the existing Xen PAT setup, how to verify that Xen and the guest kernel are really using the same setup, etc.

But since we support the last few year's worth of released versions of Xen, we still need to handle the PAT-not-supported case with reasonable grace.

I won't argue that having MTRRs when you can makes sense. It is a bit
weird in a vitalized system.

It's not really virtualized. We're talking about dom0, which is the guest domain which has access to the real machine's real hardware; the MTRR is part of that.

At a practical level there are an
increasing number of systems for which MTRRs are unusable because the
BIOS sets up overlapping mtrrs. With cheap entry level systems
shipping with 4G I expect it is becoming a majority of systems.

Yes, but that is true irrespective of Xen.

J
--
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/