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...
~Michal
