On 29/01/2020 00:36, Daniel Smith wrote:
> ### Discussion
>
> Requested: an in-Xen-tree reference domB implementation
>
> Note: the hypervisor interface supports starting a domain with a
> specified domid. This is not made available by the libxl toolstack.
>
> Xen has logic on permission delegation:
>
> - in order for a VM to be able to delegate a permission to another, it
> itself must have that permission.
>
> - **ACTION**: change this to be implemented as a XSM hook, so that
> > policy can choose to override this constraint, while
> > preserving it (ie. the existing behaviour) as the default.
I think it is worth highlighting that Xen's current behaviour appears to
have regressed an older usecase accidentally, and this proposed approach
is close to the original idea for hwdom.
> The domain id to assign to domB: should not be zero.
>
> - Recommendation is to use a new fixed domain id allocated from the
> reserved range.
>
> - See DOMID\_IDLE, DOMID\_INVALID, etc in \<xen.h\>
>
> The is\_hardware\_domain predicate
>
> - uses within Xen not necessarily all consistent?
I think the current uses of is_{hardware,control}_domain() should be
ok. We've been fairly careful since the separate hwdom logic first went in.
> - convert this to a XSM hook?
>
> - ***to be determined***: performance impact since hits the avc?
What changes in a "even the XSM dummy policy is actually a flask policy"
world is that there is that the concept of "the hardware/control domain"
blurs. Its all strictly "can $DOM do $X?".
That said, while "the" control domain can probably disappear, "the"
hardware domain probably can't. There needs to be some entity
responsible for at least, getting notifications of newly hotplugged
hardware.
>
> Need to not shut down the platform when domB exits
>
> - ie. distinguish domB from the hardware domain
>
> Since the hypervisor ABI is unstable, specifically the domain building
> hypercalls, will need to use the Xen toolstack:
>
> - so libxc/libxl is the right interface for initial domB domain logic
> to use
>
> - otherwise problematic when Xen hypervisor version is changed
>
> - in the near term, this mandates the use of Linux + toolstack
This aspect is being worked on for plenty of other good reasons.
With any luck, it will be in process by the time domB wants to get
around to using it.
> ### Decision:
>
> use full Linux within domB as starting point
>
> - unikraft discussed, not selected: is not deployed in production and
> want to use mature, QA\'d and externally maintained components
> - 32MB size for the kernel queried: proposers have no issue with that
> size
>
> Request made for a script interpreter in an example domB, with scripts
> to start dom0 with a given set of permissions
>
> - aim is to make domB usable for other people\'s use cases and widen
> adoption, help other people with what we build for domB
I think the point was that the first reference domB ought to be
something fairly familiar and easily tweak-able. In particular, that
reduces the quantity of concurrent work to do while getting the
hypervisor pieces in place.
However, I think it would also be helpful of stating the eventual design
goals, to keep the microkernel plan in mind.
~Andrew
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
