[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH v3 1/3] docs: add documentation for Argo as a feature
- To: Jason Andryuk <jason.andryuk@xxxxxxx>
- From: Christopher Clark <christopher.w.clark@xxxxxxxxx>
- Date: Sun, 8 Jun 2025 10:48:55 +0100
- Cc: Teddy Astie <teddy.astie@xxxxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxxx, Daniel Smith <dpsmith@xxxxxxxxxxxxxxxxxxxx>, Rich Persaud <persaur@xxxxxxxxx>, Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, Anthony PERARD <anthony.perard@xxxxxxxxxx>, Michal Orzel <michal.orzel@xxxxxxx>, Jan Beulich <jbeulich@xxxxxxxx>, Julien Grall <julien@xxxxxxx>, Roger Pau Monné <roger.pau@xxxxxxxxxx>, Stefano Stabellini <sstabellini@xxxxxxxxxx>
- Delivery-date: Sun, 08 Jun 2025 09:49:27 +0000
- List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
On 2025-05-29 18:40, Teddy Astie wrote:
> Hello Christopher,
>
> Le 28/05/2025 à 23:13, Christopher Clark a écrit :
>> +## Argo and VirtIO
>> +
>> +References to design documentation for the development of an Argo
>> +transport for VirtIO are available via:
>> +https://wiki.xenproject.org/wiki/Virtio_On_Xen
>> +
>
> Are there news regarding this ?
>
> There is work done on virtio-msg [1], which looks fairly similar to
> virtio-argo (or at least, virtio-msg could work with Argo in a similar
> fashion to what's described on the virtio-argo design).
>
> [1] https://linaro.atlassian.net/wiki/spaces/HVAC/overview
I appreciate the interest - I don't have additional material on it at the moment.
I think this should be dropped. We don't need a link to a design
document without an implementation. You can add it once you've
upstreamed the implementation.
OK, I'll remove this section for the next version of the series.
>> +# Known issues
>> +
>> +* For development: sysctl/domctls for toolstack to control per-VM access
>> + to Argo
>> +
>
> Is it regarding disabling the argo on a per-guest basis, or regarding if
> a specific VM can communicate with another VM ? i.e can the toolstack
> decide to prevent 2 guest from communicating ?
>
> IIRC, in Argo, a guest on his own can decide who can communicate with
> him using separate registered rings. But I am not sure if there is more
> on that regard.
It's to do with enabling administrative controls for the toolstack to be able to govern access to Argo by individual VMs on a per-VM basis. At the moment there is a host boot option that turns it on or off for the system and there are XSM/Flask policy controls that govern access to Argo by individual VMs on a per-VM basis, but that is less accessible for a system administrator to apply changes to VM access and less dynamic than some use cases may require.
Yes, I think the existing text needs to be rephrased to be more explicit
on the issue. I can guess what it is, but I shouldn't have to. I'd
recommend stating the issue as it exists, and then optionally clearly
state a proposed solution.
Fair, thanks, will revise it.
Christopher
|
