From: "Daniel P. Smith" <dpsmith@apertussolutions.com>
To: Henry Wang <xin.wang2@amd.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: Tue, 30 Apr 2024 06:22:39 -0400 [thread overview]
Message-ID: <3054018d-1ae4-43c5-b44a-2ecf1b4cdfc7@apertussolutions.com> (raw)
In-Reply-To: <03357204-0308-46a2-a215-142d681d2b6a@amd.com>
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.
v/r,
dps
next prev parent reply other threads:[~2024-04-30 10:23 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 [this message]
2024-05-06 3:13 ` Henry Wang
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=3054018d-1ae4-43c5-b44a-2ecf1b4cdfc7@apertussolutions.com \
--to=dpsmith@apertussolutions.com \
--cc=Volodymyr_Babchuk@epam.com \
--cc=alec.kwapis@medtronic.com \
--cc=anthony.perard@citrix.com \
--cc=bertrand.marquis@arm.com \
--cc=jgross@suse.com \
--cc=julien@xen.org \
--cc=michal.orzel@amd.com \
--cc=sstabellini@kernel.org \
--cc=xen-devel@lists.xenproject.org \
--cc=xin.wang2@amd.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 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).