On 05.09.19 09:41, Rich Persaud wrote:
On Sep 5, 2019, at 03:19, Jan Beulich <[email protected]> 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
[email protected]
https://lists.xenproject.org/mailman/listinfo/xen-devel
