[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH for-4.12 4/8] x86/shadow: alloc enough pages so initialization doesn't fail
>>> On 06.02.19 at 10:10, <roger.pau@xxxxxxxxxx> wrote: > On Tue, Feb 05, 2019 at 10:32:08AM -0700, Jan Beulich wrote: >> >>> On 05.02.19 at 16:53, <roger.pau@xxxxxxxxxx> wrote: >> > On Tue, Feb 05, 2019 at 08:15:27AM -0700, Jan Beulich wrote: >> >> >>> On 05.02.19 at 14:52, <roger.pau@xxxxxxxxxx> wrote: >> >> > I don't think the amount of guest memory matters here, the following >> >> > example with 8G of RAM and 8 vCPUs fails in the same way: >> >> > >> >> > # cat test.c >> >> > test.c test.c.gcov test.cfg test.core >> >> > root@:~ # cat test.cfg >> >> > name = "test" >> >> > type = "hvm" >> >> > >> >> > memory = 8192 >> >> > vcpus = 8 >> >> > hap = 0 >> >> > # xl create test.cfg >> >> > Parsing config from test.cfg >> >> > libxl: error: libxl_create.c:578:libxl__domain_make: domain creation >> >> > fail: > >> >> > Cannot allocate memory >> >> > libxl: error: libxl_create.c:975:initiate_domain_create: cannot make > domain: >> >> > -3 >> >> > >> >> > And I think that's a perfectly suitable guest config. >> >> >> >> Indeed. And it doesn't seem to work for me anymore either. Must be >> >> a regression, as I'm pretty sure it did still work not all that long ago. >> >> Not even "shadow_memory=256" helps. >> > >> > No, because shadow_init is called from domain_create, and it's >> > impossible to increase the shadow memory pool before the domain is >> > actually created. >> >> Okay, I misunderstood the problem initially. Aiui this is a >> regression from the early setting of ->max_vcpus, as that now > > Ahh, I wasn't able to figure out what caused this regression, it's > indeed caused by max_vcpus being set at domain_create. > >> causes shadow_min_acceptable_pages() to block far more pages >> than it did before from use for p2m allocs during domain creation. >> I think I see an alternative way of fixing this for the moment >> (without adding re-size logic yet when d->tot_pages grows), but >> this will have to wait until tomorrow. > > Ack, I'm happy to implement it if you tell me the plan :). Well, the plan was hard to spell out without actually trying out what is needed. You'll likely have seen already the resulting patch I've sent out for discussion. > Maybe as an alternative the checks in shadow_alloc_p2m_page can be > relaxed during domain creation, I've been considering this, but decided against it, because it would undermine the functionality in case the tool stack would not issue a set-allocation domctl. Mid-term (perhaps after 4.12) I think we need to settle on a more uniform model here, e.g. either always requiring a set-allocation request by the tool stack, or making the code not depend on it at all. > or the p2m allocated when the first memory page gets added to the domain? This might be possible as well, but perhaps requires a more intrusive change, in particular if you take into consideration the VMX change which was a byproduct of the playing done for this one. Jan _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxxx https://lists.xenproject.org/mailman/listinfo/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |