qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH] qdev: Fix device_add bus assumptions


From: Andreas Färber
Subject: Re: [Qemu-devel] [PATCH] qdev: Fix device_add bus assumptions
Date: Mon, 22 Apr 2013 16:22:47 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130329 Thunderbird/17.0.5

Am 22.04.2013 16:15, schrieb KONRAD Frédéric:
> On 22/04/2013 16:02, Andreas Färber wrote:
>> Hi Fred,
>>
>> Am 22.04.2013 15:54, schrieb KONRAD Frédéric:
>>> On 22/04/2013 15:27, Andreas Färber 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=virtio-serial0,bus=pci.0,addr=0x4
>>>>> -chardev spicevmc,id=charchannel0,name=vdagent -device
>>>>> virtserialport,bus=virtio-serial0.0,chardev=charchannel0,id=channel0,name=com.redhat.spice.0
>>>>>
>>>>> -drive file=/home/img/win7.qed,if=virtio,index=0,format=qed  -monitor
>>>>> stdio   -vga qxl  -vnc :1
>>>>>
>>>>> Error output:
>>>>>       -device
>>>>> virtserialport,bus=virtio-serial0.0,chardev=charchannel0,id=channel0,name=com.redhat.spice.0:
>>>>>
>>>>> Bus 'virtio-serial0.0' is full
>>>>>       -device
>>>>> virtserialport,bus=virtio-serial0.0,chardev=charchannel0,id=channel0,name=com.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 = off
>>>          vectors = 2
>>>          class = 0x780
>>>          indirect_desc = on
>>>          event_idx = on
>>>          max_ports = 31
>>>          addr = 04.0
>>>          romfile = <null>
>>>          rombar = 1
>>>          multifunction = off
>>>          command_serr_enable = 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 = 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 name
>> on realize/qdev-init of the containing (virtio-serial-pci) device.
>>
>> Whether we want that is another question... :) It would fix command line
>> 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.
> 
> 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=id0 to create
> a virtio-serial-bus called id0.0 is that right?
> 
> Thanks,
> Fred

-- 
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg



reply via email to

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