xen-devel.lists.xenproject.org archive mirror
 help / color / mirror / Atom feed
From: Boris Ostrovsky <boris.ostrovsky@oracle.com>
To: Juergen Gross <jgross@suse.com>, Jan Beulich <JBeulich@suse.com>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>, xen-devel@lists.xen.org
Subject: Re: [PATCH for-4.10] libxc: load acpi RSDP table at correct address
Date: Mon, 20 Nov 2017 11:14:20 -0500	[thread overview]
Message-ID: <cfa72014-ac42-96b8-6663-89c135531e7a@oracle.com> (raw)
In-Reply-To: <e00e14fb-2d15-bfbc-5449-36fce4aac3fd@suse.com>

On 11/20/2017 10:27 AM, Juergen Gross wrote:
> On 20/11/17 15:25, Boris Ostrovsky wrote:
>> On 11/20/2017 09:14 AM, Juergen Gross wrote:
>>> On 20/11/17 14:56, Boris Ostrovsky wrote:
>>>> On 11/20/2017 06:50 AM, Jan Beulich wrote:
>>>>>>>> On 20.11.17 at 12:20, <jgross@suse.com> wrote:
>>>>>> 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.
>>>>> What is "architecturally correct" in PVH can't be read out of
>>>>> specs other than what we write down. When there's no BIOS,
>>>>> placing anything right below the 1Mb boundary is at least
>>>>> bogus.
>>>> Unless it's a UEFI boot -- where else would you put it? Aren't these two
>>>> (UEFI and non-UEFI) the only two options that the ACPI spec provides?
>>> I think Jan is right: for PVH its _our_ job to define the correct
>>> placement. 
>> Yes, and if it is placed in a non-standard location then the guest will
>> have to deal with it in a non-standard way. Which we can in Linux by
>> setting acpi_rsdp pointer in the special PVH entry point, before jumping
>> to Linux "standard" entry --- startup_{32|64}().
>>
>> But if your goal is to avoid that special entry point (and thus not set
>> acpi_rsdp) then how do you expect kernel to find RSDP?
>>
>>> Which still can be the same as in the BIOS case, making
>>> it easier to adapt any guest systems.
>>>
>>> So I'd say: The RSDP address in PVH case is passed in the PVH start
>>> info block to the guest. In case there is no conflict with the
>>> physical load address of the guest kernel the preferred address of
>>> the RSDP is right below the 1MB boundary.
>> And what do we do if there *is* a conflict?
> Either as without my patch: use the first available free memory page.
>
> Or: add a domain config parameter for specifying the RSDP address
> (e.g. default: as today, top: end of RAM, legacy: just below 1MB, or
> a specific value) and fail to load in case of a conflict.

This feels like a band-aid to work around a problem that we want to fix
in the long term anyway.

What could cause grub2 to fail to find space for the pointer in the
first page? Will we ever have anything in EBDA (which is one of the
possible RSDP locations)?

-boris


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

  reply	other threads:[~2017-11-20 16:14 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 [this message]
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

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=cfa72014-ac42-96b8-6663-89c135531e7a@oracle.com \
    --to=boris.ostrovsky@oracle.com \
    --cc=JBeulich@suse.com \
    --cc=andrew.cooper3@citrix.com \
    --cc=jgross@suse.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).