From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:37533) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UUHdr-0001Ow-T8 for qemu-devel@nongnu.org; Mon, 22 Apr 2013 10:22:54 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UUHdq-00014O-J7 for qemu-devel@nongnu.org; Mon, 22 Apr 2013 10:22:51 -0400 Received: from cantor2.suse.de ([195.135.220.15]:60258 helo=mx2.suse.de) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UUHdq-00014A-98 for qemu-devel@nongnu.org; Mon, 22 Apr 2013 10:22:50 -0400 Message-ID: <517547B7.3020300@suse.de> Date: Mon, 22 Apr 2013 16:22:47 +0200 From: =?ISO-8859-1?Q?Andreas_F=E4rber?= MIME-Version: 1.0 References: <1366077021-28882-1-git-send-email-afaerber@suse.de> <20130418104156.7a5349f0@nial.usersys.redhat.com> <20130418110151.316c17b6@nial.usersys.redhat.com> <5D9ACBBCF6B270468D615C4719A59BE33A469646@szxeml548-mbx.china.huawei.com> <51753ADA.5010504@suse.de> <51754130.9080507@greensocs.com> <517542F2.6080407@suse.de> <5175461E.9040008@greensocs.com> In-Reply-To: <5175461E.9040008@greensocs.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PATCH] qdev: Fix device_add bus assumptions List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: =?ISO-8859-1?Q?KONRAD_Fr=E9d=E9ric?= Cc: Libaiqing , "ehabkost@redhat.com" , Haofeng , "qemu-devel@nongnu.org" , "armbru@redhat.com" , "anthony@codemonkey.ws" , Igor Mammedov , "pbonzini@redhat.com" , "lcapitulino@redhat.com" Am 22.04.2013 16:15, schrieb KONRAD Fr=E9d=E9ric: > On 22/04/2013 16:02, Andreas F=E4rber wrote: >> Hi Fred, >> >> Am 22.04.2013 15:54, schrieb KONRAD Fr=E9d=E9ric: >>> On 22/04/2013 15:27, Andreas F=E4rber wrote: >>>> Am 22.04.2013 13:51, schrieb Libaiqing: >>>>> When I use the config below,an error occurs.Is there anything >>>>> wrong? >>>>> >>>>> Qemu-kvm -enable-kvm -name win7 -M pc-0.15 -m 1024 -smp 2 -boot= c >>>>> -device virtio-serial-pci,id=3Dvirtio-serial0,bus=3Dpci.0,addr=3D0x= 4 >>>>> -chardev spicevmc,id=3Dcharchannel0,name=3Dvdagent -device >>>>> virtserialport,bus=3Dvirtio-serial0.0,chardev=3Dcharchannel0,id=3Dc= hannel0,name=3Dcom.redhat.spice.0 >>>>> >>>>> -drive file=3D/home/img/win7.qed,if=3Dvirtio,index=3D0,format=3Dqed= -monitor >>>>> stdio -vga qxl -vnc :1 >>>>> >>>>> Error output: >>>>> -device >>>>> virtserialport,bus=3Dvirtio-serial0.0,chardev=3Dcharchannel0,id=3Dc= hannel0,name=3Dcom.redhat.spice.0: >>>>> >>>>> Bus 'virtio-serial0.0' is full >>>>> -device >>>>> virtserialport,bus=3Dvirtio-serial0.0,chardev=3Dcharchannel0,id=3Dc= hannel0,name=3Dcom.redhat.spice.0: >>>>> >>>>> Bus 'virtio-serial0.0' not found >>>>> >>>>> Any feedback are appliciated. >>>> This does not sound related to this patch at all... >>>> >>>> Instead it sounds as if the virtio refactorings had some effect not >>>> only >>>> on virtio-net but also on virtio-serial. Fred? >>> Yes, sounds like the same issue as virtio-net: >>> >>> bus: pci.0 >>> type PCI >>> dev: virtio-serial-pci, id "virtio-serial0" >>> ioeventfd =3D off >>> vectors =3D 2 >>> class =3D 0x780 >>> indirect_desc =3D on >>> event_idx =3D on >>> max_ports =3D 31 >>> addr =3D 04.0 >>> romfile =3D >>> rombar =3D 1 >>> multifunction =3D off >>> command_serr_enable =3D on >>> class Class 0780, addr 00:04.0, pci id 1af4:1003 (sub >>> 1af4:0003) >>> bar 0: i/o at 0xc040 [0xc05f] >>> bar 1: mem at 0xfebf1000 [0xfebf1fff] >>> bus: virtio-serial0.0 >>> type virtio-pci-bus >>> dev: virtio-serial-device, id "" >>> max_ports =3D 31 >>> bus: virtio-serial-bus.0 >>> type virtio-serial-bus >>> >>> The autogenerated bus name "deviceid.n" (virtio-serial0.0) became a >>> virtio-bus... >>> >>> virtio-serial-bus.0 is the right bus to connect virtserialport. >>> >>> Any idea how to fix that? >> The only idea I can come up with right now is to overwrite the bus nam= e >> on realize/qdev-init of the containing (virtio-serial-pci) device. >> >> Whether we want that is another question... :) It would fix command li= ne >> backwards compatibility but would be inconsistent then; I guess the >> former is more important here. >> >> Regards, >> Andreas > I'm not sure that only overwriting the bus name will fix the issue. >=20 > virtio-serial-device's bus still won't have the right name? I was talking of virtio-serial-pci overwriting virtio-serial-device's bus with its own id.0 after it's been created by virtio-serial-device with NULL argument! Assuming it gets created in instance_init and can't just access its parent's id in its own realize function to have it correct from the start. Andreas > Here with the command line, we expect virtio-serial-pci,id=3Did0 to cre= ate > a virtio-serial-bus called id0.0 is that right? >=20 > Thanks, > Fred --=20 SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 N=FCrnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imend=F6rffer; HRB 16746 AG N=FCrnbe= rg