Re: Patches for stable

[George Dunlap <dunlapg@umich.edu>]

On Fri, Apr 6, 2018 at 2:12 PM, Juergen Gross <jgross@suse.com> wrote:
> On 06/04/18 13:13, George Dunlap wrote:
>> On Fri, Apr 6, 2018 at 11:57 AM, Juergen Gross <jgross@suse.com> wrote:
>>> On 06/04/18 12:07, George Dunlap wrote:
>>>> On Fri, Apr 6, 2018 at 11:02 AM, Juergen Gross <jgross@suse.com> wrote:
>>>>> On 06/04/18 11:49, George Dunlap wrote:
>>>>>> On Thu, Apr 5, 2018 at 7:33 PM, Boris Ostrovsky
>>>>>> <boris.ostrovsky@oracle.com> 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.
>>>>>>
>>>>>> OTOH, one advantage of having a separate elfnote, rather than gating
>>>>>> it on Linux version, is that if a distro wanted to, they could do
>>>>>> their own backport to (say) Linux 4.15 and reap the advantages.
>>>>>
>>>>> Hmm, Linux kernel has already an elfnote with the guest version. It is
>>>>> set to "2.6". What about writing the actual kernel version into that
>>>>> note and assume everything != "2.6" to support a high RSDP address?
>>>>
>>>> Why do you think it's 2.6 in the first place?  Because there are
>>>> user-space tools that depend on the kernel version being equal to
>>>> "2.6" which would break if that were changed.
>>>
>>> Can you give me a hint where this would be? The elfnote is being fed
>>> into elf_dom_parms->guest_ver. I couldn't find any reference to that
>>> other than setting it.
>>>
>>> The other reference I could find is the readnotes utility. In the Xen
>>> tree I couldn't find any tool using the output of that.
>>>
>>>> *This* is the degree to which the Linux community tries to prevent
>>>> breaking existing systems -- because of a clear bug in userspace
>>>> tooling, they've kept the advertized kernel version the same for the
>>>> better part of a decade.
>>>
>>> You are aware of the fact I'm speaking of a Xen-specific elfnote?
>>
>> No I wasn't.
>>
>> FWIW I think taking "I have set the kernel version correctly" to mean
>> "I know to read the address of the RSDP table from the start_info
>> page" isn't a very good idea.  For one, it's fragile: someone may not
>> realize that the one implies the other.  Secondly, it may turn out
>> that there's a reason it's been kept at "2.6", and then we'd have to
>> revert the one change and make a new elfnote anyway.
>
> Hmm, good point.
>
> So its time for a new XENFEAT_ value then? This would be the least
> intrusive way to add such a flag. Something like
> XENFEAT_linux_high_rsdp_address_okay ?

That sounds reasonable to me.  I'd personally make it something like
"reads_rsdp_from_start_info" or something, but the name doesn't matter
to me as much. :-)

The other option would be to introduce a "max_pvh_interface_supported"
or something.  If it's not present (and it's a Linux kernel), default
it to '0', and have that mean "RSDP must be under 1MiB".

That will allow us elbow-room in the future if we want to make other
breaking changes like this, without needing to keep a separate flag
around for each one indefinitely.

 -George

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