qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH v2 1/2] Generalize -machine command line option


From: Ian Campbell
Subject: Re: [Qemu-devel] [PATCH v2 1/2] Generalize -machine command line option
Date: Wed, 25 May 2011 09:13:34 +0100

On Tue, 2011-05-24 at 18:18 +0200, Jan Kiszka wrote:
> On 2011-05-24 18:06, Ian Campbell wrote:
> > On Sun, 2011-05-22 at 13:00 +0200, Jan Kiszka wrote:
> >> From: Jan Kiszka <address@hidden>
> >>
> >> -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 <address@hidden>
> >> Signed-off-by: Jan Kiszka <address@hidden>
> > 
> > "-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?

Unsurprisingly it crashed...

I'm not sure if this is a bug in the xen side of simply a case of
providing enough rope. I didn't really follow the threads which resulted
in the accel stuff all that closely so I'm not sure what the intention
was, it seems to me that the accel option is invalid with certain
machine types though.

I suppose in theory -machine xenpv,accel=kvm might result in xenner or
something, accel=xenpv,tcg I'm less sure about (perhaps xenner too?).
For -machine xenfv I don't expect anything other than accel=xen makes
much sense.

> 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.

I saw a follow up patch -- I'll give it a go.

> 
> Thanks for testing!
> Jan
> 

-- 
Ian Campbell
Current Noise: Blind Melon - Soak The Sin

Anti-trust laws should be approached with exactly that attitude.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]