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

[Stefano Stabellini <sstabellini@xxxxxxxxxx>]

On Mon, 9 Jul 2018, Julien Grall wrote:
> 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.

I'll add a note about this limitation to the dom0less doc I am writing.

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