qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [Crucial bug] Qemu-2.0.0 do not support virtio-net hot


From: Andreas Färber
Subject: Re: [Qemu-devel] [Crucial bug] Qemu-2.0.0 do not support virtio-net hot plug/unplug exceed two times
Date: Tue, 06 May 2014 17:02:09 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0

Hi,

Am 06.05.2014 16:08, schrieb Gonglei (Arei):
>> -----Original Message-----
>> From: Andreas Färber [mailto:address@hidden
>> Sent: Tuesday, May 06, 2014 9:58 PM
>> To: Gonglei (Arei)
>> Cc: Markus Armbruster; Hani Benhabiles; Peter Maydell; Paolo Bonzini;
>> Michael S. Tsirkin; address@hidden
>> Subject: Re: [Qemu-devel] [Crucial bug] Qemu-2.0.0 do not support virtio-net
>> hot plug/unplug exceed two times
>>
>> Am 06.05.2014 15:41, schrieb Gonglei (Arei):
>>>>
>>>> Am 06.05.2014 14:52, schrieb Gonglei (Arei):
>>>>> Step 1: I executed "device_add virtio-net-pci,id=net1"
>>>>> with "info pci", I found the net1, showing as below:
>>>>> Bus  0, device   4, function 0:
>>>>>     Ethernet controller: PCI device 1af4:1000
>>>>>       IRQ 0.
>>>>>       BAR0: I/O at 0xffffffffffffffff [0x001e].
>>>>>       BAR1: 32 bit memory at 0xffffffffffffffff [0x00000ffe].
>>>>>       BAR6: 32 bit memory at 0xffffffffffffffff [0x0003fffe].
>>>>>       id "net1"
>>>>> Step 2: I executed " device_del net1", but the net1 still existed.
>>>>>
>>>>>> In QMP, you get a DEVICE_DELETED event when the unplug completes.
>>>> See
>>>>>> qmp/qmp-events.txt.
>>>>> Actually, I don't get the event, as the net1 can't be unplug.
>>>>>
>>>>> BTW, when I execute step 1 "device_add virtio-net-pci,id=net1", I don't 
>>>>> find
>>>> the
>>>>> Ethernet controller of virtio-net by "lspci " in the guest OS.
>>>>> TBH, the command execution failed despite we can see net1 with "info
>> pci".
>>>>
>>>> Sounds like the acpiphp kernel module is not loaded inside the guest?
>>>>
>>> OMG, thank you so much. Good catch.
>>
>> In that case check your /etc/modprobe.conf file in the SLES guest. From
>> at least SLES 11 SP2 on you should have an entry like this (here SP3):
>>
>> alias dmi:bvnQEMU:bvrQEMU:* acpiphp
>>
>> The exact values changed between SeaBIOS versions at some point.
>>
> Yes, I find the entry in /etc/modprobe.conf file. But I don't understand it:
> 
> # QEMU/KVM can handle ACPI Hotplugging
> alias dmi:bvnQEMU:bvrQEMU:* acpiphp
> 
> Why not the SLSE OS auto load the acpiphp module when it's booting?

This entry is what's supposed to trigger the auto-load on our KVM. :)

Like I said above, it depends on the (Sea)BIOS, and you can verify your
values by running

udevadm monitor --property

and while it's monitoring, running

udevadm trigger

On a recent QEMU I then see

KERNEL[761.415335] change   /devices/virtual/dmi/id (dmi)
ACTION=change
DEVPATH=/devices/virtual/dmi/id
MODALIAS=dmi:bvnBochs:bvrBochs;bd01/01/2011:svnQEMU:pnStandardPC(i440FX+PIIX,1996):pvrpc-i440fx-2.0:cvnBochs:ct1:cvr:
SEQNUM=2896
SUBSYSTEM=dmi

So with the SeaBIOS blob from qemu.git,

alias dmi:bvnBochs:bvrBochs:* acpiphp

would be needed. Once you add it to modprobe.conf I would expect the
next `udevadm trigger` (or reboot) to auto-load the module again.

SLES 12 has the module built-in and thus no longer depends on this
mechanism for auto-loading it.

Best regards,
Andreas

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