Re: [Xen-devel] [PATCH 1/3] Add mcelog support for xen platform

["H. Peter Anvin" <hpa@xxxxxxxxx>]

My biggest beefs are page table manipulation, all the extra ugliness in kernel 
entry and exit, and lack of clear initialization semantics.  Additionally, any 
pvop which has unclear semantics - especially anything which is a nop on native 
and has zero documentation.

Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx> wrote:

>On Mon, Apr 23, 2012 at 09:17:28AM -0700, H. Peter Anvin wrote:
>> On 04/23/2012 08:27 AM, Luck, Tony wrote:
>> >> Because, if you'd hooked into it, just imagine one fine day, when
>we
>> >> remove mcelog support, what screaming the xen people will be doing
>when
>> >> mcelog doesn't work anymore.
>> > 
>> > Agreed. Even before we get to deleting mcelog, "struct mce" can
>change (new
>> > fields could be added) ... and you don't want to have your
>hypervisor to
>> > have to know which version of Linux it is talking to.
>> 
>> This is a great example on the fundamental problem with Xen, or
>rather
>> the approach that Xen has taken of grabbing random kernel internals
>and
>> claiming them as APIs (or, in some cases even as ABIs.)  A lot of
>these
>
>I am _not_ claiming that. If I left you with that impression from my
>responses - my fault for not getting my point across (the sleep
>deprevation
>is probably not helping either).
>
>I am _not_ stating that the usage of 'mce_log' or 'struct mce' MUST
>remain the same from now on. No. I am saying that the driver will be
>changed lock-step as Tony and Boris see fit in changing the functions.
>
>And currently the way the existing MCE drivers do this - is by using
>mce_log. This driver does is too - since the in-tree drivers do it this
>way.
>When they change to use a different mechanism - this driver will as
>well.
>
>> have had problems that are now very nearly unfixable, and that has
>> seriously stalled out the ability of evolve the Linux kernel in some
>> areas.  Note that the cost of this is borne by the development
>> community, not by the Xen maintainers.
>
>The ones I know that you are unhappy about are the MMU paravirt
>interfaces
>and I did mention to you that once some prototype work is done and
>it showed success, I will work on removing said support.
>
>Why don't you send me your unhappy list so that is on my radar as well
>please?
>
>> 
>>      -hpa
>> 
>> -- 
>> H. Peter Anvin, Intel Open Source Technology Center
>> I work for Intel.  I don't speak on their behalf.
>> 
>> 
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@xxxxxxxxxxxxx
>> http://lists.xen.org/xen-devel

-- 
Sent from my mobile phone. Please excuse brevity and lack of formatting.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel