Re: [Xen-devel] Patches for stable

[Juergen Gross <jgross@xxxxxxxx>]

On 06/04/18 13:13, George Dunlap wrote:
> On Fri, Apr 6, 2018 at 11:57 AM, Juergen Gross <jgross@xxxxxxxx> wrote:
>> On 06/04/18 12:07, George Dunlap wrote:
>>> On Fri, Apr 6, 2018 at 11:02 AM, Juergen Gross <jgross@xxxxxxxx> wrote:
>>>> On 06/04/18 11:49, George Dunlap wrote:
>>>>> On Thu, Apr 5, 2018 at 7:33 PM, Boris Ostrovsky
>>>>> <boris.ostrovsky@xxxxxxxxxx> 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@xxxxxxxx> wrote:
>>>>>>>>> On 05/04/18 15:42, George Dunlap wrote:
>>>>>>>>>> On Thu, Apr 5, 2018 at 2:06 PM, Juergen Gross <jgross@xxxxxxxx> 
>>>>>>>>>> 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 ?


Juergen


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