From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:44141) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QOuJY-0004DF-UY for qemu-devel@nongnu.org; Tue, 24 May 2011 12:18:37 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QOuJX-0008Qa-Oz for qemu-devel@nongnu.org; Tue, 24 May 2011 12:18:36 -0400 Received: from thoth.sbs.de ([192.35.17.2]:33380) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QOuJX-0008QU-E1 for qemu-devel@nongnu.org; Tue, 24 May 2011 12:18:35 -0400 Message-ID: <4DDBDA51.7010104@siemens.com> Date: Tue, 24 May 2011 18:18:25 +0200 From: Jan Kiszka MIME-Version: 1.0 References: <4DD64E1F.8020603@siemens.com> <4DD8ECB0.9050803@web.de> <1306253200.20576.186.camel@zakaz.uk.xensource.com> In-Reply-To: <1306253200.20576.186.camel@zakaz.uk.xensource.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH v2 1/2] Generalize -machine command line option List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Ian Campbell Cc: Anthony PERARD , Anthony Liguori , qemu-devel On 2011-05-24 18:06, Ian Campbell wrote: > On Sun, 2011-05-22 at 13:00 +0200, Jan Kiszka wrote: >> From: Jan Kiszka >> >> -machine somehow suggests that it selects the machine, but it doesn't. >> Fix that before this command is set in stone. >> >> Actually, -machine should supersede -M and allow to introduce arbitrary >> per-machine options to the command line. That will change the internal >> realization again, but we will be able to keep the user interface >> stable. >> >> CC: Anthony PERARD >> Signed-off-by: Jan Kiszka > > "-machine xenfv" doesn't work for me with this patch, it gives: > Program received signal SIGSEGV, Segmentation fault. > hypercall_buffer_cache_lock (xch=0x0) at xc_hcall_buf.c:36 > 36 xc_hcall_buf.c: No such file or directory. > in xc_hcall_buf.c > (gdb) bt > #0 hypercall_buffer_cache_lock (xch=0x0) at xc_hcall_buf.c:36 > #1 0xb7d53f1d in hypercall_buffer_cache_alloc (xch=0x0, b=0xbffff77c, nr_pages=1) at xc_hcall_buf.c:52 > #2 xc__hypercall_buffer_alloc_pages (xch=0x0, b=0xbffff77c, nr_pages=1) at xc_hcall_buf.c:128 > #3 0xb7d54028 in xc__hypercall_buffer_alloc (xch=0x0, b=0xbffff77c, size=16) at xc_hcall_buf.c:162 > #4 0xb7d42719 in xc_get_hvm_param (handle=0x0, dom=248, param=5, value=0xbffff810) at xc_domain.c:1078 > #5 0x08252777 in xen_hvm_init () at /home/ianc/devel/qemu.git/xen-all.c:803 > #6 0x082921e9 in pc_xen_hvm_init (ram_size=536870912, boot_device=0xbffffabb "cda", kernel_filename=0x0, kernel_cmdline=0x82d648f "", initrd_filename=0x0, cpu_model=0x0) at /home/ianc/devel/qemu.git/hw/pc_piix.c:246 > #7 0x081e3f0e in main (argc=26, argv=0xbffffba4, envp=0xbffffc10) at /home/ianc/devel/qemu.git/vl.c:3162 > > I suspect this is because xen_init() (which sets xch) is never called, > perhaps because it causes the accelerator to always be tcg? If I use > "-machine xenfv,accel=xen" then it works as expected, -M continues to > work too AFAICT. > > It would be nice to retain the behaviour of defaulting to accel=xen for > machine=xenfv. (to be honest I can't quite see where this behaviour came > from, nor what about this patch changes it...) Well, first of all I think this revealed a Xen bug because it crashes when you try to run xenfv with an inappropriate accelerator, no? What is the result of -machine xenfv,accel=tcg or, without my patch, -M xenfv -machine accel=tcg? Then the question is what accel options are actually picked with -machine xenfv, or why the default options are maybe not considered. I don't have any Xen around, but I will check how far I can debug this - or actually try to understand what I coded if nothing helps. Thanks for testing! Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux