[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] Patches for stable
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? Juergen _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxxx https://lists.xenproject.org/mailman/listinfo/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |