From: Boris Ostrovsky <boris.ostrovsky@oracle.com>
To: Juergen Gross <jgross@suse.com>,
Andrew Cooper <andrew.cooper3@citrix.com>,
xen-devel@lists.xen.org, Maran Wilson <maran.wilson@oracle.com>,
Jan Beulich <jbeulich@suse.com>,
Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [PATCH for-4.10] libxc: load acpi RSDP table at correct address
Date: Mon, 20 Nov 2017 08:51:16 -0500 [thread overview]
Message-ID: <e49ca8cb-a756-0092-6da7-8bcd85d352d9@oracle.com> (raw)
In-Reply-To: <7269e6ba-7fab-a0a4-0daa-8aca59d7d273@suse.com>
On 11/20/2017 06:20 AM, Juergen Gross wrote:
> On 20/11/17 11:57, Andrew Cooper wrote:
>> On 20/11/17 10:43, Juergen Gross wrote:
>>> On 20/11/17 11:21, Andrew Cooper wrote:
>>>> On 20/11/17 10:04, Juergen Gross wrote:
>>>>> On 20/11/17 10:58, Andrew Cooper wrote:
>>>>>> On 20/11/2017 09:55, Juergen Gross wrote:
>>>>>>> On 20/11/17 10:51, Roger Pau Monné wrote:
>>>>>>>> Adding xen-devel, dropped it on my reply.
>>>>>>>>
>>>>>>>> Replying from my phone, sorry for the formatting.
>>>>>>>>
>>>>>>>>
>>>>>>>> El 20 nov. 2017 9:35, "Juergen Gross" <jgross@suse.com
>>>>>>>> <mailto:jgross@suse.com>> escribió:
>>>>>>>>
>>>>>>>> For PVH domains loading of the ACPI RSDP table is done via
>>>>>>>> allocating
>>>>>>>> a domain loader segment after having loaded the kernel. This
>>>>>>>> leads to
>>>>>>>> the RSDP table being loaded at an arbitrary guest address instead of
>>>>>>>> the architectural correct address just below 1MB.
>>>>>>>>
>>>>>>>>
>>>>>>>> AFAIK this is only true for legacy BIOS boot, when using UEFI the
>>>>>>>> RSDP can be anywhere in memory, hence grub2 must already have an
>>>>>>>> alternative way of finding the RSDP apart from scanning the low 1MB.
>>>>>>> The problem isn't grub2, but the loaded linux kernel. Without this
>>>>>>> patch Linux won't find the RSDP when booted in a PVH domain via grub2.
>>>>>>>
>>>>>>> I could modify grub2 even further to move the RSDP to the correct
>>>>>>> address, but I think doing it correctly on Xen side is the better
>>>>>>> option.
>>>>>> Why? The PVH info block contains a pointer directly to the RSDP, and
>>>>>> Linux should be following this rather than scanning for it using the
>>>>>> legacy method.
>>>>> Oh no, please not this discussion again.
>>>>>
>>>>> We already had a very long discussion how to do PVH support in grub2,
>>>>> and the outcome was to try to use the standard boot entry of the kernel
>>>>> instead the PVH sepcific one.
>>>>>
>>>>> The Linux kernel right now doesn't make use of the RSDP pointer in the
>>>>> PVH info block, so I think we shouldn't change this when using grub2.
As I mentioned in the other thread --- it will when we get to dom0 support.
>>>> I clearly missed the previous discussion, and I don't advocate using yet
>>>> another PVH-specific entry point, but how does Linux cope in other
>>>> non-BIOS environments? Does it genuinely rely exclusively on the legacy
>>>> mechanism?
FYI (and this is not directly related to this thread) there was a
discussion with KVM engineers and they may be interested in doing a
PVH-like boot, using Xen PVH entry point.
Adding Maran who is looking at this.
-boris
>>> Looking at the code I think so, yes. Maybe there are cases where no RSDP
>>> is needed, but in the grub2/PVH case we need it to distinguish PVH from
>>> HVM.
>> In which case, being a Linux limitation, I think it is wrong to
>> unilaterally apply this restriction to all other PVH guests.
> Which restriction? I'm loading the RSDP table to its architectural
> correct addres if possible, otherwise it will be loaded to the same
> address as without my patch. So I'm not adding a restriction, but
> removing one.
>
>> Doing this in grub seems like the more appropriate place IMO.
> I don't think so.
>
>
> Juergen
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> https://lists.xen.org/xen-devel
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
prev parent reply other threads:[~2017-11-20 13:51 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-11-20 8:34 [PATCH for-4.10] libxc: load acpi RSDP table at correct address Juergen Gross
[not found] ` <CAPLaKK5OH3Fj=9EgVZ19=8kiRuHwftWnYduoV7+rkFU_bkWBgQ@mail.gmail.com>
2017-11-20 9:51 ` Roger Pau Monné
2017-11-20 9:55 ` Juergen Gross
2017-11-20 9:58 ` Andrew Cooper
2017-11-20 10:04 ` Juergen Gross
2017-11-20 10:21 ` Andrew Cooper
2017-11-20 10:43 ` Juergen Gross
2017-11-20 10:57 ` Andrew Cooper
2017-11-20 11:20 ` Juergen Gross
2017-11-20 11:50 ` Jan Beulich
2017-11-20 13:56 ` Boris Ostrovsky
2017-11-20 14:11 ` Jan Beulich
2017-11-20 14:14 ` Juergen Gross
2017-11-20 14:20 ` Jan Beulich
2017-11-20 14:25 ` Boris Ostrovsky
2017-11-20 14:36 ` Andrew Cooper
2017-11-20 14:52 ` Boris Ostrovsky
2017-11-20 15:27 ` Juergen Gross
2017-11-20 16:14 ` Boris Ostrovsky
2017-11-20 16:26 ` Jan Beulich
2017-11-20 16:28 ` Boris Ostrovsky
2017-11-20 16:43 ` Jan Beulich
2017-11-20 16:59 ` Boris Ostrovsky
2017-11-21 7:44 ` Jan Beulich
2017-11-21 10:42 ` Andrew Cooper
2017-11-21 11:13 ` Juergen Gross
2017-11-22 10:26 ` Roger Pau Monné
2017-11-20 18:29 ` Juergen Gross
[not found] ` <5A12F2BA02000078001901F3@suse.com>
2017-11-20 15:24 ` Juergen Gross
2017-11-20 16:14 ` Jan Beulich
[not found] ` <5A130D68020000780019032E@suse.com>
2017-11-20 18:28 ` Juergen Gross
2017-11-21 7:50 ` Jan Beulich
[not found] ` <5A13E8DB0200007800190512@suse.com>
2017-11-21 8:13 ` Juergen Gross
2017-11-21 8:46 ` Jan Beulich
[not found] ` <5A13F5DD02000078001905AC@suse.com>
2017-11-21 9:37 ` Juergen Gross
2017-11-21 10:44 ` Andrew Cooper
2017-11-20 13:51 ` Boris Ostrovsky [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=e49ca8cb-a756-0092-6da7-8bcd85d352d9@oracle.com \
--to=boris.ostrovsky@oracle.com \
--cc=andrew.cooper3@citrix.com \
--cc=jbeulich@suse.com \
--cc=jgross@suse.com \
--cc=konrad.wilk@oracle.com \
--cc=maran.wilson@oracle.com \
--cc=xen-devel@lists.xen.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).