[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

 


Rackspace

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