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


Juergen

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

Reply via email to