Re: [Xen-devel] [PATCH RFC 14/15] xen/arm: call construct_domU from start_xen and start DomU VMs

[Julien Grall <julien.grall@xxxxxxx>]

Hi,

On 09/07/2018 21:59, Stefano Stabellini wrote:
> On Mon, 9 Jul 2018, Julien Grall wrote:
> > Hi Stefano,
> >
> > On 07/07/18 00:11, Stefano Stabellini wrote:
> > > On Fri, 15 Jun 2018, Julien Grall wrote:
> > > > On 06/13/2018 11:15 PM, Stefano Stabellini wrote:
> > > > > Introduce support for the "xen,domU" compatible node on device tree.
> > > > > Create new DomU VMs based on the information found on device tree under
> > > > > "xen,domU".
> > > > While I like the idea of having multiple domain created by Xen, I think
> > > > there
> > > > are still few open questions here:
> > > >         1) The domains will be listed via "xl list". So are they still
> > > > manageable via DOMCTL?
> > > Yes, they are. There is an argument for making them "hidden" from
> > > DOMCTLs, but that is not done as part of this series. Future work.
> > What will happen with libxl today? Is the toolstack going to be confused?
> The toolstack can list the running domains without problems with `xl
> list' (although they have no name). Also, xl vcpu-pin works fine.
> However, some operations might not work correctly though. For instance,
> `xl destroy' cannot completely get rid of the domain. I'll add info
> about these limitations to a separate dom0less document (as you also
> suggested below), because it is not part of the multiboot spec.
>
>
> > > >         2) Is it possible to restart those domains?
> > > No they can't be restarted. For example, their original kernel is gone
> > > from memory.
> > So what will happen if you use "xl restart" on them?
> Do you mean `xl reboot'?  The command executes but nothing happens.
>
>
> > > >         3) If a domain crash, what will happen? Are they just going to  sit
> > > > there using resources until the platform rebooted?
> > > The entire platform needs to be rebooted.
> > That should be clarified somewhere in the documentation.
> Yes, you are right. I'll add this to the new dom0less doc.
>
>
> > > >         4) How do you handle scheduling? Is it still possible to do it via
> > > > Dom0? How about the dom0less situation?
> > > The scheduler can be chosen via the Xen command line option. It is also
> > > possible to do that from dom0 (if there is a dom0).
> > Can you explain how the vCPUs are going to get pinned via the command line?
> Today, only dom0 vCPUs can get automatically pinned with a Xen command
> line option. However, `xl vcpu-pin' in dom0 works with other domains
> started by Xen at boot, and the NULL scheduler doesn't require pinning.
> FYI for my own usage, I plan to use the NULL scheduler.
Well your series is called "Dom0less", so using Dom0 to pin the vCPU 
does not look right to me.
But even with NULL scheduler you may want to pin a vCPU to a given pCPU. 
Imagine a big.LITTLE environment. However, NULL scheduler is not 
supported, so it feels a little odd that there are no way to configure 
guest DomU without Dom0 in play.
So there is some clarification needed here.

Cheers,

--
Julien Grall

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