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.andr...@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
