[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [PATCH v4 8/9] tools: add example application to initialize dom0less PV drivers
On Fri, 1 Apr 2022, Juergen Gross wrote: > On 01.04.22 12:21, Julien Grall wrote: > > Hi, > > > > I have posted some comments in v3 after you sent this version. Please have a > > look. > > > > On 01/04/2022 01:38, Stefano Stabellini wrote: > > > +static int init_domain(struct xs_handle *xsh, libxl_dominfo *info) > > > +{ > > > + struct xc_interface_core *xch; > > > + libxl_uuid uuid; > > > + uint64_t xenstore_evtchn, xenstore_pfn; > > > + int rc; > > > + > > > + printf("Init dom0less domain: %u\n", info->domid); > > > + xch = xc_interface_open(0, 0, 0); > > > + > > > + rc = xc_hvm_param_get(xch, info->domid, HVM_PARAM_STORE_EVTCHN, > > > + &xenstore_evtchn); > > > + if (rc != 0) { > > > + printf("Failed to get HVM_PARAM_STORE_EVTCHN\n"); > > > + return 1; > > > + } > > > + > > > + /* Alloc xenstore page */ > > > + if (alloc_xs_page(xch, info, &xenstore_pfn) != 0) { > > > + printf("Error on alloc magic pages\n"); > > > + return 1; > > > + } > > > + > > > + rc = xc_dom_gnttab_seed(xch, info->domid, true, > > > + (xen_pfn_t)-1, xenstore_pfn, 0, 0); > > > + if (rc) > > > + err(1, "xc_dom_gnttab_seed"); > > > + > > > + libxl_uuid_generate(&uuid); > > > + xc_domain_sethandle(xch, info->domid, libxl_uuid_bytearray(&uuid)); > > > + > > > + rc = gen_stub_json_config(info->domid, &uuid); > > > + if (rc) > > > + err(1, "gen_stub_json_config"); > > > + > > > + /* Now everything is ready: set HVM_PARAM_STORE_PFN */ > > > + rc = xc_hvm_param_set(xch, info->domid, HVM_PARAM_STORE_PFN, > > > + xenstore_pfn); > > > > On patch #1, you told me you didn't want to allocate the page in Xen because > > it wouldn't be initialized by Xenstored. But this is what we are doing here. > > Xenstore (at least the C variant) is only using the fixed grant ref > GNTTAB_RESERVED_XENSTORE, so it doesn't need the page to be advertised > to the guest. And the mapping is done only when the domain is being > introduced to Xenstore. > > > > > This would be a problem if Linux is still booting and hasn't yet call > > xenbus_probe_initcall(). > > > > I understand we need to have the page setup before raising the event > > channel. I don't think we can allow Xenstored to set the HVM_PARAM (it may > > run in a domain with less privilege). So I think we may need to create a > > separate command to kick the client (not great). > > > > Juergen, any thoughts? > > I think it should work like that: > > - setup the grant via xc_dom_gnttab_seed() > - introduce the domain to Xenstore > - call xc_hvm_param_set() > > When the guest is receiving the event, it should wait for the xenstore > page to appear. I am OK with what you wrote above, and I understand Julien's concerns about "waiting". Before discussing that, I would like to make sure I understood why setting HVM_PARAM_STORE_PFN first (before xs_introduce_domain) is not possible. In a previous reply to Julien I wrote that it is not a good idea to set HVM_PARAM_STORE_PFN in Xen before creating the domains because it would cause Linux to hang at boot. That is true, Linux hangs on drivers/xen/xenbus/xenbus_comms.c:xb_init_comms waiting on xb_waitq. It could wait a very long time as domUs are typically a lot faster than dom0 to boot. However, if we set HVM_PARAM_STORE_PFN before calling xs_introduce_domain in init-dom0less, for Linux to see it before xs_introduce_domain is done, Linux would need to be racing against init-dom0less. In that case, the wait in xb_init_comms would be minimal anyway. It shouldn't be a problem. There would be no "hang", just a wait a bit longer than usual. Is that right?
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |