All of lore.kernel.org
 help / color / mirror / Atom feed
From: Shannon Zhao <shannon.zhao@linaro.org>
To: Jan Beulich <JBeulich@suse.com>, Shannon Zhao <zhaoshenglong@huawei.com>
Cc: Hangaohuai <hangaohuai@huawei.com>,
	Ian Campbell <ian.campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	andrew@fubar.geek.nz,
	"Huangpeng(Peter)" <peter.huangpeng@huawei.com>,
	Julien Grall <julien.grall@citrix.com>,
	StefanoStabellini <stefano.stabellini@citrix.com>,
	David Vrabel <david.vrabel@citrix.com>,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>,
	xen-devel <xen-devel@lists.xen.org>,
	Parth Dixit <parth.dixit@linaro.org>,
	Christoffer Dall <christoffer.dall@linaro.org>
Subject: Re: Design doc of adding ACPI support for arm64 on Xen - version 4
Date: Thu, 27 Aug 2015 22:21:16 +0800	[thread overview]
Message-ID: <55DF1CDC.7050106@linaro.org> (raw)
In-Reply-To: <55DF3714020000780009D777@prv-mh.provo.novell.com>



On 2015/8/27 22:13, Jan Beulich wrote:
>>>> On 27.08.15 at 15:50, <shannon.zhao@linaro.org> wrote:
>> On 2015/8/27 15:52, Jan Beulich wrote:
>>> One other aspect completely left off so far is that of proper isolation:
>>> What x86 exposes to Dom0 is specifically limited to what Dom0 is
>>> supposed to know. I'm getting the impression that by exposing more
>>> EFI tables this is being violated just for the purpose of avoiding any
>>> changes to Linux. But maybe I'm misremembering, and all the extra
>>> tables exposed are actually fake ones rather than cloned host ones.
>>
>> Currently we create EFI system table and EFI memory descriptor table as
>> Linux requires. I think the EFI memory descriptor table is necessary.
>> What we didn't reach an agreement is only the EFI system table. Yes, we
>> only use the Configure table of the EFI system table to get the ACPI
>> root address. As you mentioned before, it could pass only the Configure
>> table to Dom0, but we should change the process of parsing the DT and
>> consider the backwards compatibility.
>
> A made up system table would (as said before) be fine with me too.
> Just not a clone of the host one.
>

Yeah, it's a made up one.

>> On the other hand, as the RUNTIME service is not supported, it could
>> assign the runtime service members of EFI system table invalid values
>> and let Dom0 not initialize RUNTIME service(This could be done by making
>> the memory attribute not be EFI_MEMORY_RUNTIME when we create the EFI
>> memory descriptor table). If the RUNTIME service is supported in the
>> future, it doesn't need to change the Linux again. So it could avoid
>> changing back.
>
> I'd strongly advise against such hackery - it will get you (and Xen)
> into the bad firmware corner. EFI without runtime services doesn't
> exist. And runtime services code/data not marked as such are a
> firmware bug (sadly existing in reality on the x86 side). But remember
> that under Xen the Dom0 kernel mustn't care about runtime services
> (other than wanting to be able to invoke them through hypercalls).
>

Oh, I see. Thanks for your explanation.

-- 
Shannon

  reply	other threads:[~2015-08-27 14:21 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-08-19 12:13 Design doc of adding ACPI support for arm64 on Xen - version 4 Shannon Zhao
2015-08-19 14:05 ` Jan Beulich
2015-08-19 18:37   ` Julien Grall
2015-08-20  9:22     ` Jan Beulich
2015-08-20  3:41   ` Shannon Zhao
2015-08-20  9:30     ` Jan Beulich
2015-08-20 12:56       ` Shannon Zhao
2015-08-20 14:06         ` Jan Beulich
2015-08-21  2:25           ` Shannon Zhao
2015-08-21 10:01             ` Jan Beulich
2015-08-27  0:37             ` Julien Grall
2015-08-27  7:52               ` Jan Beulich
2015-08-27 13:50                 ` Shannon Zhao
2015-08-27 14:13                   ` Jan Beulich
2015-08-27 14:21                     ` Shannon Zhao [this message]
2015-08-19 15:02 ` Roger Pau Monné
2015-08-20  3:07   ` Shannon Zhao
2015-08-20  4:58     ` Julien Grall
2015-08-20  8:20     ` Roger Pau Monné
2015-08-20 11:22       ` Shannon Zhao
2015-08-20 11:28         ` Roger Pau Monné
2015-08-20 12:13           ` Jan Beulich
2015-08-20 12:29           ` Shannon Zhao
2015-08-20 13:46             ` Roger Pau Monné
2015-08-20 14:09               ` Jan Beulich
2015-08-21  3:04               ` Shannon Zhao

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=55DF1CDC.7050106@linaro.org \
    --to=shannon.zhao@linaro.org \
    --cc=JBeulich@suse.com \
    --cc=andrew@fubar.geek.nz \
    --cc=boris.ostrovsky@oracle.com \
    --cc=christoffer.dall@linaro.org \
    --cc=david.vrabel@citrix.com \
    --cc=hangaohuai@huawei.com \
    --cc=ian.campbell@citrix.com \
    --cc=julien.grall@citrix.com \
    --cc=parth.dixit@linaro.org \
    --cc=peter.huangpeng@huawei.com \
    --cc=stefano.stabellini@citrix.com \
    --cc=stefano.stabellini@eu.citrix.com \
    --cc=xen-devel@lists.xen.org \
    --cc=zhaoshenglong@huawei.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.