[lkml]   [2009]   [May]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [GIT PULL] xen /proc/mtrr implementation
    Jeremy Fitzhardinge <> writes:

    > 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.

    Sure it is. There is a better newer replacement. It is taking a while to
    get userspace transitioned but that is different. Honestly I am puzzled
    why that it but whatever.

    > 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.

    There are about 5 of them so let's fix them.
    With PAT we are in a much better position both for portability and for

    >> 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.

    Is it possible to fix PAT and get that working first. That is very definitely
    the preferend API.


     \ /
      Last update: 2009-05-16 01:29    [W:0.027 / U:4.272 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site