Peter Maydell <peter.mayd...@linaro.org> writes:
> On 5 March 2015 at 02:02, Markus Armbruster <arm...@redhat.com> wrote:
>> zhanghailiang <zhang.zhanghaili...@huawei.com> writes:
>>
>>> From: Xiangyou Xie <xiexiang...@huawei.com>
>>>
>>> If VM is configured with large size of hugepage, when startup,
>>> it will consume lots of time to zero the hugepage memory in the function
>>> 'os_mem_prealloc'.
>>> Libvirtd will wait 30 seconds for qemu to establish the monitor,
>>> If the timeout triggers, libvirtd will send TERM signal to kill qemu.
>>>
>>> To solve the problem, adjust the processing of '-mon' to the ahead of
>>> '-object'.
>>>
>>> Signed-off-by: Xiangyou Xie <xiexiang...@huawei.com>
>>> Signed-off-by: zhanghailiang <zhang.zhanghaili...@huawei.com>
>>> ---
>>> vl.c | 8 ++++----
>>> 1 file changed, 4 insertions(+), 4 deletions(-)
>>>
>>> diff --git a/vl.c b/vl.c
>>> index 86bdce0..d0c03fe 100644
>>> --- a/vl.c
>>> +++ b/vl.c
>>> @@ -4000,6 +4000,10 @@ int main(int argc, char **argv, char **envp)
>>> exit(0);
>>> }
>>>
>>> + if (qemu_opts_foreach(qemu_find_opts("mon"), mon_init_func, NULL, 1)
>>> != 0) {
>>> + exit(1);
>>> + }
>>> +
>>> if (qemu_opts_foreach(qemu_find_opts("object"),
>>> object_create, NULL, 0) != 0) {
>>> exit(1);
>>> @@ -4154,10 +4158,6 @@ int main(int argc, char **argv, char **envp)
>>>
>>> parse_numa_opts();
>>>
>>> - if (qemu_opts_foreach(qemu_find_opts("mon"), mon_init_func, NULL, 1)
>>> != 0) {
>>> - exit(1);
>>> - }
>>> -
>>> if (foreach_device_config(DEV_SERIAL, serial_parse) < 0)
>>> exit(1);
>>> if (foreach_device_config(DEV_PARALLEL, parallel_parse) < 0)
>>
>>
>> Errors after monitor initialization look ugly when a monitor is on
>> stdio:
>>
>> $ qemu -nodefaults -monitor stdio -vga xxx
>> QEMU 2.2.50 monitor - type 'help' for more information
>> (qemu) Unknown vga type: xxx
>> $
>>
>> This patch initializes monitors earlier, thus makes more errors look
>> ugly. Do we care?
>
> Yeah, this doesn't seem great. Surely the actual problem here
> is that we're doing something that takes 30 seconds to initialise
> as part of our command line option parsing phase ?
Yep. Quoting myself:
Our startup is a big happy ad hoc mess. A more organizes [sic]
program would read and check configuration first (quick, can fail),
then allocate resources (quick, can fail), then initialize (somewhat
slow, failure unlikely).
Reorganizing everything to work like that is a huge task.
Until we get that (if ever!), all we can do is delay the most
egregiously slow initializations until after configuration checking and
monitor creation.
