On Wed, Jun 4, 2025 at 5:14 PM Jason Andryuk <jason.andr...@amd.com> wrote:
> 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
