|
xen-devel
[Xen-devel] Re: [GIT PULL] xen /proc/mtrr implementation
Jeremy Fitzhardinge <jeremy@xxxxxxxx> 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
flexibility.
>> 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.
Eric
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
Home