From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:33676) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YTsWA-0007va-5W for qemu-devel@nongnu.org; Fri, 06 Mar 2015 08:42:19 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YTsW6-0006YJ-TZ for qemu-devel@nongnu.org; Fri, 06 Mar 2015 08:42:18 -0500 Received: from mx1.redhat.com ([209.132.183.28]:51976) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YTsW6-0006YC-Kv for qemu-devel@nongnu.org; Fri, 06 Mar 2015 08:42:14 -0500 From: Markus Armbruster References: <1425466773-8532-1-git-send-email-zhang.zhanghailiang@huawei.com> <874mq0u252.fsf@blackfin.pond.sub.org> Date: Fri, 06 Mar 2015 13:05:56 +0100 In-Reply-To: (Peter Maydell's message of "Fri, 6 Mar 2015 18:51:41 +0900") Message-ID: <87egp2jpp7.fsf@blackfin.pond.sub.org> MIME-Version: 1.0 Content-Type: text/plain 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: Peter Maydell Cc: zhanghailiang , QEMU Developers , Xiangyou Xie , "Huangpeng (Peter)" , "Gonglei (Arei)" , Paolo Bonzini Peter Maydell writes: > On 5 March 2015 at 02: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? > > 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.