Re: [Xen-devel] [ANNOUNCE] Call for agenda items for September 5th Community Call @ 15:00 UTC

[Juergen Gross <jgross@xxxxxxxx>]

On 05.09.19 09:41, Rich Persaud wrote:
> > On Sep 5, 2019, at 03:19, Jan Beulich <jbeulich@xxxxxxxx> wrote:
> >
> > > On 05.09.2019 04:32, Rich Persaud wrote:
> > > Agenda item:  Domain name service for nested virt and disaggregation
> > >
> > > (text based on draft by Daniel Smith, who will speak to this agenda item)
> > >
> > > If a future, minimal "L0 Xen" hypervisor can be optimized for nested 
> > > virtualization in greenfield deployments (i.e. no requirement to maintain existing 
> > > hypervisor-guest interfaces), then PV driver mechanisms other than grants, events and 
> > > xenstore could be considered.  This was discussed in a Xen Summit 2019 design session:
> > > https://lists.gt.net/xen/devel/560973
> > >
> > > For some OpenXT use cases, we are in the process of further disaggregating the 
> > > platform.  We need a name service to enable the disaggregated service domains 
> > > to discover the other service domains with which they need to communicate.  
> > > Xenstore is not sufficient, as we would like to use Flask to control the data 
> > > flow, as well as applying mandatory access control to service calls.
> > >
> > > We are reaching out to the Xen Community to elicit input on approaches, such 
> > > that we might be able to submit an upstream RFC based on our early work:
> > >
> > > - For a communication channel we are looking to leverage Argo, which is 
> > > currently in experimental status. Its predecessor (v4v) is already being used 
> > > in a similar fashion by Bromium uXen (https://github.com/openxt/uxen), which 
> > > functions well across nested hypervisors.  uXen v4v includes a mechanism to 
> > > control information flow.
> > >
> > > - An open question is how to address the domains. Xen domain ids are reused and 
> > > have no guarantee for uniqueness.  UUIDs are available and can provide better 
> > > guarantees for uniqueness. Another approach is to use the name string which 
> > > allows the ability for punctuation characters, eg. : or /, to create namespaced 
> > > names for the domains.
> > Forgive me asking, but why is this put up as an agenda item here?
> > IMO this is the kind of thing where you would send a proposal and
> > request feedback by email first, and put it up as an agenda item
> > here only if it got stalled there. (Apologies if I've overlooked
> > such a stalled thread.)
> If Xen community call topics are limited to escalations of xen-devel threads, 
> then a new thread can be created for this topic. Xen community calls have also 
> provided real-time, interactive feedback on candidate proposals, along with 
> guidance on areas which need documentation before a formal proposal is made to 
> xen-devel.   Such agenda items are typically covered after all series and 
> priority topics have been addressed.
I kind of agree with Jan, but I can see your point.

My approach to address something like that would be to send a patch
adding the high level feature document to e.g. docs/features. This
can be accompanied by a rough RFC implementation, but that wouldn't
be required. By sending a first patch you show some commitment to the
topic, but you don't have to invest too much time in case the idea is
rejected. And with a patch you automatically request some feedback.
The feature document would only be committed with the code, of course.


Juergen


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel