[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH v3 5/5] tools: add example application to initialize dom0less PV drivers
Hi Stefano,
On 01/04/2022 01:35, Stefano Stabellini wrote:
+
+ /* Alloc magic pages */
+ if (alloc_magic_pages(info, &dom) != 0) {
+ printf("Error on alloc magic pages\n");
+ return 1;
+ }
+
+ xc_dom_gnttab_init(&dom);
This call as the risk to break the guest if the dom0 Linux doesn't support
the
acquire interface. This is because it will punch a hole in the domain
memory
where the grant-table may have already been mapped.
Also, this function could fails.
I'll check for return errors. Dom0less is for fully static
configurations so I think it is OK to return error and abort if
something unexpected happens: dom0less' main reason for being is that
there is nothing unexpected :-)
Does this mean the caller will have to reboot the system if there is an error?
IOW, we don't expect them to call ./init-dom0less twice.
Yes, exactly. I think init-dom0less could even panic. My mental model is
that this is an "extension" of construct_domU. Over there we just panic
if something is wrong and here it would be similar. The user provided a
wrong config and should fix it.
Ok. I think we should make explicit how it can be used.
+
+ libxl_uuid_generate(&uuid);
+ xc_domain_sethandle(dom.xch, info->domid,
libxl_uuid_bytearray(&uuid));
+
+ rc = gen_stub_json_config(info->domid, &uuid);
+ if (rc)
+ err(1, "gen_stub_json_config");
+
+ rc = restore_xenstore(xsh, info, uuid, dom.xenstore_evtchn);
+ if (rc)
+ err(1, "writing to xenstore");
+
+ xs_introduce_domain(xsh, info->domid,
+ (GUEST_MAGIC_BASE >> XC_PAGE_SHIFT) + XENSTORE_PFN_OFFSET,
+ dom.xenstore_evtchn);
xs_introduce_domain() can technically fails.
OK
+ return 0;
+}
+
+/* Check if domain has been configured in XS */
+static bool domain_exists(struct xs_handle *xsh, int domid)
+{
+ return xs_is_domain_introduced(xsh, domid);
+}
Would not this lead to initialize a domain with PV driver disabled?
I am not sure I understood your question, but I'll try to answer anyway.
This check is purely to distinguish dom0less guests, which needs further
initializations, from regular guests (e.g. xl guests) that don't need
any actions taken here.
Dom0less domUs can be divided in two categories based on whether they are xen
aware (e.g. xen,enhanced is set).
Looking at this script, it seems to assume that all dom0less domUs are Xen
aware. So it will end up to allocate Xenstore ring and call
xs_introduce_domain(). I suspect the call will end up to fail because the
event channel would be 0.
So did you try to use this script on a platform where there only xen aware
domU and/or a mix?
Good idea of asking for this test. I thought I already ran that test,
but I did it again to be sure. Everything works OK (although the
xenstore page allocation is unneeded). xs_introduce_domain does not
> fail:
Are you sure? If I pass 0 as the 4th argument (event channel), the
command will return EINVAL. However, looking at the code you are not
checking the return for the call. So you will continue as if it were
successful.
So you will end up to write nodes for a domain Xenstored is not aware
and also set HVM_PARAM_STORE_PFN which may further confuse the guest as
it may try to initialize Xenstored it discovers the page.
I think that's because it is usually called on all domains by the
toolstack, even the ones without xenstore support in the kernel.
The toolstack will always allocate the event channel irrespective to
whether the guest will use Xenstore. So both the shared page and the
event channel are always valid today.
With your series, this will change as the event channel will not be
allocated when "xen,enhanced" is not set.
In your case, I think we may want to register the domain to xenstore but
say there are no connection available for the domain. Juergen, what do
you think?
Cheers,
--
Julien Grall
|
