> Subject: Re: pci-stub error and MSI-X for KVM guest
>
> * Fischer, Anna (anna.fischer@xxxxxx) wrote:
> > > Subject: Re: pci-stub error and MSI-X for KVM guest
> > > > This works fine in principle and I can see the PCI device in the
> > > > guest under lspci. However, the 82576 VF driver requires the OS
> > > > to support MSI-X. My Fedora installation is configured with MSI-X,
> > > > e.g. CONFIG_PCI_MSI is 'y'. When I load the driver it tells me it
> > > cannot
> > > > initialize MSI-X for the device, and under /proc/interrupts I can
> see
> > > > that MSI-X does not seem to work. Is this a KVM/QEMU limitation?
> It
> > > works
> > > > for me when running the VF driver under a non-virtualized Linux
> system.
> > >
> > > No, this should work fine. QEMU/KVM supports MSI-X to guest as well
> as
> > > VFs.
> >
> > Actually, I just got this to work. However, it only works if I call
> > qemu-kvm from the command line, while it doesn't work when I start
> > the guest via the virt-manager. So this seems to be an issue with
> > Fedora's virt-manager rather than with KVM/QEMU. If I call qemu-kvm
> > from the command line then I get the pci-stub messages saying 'irq xx
> > for MSI/MSI-x' when the guest boots up and the VF device works just
> fine
> > inside the guest. When I start the guest using virt-manager then I
> don't
> > see any of these irq allocation messages from pci-stub. Any idea what
> > the problem could be here?
>
> No, sounds odd. Can you:
>
> # virsh dumpxml [domain]
>
> and show the output of the hostdev XML section?
<hostdev mode='subsystem' type='pci' managed='yes'>
<source>
<address domain='0x0000' bus='0x03' slot='0x10' function='0x3'/>
</source>
</hostdev>
The device to assign is at 0000:03:10.3, dmesg shows:
pci-stub 0000:03:10.3: enabling device (0000 -> 0002)
assign device: host bdf = 3:10:3
> > > > Also, when I do an lspci on the KVM guest, that is fine, but when
> I
> > > > do an lspci -v then the guest crashes down. In the host OS under
> dmesg
> > > > I can see this:
> > > >
> > > > pci-stub 0000:03:10.0: restoring config space at offset 0x1 (was
> > > 0x100000, writing 0x100004)
> > > >
> > > > Is this a known issue? My qemu-kvm version is 2:0.11.0.
> > >
> > > No, I've not seen the crash before. What do you mean "the guest
> crashes
> > > down"?
> >
> > So this also only happens when starting the guest using virt-manager.
> It
> > works fine when starting qemu-kvm from the command line. This is weird
> as
> > I call it with the same parameters as I can see virt-manager uses
> under
> > 'ps -ef | grep qemu'. The guest crashes down means that the QEMU
> process
> > is terminated. I don't see anything in the logs. It just disappears.
>
> Ouch. Can you do "debuginfo-install qemu-system-x86" to get the debug
> packages, then attach gdb to the QEMU process so that when you do lspci
> -v
> in the guest (assuming this is QEMU segfaulting) you'll get a backtrace?
I don't know how I can tell virt-manager through the GUI to enable debug mode, e.g. call virt-manager with '-s'. From the command line I can attach gdb like this, but when running virt-manager from the GUI then I cannot connect to localhost:1234. However, the issues only arise when starting virt-manager from the GUI. I can't find the configuration option to somehow tell that I want it to be launched with '-s'?
> > > This looks like a Fedora specific version (rpm version). Can you
> verify
> > > this is from Fedora packages vs. upstream source? If it's Fedora,
> > > would be useful to open a bug there.
> >
> > Yes, I am using KVM/QEMU which ships with the Fedora Core 12
> distribution.
>
> OK, please file a bug there (and include the backtrace info).
I will file a bug once I get the full information. Currently my guess is actually that I might have package mismatches or so with libvirt or virt-manager or QEMU related software. The is my only explanation for why it works from the command line, but not from the GUI. Some path variables must be set differently and perhaps pointing to different libraries or packages or so, otherwise there is no way it can behave differently when calling virt-manager with exactly the same parameters...
Cheers,
Anna
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
