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.
I think extending the PVH interface in such a way is no good idea.
Option 1: Put the RSDP in lowmem unless we know the guest will use the address in start_info Pro: Existing Linux instances boot Con: Existing BSD instances whose memory is an exact multiple of 1 GiB will have slightly slower TLB miss times.
Option 2: Put the RSDP in highmem regardless Pro: Existing BSD instances whose memory is an exact multiple of 1GiB will have slightly faster TLB miss times Con: Existing Linux instances don't boot at all
This seems like a no-brainer to me. But anyway, maybe we should move the discussion elsewhere and stop bothering Greg. :-)
-George