From: Jason Andryuk <jason.andryuk@amd.com>
To: "Orzel, Michal" <michal.orzel@amd.com>, <xen-devel@lists.xenproject.org>
Cc: Stefano Stabellini <sstabellini@kernel.org>,
Julien Grall <julien@xen.org>,
Bertrand Marquis <bertrand.marquis@arm.com>
Subject: Re: [PATCH v3 8/8] xen/dom0less: store xenstore event channel in page
Date: Wed, 27 Aug 2025 09:24:03 -0400 [thread overview]
Message-ID: <376fa306-1b77-4bf1-ba02-9a8d7946e70c@amd.com> (raw)
In-Reply-To: <b59ea812-6c97-49ea-b7a9-c02e3e265800@amd.com>
On 2025-08-27 04:03, Orzel, Michal wrote:
>
>
> On 26/08/2025 23:08, Jason Andryuk wrote:
>> Write the associated event channel into the xenstore page so xenstored
>> can read it. xenstored can map the grant by the reserved grant table
>> entry, and then read out the event channel and bind it. This eliminates
>> the need for an additional mechanism to discover the event channel.
>>
>> Signed-off-by: Jason Andryuk <jason.andryuk@amd.com>
>> ---
>> v2:
>> No change
>>
>> This should go in after the init-dom0less changes so init-dom0less is
>> ready for xenstored automatically introducing domains.
>>
>> I'm looking for feedback. This is ARM-only for the time being, but that
>> is the only in-tree user of this code. From the perspective, it is okay
>> to go in.
>>
>> If we want a cross-arch approach, a common function to write to guest
>> physical addresses would be needed for additional arches, but they
>> aren't available yet.
>>
>> Oleksii added a function pointer to dtb_load() and initrd_load() when
>> moving dom0less to common, but I think that isn't necessary. Just
>> having a common helper would be sufficient.
>>
>> copy_to_guest_phys() or something_copy_to_guest_phys() could be defined
>> or a wrapper for ARM's copy_to_guest_phys_flush_dcache(). Other arches
>> could need to implement it when using dom0less.
>>
>> I'm not an ARM expert, but Stefano said
>> copy_to_guest_phys_flush_dcache() is not necessary since this xenstore
>> page isn't expected to be accessed without caches enabled.
> I'm not sure I understand this point. When copying data *to* the guest, cleaning
> is about Xen's cache, not guest's...
I was trying to highlight that the patch is using
access_guest_memory_by_gpa(), but dtb_load() and initrd_load() use
copy_to_guest_phys_flush_dcache().
I assumed from the name, and Stefano's comment, that
copy_to_guest_phys_flush_dcache() was about ensuring the CPU's cache is
flushed to RAM. That way a guest starting with cache disabled would see
the correct contents. But I don't really know how it works and may be
wrong.
Thanks,
Jason
prev parent reply other threads:[~2025-08-27 13:23 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-08-26 21:08 [PATCH v3 0/8] init-dom0less and dom0less xenstore evtchn Jason Andryuk
2025-08-26 21:08 ` [PATCH v3 1/8] tools/init-dom0less: Make handles global Jason Andryuk
2025-08-27 15:12 ` Jürgen Groß
2025-08-26 21:08 ` [PATCH v3 2/8] tools/init-dom0less: Factor out xenstore setup Jason Andryuk
2025-08-26 21:08 ` [PATCH v3 3/8] tools/init-dom0less: Only introduce un-introduced domains Jason Andryuk
2025-08-26 21:08 ` [PATCH v3 4/8] tools/init-dom0less: Switch domain_exists to check xenstore name Jason Andryuk
2025-08-26 21:08 ` [PATCH v3 5/8] tools/init-dom0less: Use introduced to determine no-enhanced Jason Andryuk
2025-08-26 21:08 ` [PATCH v3 6/8] tools/init-dom0less: Remove use of err() Jason Andryuk
2025-08-26 21:08 ` [PATCH v3 7/8] tools/init-dom0less: Continue on error Jason Andryuk
2025-08-26 21:08 ` [PATCH v3 8/8] xen/dom0less: store xenstore event channel in page Jason Andryuk
2025-08-27 7:58 ` Jan Beulich
2025-08-27 13:19 ` Jason Andryuk
2025-08-27 14:00 ` Jan Beulich
2025-08-27 8:03 ` Orzel, Michal
2025-08-27 13:24 ` Jason Andryuk [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=376fa306-1b77-4bf1-ba02-9a8d7946e70c@amd.com \
--to=jason.andryuk@amd.com \
--cc=bertrand.marquis@arm.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 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.