From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:57932) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YTo5a-0008Ez-Tf for qemu-devel@nongnu.org; Fri, 06 Mar 2015 03:58:39 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YTo5V-000260-U3 for qemu-devel@nongnu.org; Fri, 06 Mar 2015 03:58:34 -0500 Received: from szxga03-in.huawei.com ([119.145.14.66]:31471) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YTo5V-00025i-4w for qemu-devel@nongnu.org; Fri, 06 Mar 2015 03:58:29 -0500 Message-ID: <54F96C20.1010108@huawei.com> Date: Fri, 6 Mar 2015 16:58:08 +0800 From: zhanghailiang MIME-Version: 1.0 References: <1425466773-8532-1-git-send-email-zhang.zhanghailiang@huawei.com> <874mq0u252.fsf@blackfin.pond.sub.org> In-Reply-To: <874mq0u252.fsf@blackfin.pond.sub.org> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH] vl: Adjust the place of processing '-mon' List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Markus Armbruster Cc: hangaohuai@huawei.com, peter.huangpeng@huawei.com, Xiangyou Xie , qemu-devel@nongnu.org, arei.gonglei@huawei.com, pbonzini@redhat.com On 2015/3/5 1:02, Markus Armbruster wrote: > zhanghailiang writes: > >> From: Xiangyou Xie >> >> 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 >> Signed-off-by: zhanghailiang >> --- >> 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? > Hmm, i don't think it will make any difference, no matter monitor or stdio, it is all OK, it is just error reports, let people know what's wrong. > If not: should we initialize them even earlier? They depend on > character devices, so what about right after loop calling > chardev_init_func()? > This is reasonable, will fix it like that in v2, thanks. > Our startup is a big happy ad hoc mess. A more organizes program would Yes, maybe some cleanup work should be done. > read and check configuration first (quick, can fail), then allocate > resources (quick, can fail), then initialize (somewhat slow, failure > unlikely). > > . >