From: Henry Wang <xin.wang2@amd.com>
To: "Daniel P. Smith" <dpsmith@apertussolutions.com>,
<xen-devel@lists.xenproject.org>
Cc: Anthony PERARD <anthony.perard@citrix.com>,
Juergen Gross <jgross@suse.com>,
Stefano Stabellini <sstabellini@kernel.org>,
Julien Grall <julien@xen.org>,
Bertrand Marquis <bertrand.marquis@arm.com>,
Michal Orzel <michal.orzel@amd.com>,
Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>,
"Alec Kwapis" <alec.kwapis@medtronic.com>
Subject: Re: [PATCH 1/3] xen/arm/dom0less-build: Alloc magic pages for Dom0less DomUs from hypervisor
Date: Mon, 6 May 2024 11:13:04 +0800 [thread overview]
Message-ID: <eda5fd5b-87de-4da1-a785-44da563176cb@amd.com> (raw)
In-Reply-To: <3054018d-1ae4-43c5-b44a-2ecf1b4cdfc7@apertussolutions.com>
Hi Daniel,
On 4/30/2024 6:22 PM, Daniel P. Smith wrote:
> On 4/29/24 22:55, Henry Wang wrote:
>> Hi Daniel,
>>
>> On 4/30/2024 8:27 AM, Daniel P. Smith wrote:
>>> On 4/25/24 23:14, Henry Wang wrote:
>>>> There are use cases (for example using the PV driver) in Dom0less
>>>> setup that require Dom0less DomUs start immediately with Dom0, but
>>>> initialize XenStore later after Dom0's successful boot and call to
>>>> the init-dom0less application.
>>>>
>>>> An error message can seen from the init-dom0less application on
>>>> 1:1 direct-mapped domains:
>>>> ```
>>>> Allocating magic pages
>>>> memory.c:238:d0v0 mfn 0x39000 doesn't belong to d1
>>>> Error on alloc magic pages
>>>> ```
>>>> This is because currently the magic pages for Dom0less DomUs are
>>>> populated by the init-dom0less app through populate_physmap(), and
>>>> populate_physmap() automatically assumes gfn == mfn for 1:1 direct
>>>> mapped domains. This cannot be true for the magic pages that are
>>>> allocated later from the init-dom0less application executed in Dom0.
>>>> For domain using statically allocated memory but not 1:1
>>>> direct-mapped,
>>>> similar error "failed to retrieve a reserved page" can be seen as the
>>>> reserved memory list is empty at that time.
>>>>
>>>> To solve above issue, this commit allocates the magic pages for
>>>> Dom0less DomUs at the domain construction time. The base address/PFN
>>>> of the magic page region will be noted and communicated to the
>>>> init-dom0less application in Dom0.
>>>
>>> Might I suggest we not refer to these as magic pages? I would
>>> consider them as hypervisor reserved pages for the VM to have access
>>> to virtual platform capabilities. We may see this expand in the
>>> future for some unforeseen, new capability.
>>
>> I think magic page is a specific terminology to refer to these pages,
>> see alloc_magic_pages() for both x86 and Arm. I will reword the last
>> paragraph of the commit message to refer them as "hypervisor reserved
>> pages (currently used as magic pages on Arm)" if this sounds good to
>> you.
>
> I would highlight that is a term used in the toolstack, while is
> probably not the best, there is no reason to change in there, but the
> hypervisor does not carry that terminology. IMHO we should not
> introduce it there and be explicit about why the pages are getting
> reserved.
Thanks for the suggestion. I will rework the commit message.
Kind regards,
Henry
>
> v/r,
> dps
>
next prev parent reply other threads:[~2024-05-06 3:13 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-04-26 3:14 [PATCH 0/3] Guest magic region allocation for 11 Dom0less domUs - Take two Henry Wang
2024-04-26 3:14 ` [PATCH 1/3] xen/arm/dom0less-build: Alloc magic pages for Dom0less DomUs from hypervisor Henry Wang
2024-04-30 0:27 ` Daniel P. Smith
2024-04-30 2:55 ` Henry Wang
2024-04-30 10:22 ` Daniel P. Smith
2024-05-06 3:13 ` Henry Wang [this message]
2024-05-10 7:37 ` Michal Orzel
2024-05-10 7:42 ` Henry Wang
2024-04-26 3:14 ` [PATCH 2/3] xen/arm, tools: Add a new HVM_PARAM_MAGIC_BASE_PFN key in HVMOP Henry Wang
2024-04-26 6:21 ` Jan Beulich
2024-04-26 6:30 ` Henry Wang
2024-04-26 6:50 ` Jan Beulich
2024-04-26 7:02 ` Henry Wang
2024-04-30 0:31 ` Daniel P. Smith
2024-04-30 2:51 ` Henry Wang
2024-04-30 6:11 ` Jan Beulich
2024-04-30 8:12 ` Henry Wang
2024-04-30 8:51 ` Jan Beulich
2024-04-30 0:35 ` Daniel P. Smith
2024-04-30 1:25 ` Daniel P. Smith
2024-05-02 18:08 ` Stefano Stabellini
2024-05-06 2:01 ` Henry Wang
2024-04-26 3:14 ` [PATCH 3/3] tools/init-dom0less: Avoid hardcoding GUEST_MAGIC_BASE Henry Wang
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=eda5fd5b-87de-4da1-a785-44da563176cb@amd.com \
--to=xin.wang2@amd.com \
--cc=Volodymyr_Babchuk@epam.com \
--cc=alec.kwapis@medtronic.com \
--cc=anthony.perard@citrix.com \
--cc=bertrand.marquis@arm.com \
--cc=dpsmith@apertussolutions.com \
--cc=jgross@suse.com \
--cc=julien@xen.org \
--cc=michal.orzel@amd.com \
--cc=sstabellini@kernel.org \
--cc=xen-devel@lists.xenproject.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 read-only IMAP folder(s) and NNTP newsgroup(s).