[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



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

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.