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

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


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

While I like the idea of having multiple domain created by Xen, I think
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.


Julien Grall

Xen-devel mailing list



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