Re: Patches for stable

[George Dunlap <dunlapg@umich.edu>]

On Fri, Apr 6, 2018 at 9:00 AM, Juergen Gross <jgross@suse.com> wrote:
> On 05/04/18 20:33, Boris Ostrovsky wrote:
>> On 04/05/2018 01:11 PM, Juergen Gross wrote:
>>> On 05/04/18 16:56, George Dunlap wrote:
>>>> On Thu, Apr 5, 2018 at 3:09 PM, Juergen Gross <jgross@suse.com> wrote:
>>>>> On 05/04/18 15:42, George Dunlap wrote:
>>>>>> On Thu, Apr 5, 2018 at 2:06 PM, Juergen Gross <jgross@suse.com> wrote:
>>>>>>> On 05/04/18 15:00, Boris Ostrovsky wrote:
>>>>>>>> On 04/05/2018 08:19 AM, Juergen Gross wrote:
>>>>>>>>> On 05/04/18 12:06, George Dunlap wrote:
>>>>>>>>>
>>>>>>>>>> Aren't there flags in the binary somewhere that could tell the
>>>>>>>>>> toolstack / Xen whether the kernel in question needs the RSDP table in
>>>>>>>>>> lowmem, or whether it can be put higher?
>>>>>>>>> Not really. Analyzing the binary whether it accesses the rsdp_addr in
>>>>>>>>> the start_info isn't the way to go, IMO.
>>>>>>>>>
>>>>>>>>> I've sent a patch to xen-devel adding a quirk flag to the domain's
>>>>>>>>> config to enable the admin special casing such an "old" kernel.
>>>>>>>> Can we backport latest struct hvm_start_info changes (which bumped
>>>>>>>> interface version) to 4.11 and pass RSDP only for versions >=1?
>>>>>>> And this would help how?
>>>>>>>
>>>>>>> RSDP address is passed today, the kernel just doesn't read it. And
>>>>>>> how should Xen know which interface version the kernel is supporting?
>>>>>>> And Xen needs to know that in advance in order to place the RSDP in
>>>>>>> low memory in case the kernel isn't reading the RSDP address from
>>>>>>> start_info.
>>>>>> But the kernel image has ELF notes, right?  You can put one that
>>>>>> indicates that this binary *does* know how to read the RSDP from the
>>>>>> start_info, and if you don't find that, put it in lowmem.
>>>>> Sow you would hurt BSD which does read the RSDP address correctly but
>>>>> (today) has no such ELF note.
>>
>>
>> This can be predicated on
>>     ELFNOTE(Xen, XEN_ELFNOTE_GUEST_OS,       .asciz "linux")
>>
>> BSD will behave as it does now. For linux we could add feature flag (or
>> errata flag). Unfortunately I don't see a way to extract major.minor
>> from the headers, otherwise we could use that.
>
> What's wrong with the config flag?

How do you know the config flag exists?  If you miss it in the release
notes, you just upgrade and have all your guests suddenly stop
booting.  You google around for an hour and discover that the shiny
new feature that the XenProject told you to use was purposely,
knowingly broken, and that now you need to set this flag in each of
your guest configs.  Then you have the question of when you can remove
the config flag.  Suppose someone is running Linux 4.15, then upgrades
to Linux 4.17, then wants to downgrade back to 4.15?

Even if this only takes half an hour of each administrator's time to
have to deal with for the next 2-3 years (which I think would be
optimistic), think of the total number of man-hours wasted and the
frustration and negative feelings generated having to deal with it.

*Lots* of people in the Linux community have Greg's attitude towards
breaking existing systems.  Even if he never said another word, a
large number of other people would feel the same way, and probably a
number would say so.  Heck, there'd be a chance that the Register
would pick up the story if it were in the release notes: "XenProject
releases 4.11, breaks shiny new feature just introduced in 4.10".

> Adding a mandatory ELF-Note which says "yes, I really comply to the
> interface" seems to be weird.

Yes, fundamentally it's a bit ugly to have a "Actually I really do
comply with the interface" flag.  But it's just a little flag tucked
in a header somewhere; the vast majority of the time nobody will see
it -- not even you.  It won't fundamentally make the interface
difficult to use, it won't have any input on the performance or the
size of the resulting binary; it won't tie us into a suboptimal
interface or prevent us from adding nice new features in the future.
It sounds like it won't even existing (compliant) FreeBSD kernels from
taking advantage of 1GiB pages.

Architectural purity is certainly a goal worth striving for, but in
this case the cost to our users is definitely not worth it.

 -George

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel