Re: [Qemu-devel] Does PCI hotplug work with IVSHMEM?

[Ivano Cerrato]

Hi Marc-André, all,
even with 1G hugepages, we are not able to hotplug an ivshmem device.  
The outputs we get are the following:

* In qemu monitor:

      $info qtree

      ......
      dev: ivshmem, id ""
        chardev = <null>
        size = "2048M"
        vectors = 1
        ioeventfd = off
        msi = on
        shm = "fd"
        role = <null>
        use64 = 1
        addr = 04.0
        romfile = <null>
        rombar = 1
        multifunction = off
        command_serr_enable = on
        class RAM controller, addr 00:04.0, pci id 1af4:1110 (sub 
1af4:1100)
        bar 0: mem at 0xe0000000 [0xe00000ff]
        bar 2: mem at 0xffffffffffffffff [0x7ffffffe]

* In the guest:

        $sudo lshw
        ....
        *-memory UNCLAIMED
             description: RAM memory
             product: Virtio Inter-VM shared memory
             vendor: Red Hat, Inc
             physical id: 4
             bus info: address@hidden:00:04.0
             version: 00
             width: 64 bits
             clock: 33MHz (30.3ns)
             configuration: latency=0
             resources: memory:e0000000-e00000ff


        $dmesg
        ....
        [   18.365599] pci 0000:00:04.0: [1af4:1110] type 00 class 0x050000
        [   18.365657] pci 0000:00:04.0: reg 0x10: [mem 
0x00000000-0x000000ff]
        [   18.365746] pci 0000:00:04.0: reg 0x18: [mem 
0x00000000-0x7fffffff 64bit pref]
        [   18.366002] pci 0000:00:04.0: BAR 2: can't assign mem pref 
(size 0x80000000)
        [   18.366005] pci 0000:00:04.0: BAR 0: assigned [mem 
0xe0000000-0xe00000ff]
        [   18.366739] ACPI: Error installing CMOS-RTC region handler
        [   18.366876] pci 0000:00:00.0: no hotplug settings from platform
        [   18.366877] pci 0000:00:00.0: using default PCI settings
        [   18.366900] pci 0000:00:01.0: no hotplug settings from platform
        [   18.366901] pci 0000:00:01.0: using default PCI settings
        [   18.366923] ata_piix 0000:00:01.1: no hotplug settings from 
platform
        [   18.366924] ata_piix 0000:00:01.1: using default PCI settings
        [   18.366945] piix4_smbus 0000:00:01.3: no hotplug settings 
from platform
        [   18.366946] piix4_smbus 0000:00:01.3: using default PCI settings
        [   18.366967] cirrus 0000:00:02.0: no hotplug settings from 
platform
        [   18.366968] cirrus 0000:00:02.0: using default PCI settings
        [   18.366989] 8139cp 0000:00:03.0: no hotplug settings from 
platform
        [   18.366990] 8139cp 0000:00:03.0: using default PCI settings
        [   18.367011] pci 0000:00:04.0: no hotplug settings from platform
        [   18.367012] pci 0000:00:04.0: using default PCI settings


The host is running the Linux kernel 1.13.0-43-generic, while the guest 
runs the kernel 3.12.0-rc1 .
Instead, the QEMU version is the 1.6.2 with the patch for DPDK.

Any help would be really appreciated.

Thank you in advance,

    Ivano


Il 21/07/2015 18:37, Marc-André Lureau ha scritto:
> Hi
>
> On Tue, Jul 21, 2015 at 12:13 PM, Ivano Cerrato <address@hidden> wrote:
> > Is there any way to force the Guest OS to recognize the new device without
> > rebooting? Such as rmmod/insmod or equivalent?
> This can be observed in qemu monitor too, info qtree:
>
>        dev: ivshmem, id ""
>          chardev = ""
>          size = "2048M"
>          vectors = 1 (0x1)
>          ioeventfd = false
>          msi = true
>          shm = "foo"
>          role = ""
>          use64 = 1 (0x1)
>          addr = 05.0
>          romfile = ""
>          rombar = 1 (0x1)
>          multifunction = false
>          command_serr_enable = true
>          class RAM controller, addr 00:05.0, pci id 1af4:1110 (sub 1af4:1100)
>          bar 0: mem at 0x40000000 [0x400000ff]
>          bar 2: mem at 0xffffffffffffffff [0x7ffffffe]
>
> Check dmesg, it fails to allocate for me, but with 1G it works (f22
> x86_64). I don't know what's the reason behind it.
>
> Note that it's not safe to do hotplug with ivshmem (it may assert in
> various ways), I proposed a patch series a few weeks ago, I am going
> to send an updated version soon.