This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


Re: [Xen-devel] Intel S3420GPLX VT-d VF question

On Wed, 22 Dec 2010 15:10:12 -0500, Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx> wrote:
On Mon, Dec 20, 2010 at 09:24:17PM -0500, Michael A. Collins wrote:
On Thu, 09 Dec 2010 22:18:45 -0500, "Michael A. Collins"
<mike@xxxxxxxxxxx> wrote:
>On Wed, 8 Dec 2010 12:50:35 -0500, Konrad Rzeszutek Wilk
><konrad.wilk@xxxxxxxxxx> wrote:
>>Take your time.
>Seems as the igb module was loaded in the initramfs and was not
>reloaded using the options specified in my igb.conf file under
>/etc/modprobe.d.  I rmmod igb and did a modprobe igb max_vfs=7 and
>suddenly all the Virtual Functions showed up.  So that was the
>all along. Until I figure out how to edit the initramfs to load igb
>with max_vfs option, I'm putting the rmmod and modprobe in the
>rc.local file, that seems to work well and it gets executed before
>xend.  I am build xen-4.0-testing to replace the rpms I used.  Once
>all that is done and I test passing through one of the Virtual
>Functions to a vm, I'll report back.

Ok, so I can pass one of the virtual functions through to a HVM.  I
think I'm still not out of the water though.  It's acting very
strangely and I have not successfully been able to very layer-2

And if you tried to use the device from dom0, or even baremetal, you
had not trouble with the VIFs, right?

connectivity with it.  I am seeing the following in my HVM's qemu
register_real_device: Assigning real physical device 04:10.4 ...
pt_dev_is_virtfn: 0000:04:10.4 is a SR-IOV Virtual Function
pt_iomul_init: Error: pt_iomul_init can't open file
/dev/xen/pci_iomul: No such file or directory: 0x4:0x10.0x4
pt_register_regions: IO region registered (size=0x00004000
pt_register_regions: IO region registered (size=0x00004000
pt_msix_init: get MSI-X table bar base b2468000
pt_msix_init: table_off = 0, total_entries = 3
pt_msix_init: errno = 2
That does not sound good, but it might be just b/c it could
not find /dev/xen/pci_iomul.

pt_msix_init: mapping physical MSI-X table to 7fe3c4359000
register_real_device: Real physical device 04:10.4 registered
IRQ type = INTx
generate a sci for PHP.
deassert due to disable GPE bit.
pt_pci_write_config: Warning: Guest attempt to set address to unused
Base Address Register. [00:06.0][Offset:30h][Length:4]
pt_iomem_map: e_phys=20000000 maddr=b2448000 type=0 len=16384
index=0 first_map=1
pt_iomem_map: e_phys=20004000 maddr=b2468000 type=0 len=16384
index=3 first_map=1

Now, I never see a pt_msi_setup: msi mapped with pirq XX line, which
leads me to believe that the pass through isn't actually working.  I
am still using the mayoung built xen-4.0.1-6 rpms from koji, since I
have not been able to successfully compile xen stubdom.  I guess gcc
4.5 is just too new and untested for me to troubleshoot and get
through.  Hopefully, someone on here can point me in the right

Hmm. I am bit out of ideas.. Do you know which line in the QEMU code
would trigger that? You could instrument QEMU a bit?

Yeah, the VIFs are fine in dom0. Also, I have seen reports of other people receiving the /dev/xen/pci_iomul and still getting past it. I will dig around in the QEMU code for awhile and see what I can come up with. Thanks.

Xen-devel mailing list

<Prev in Thread] Current Thread [Next in Thread>