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

Re: [Xen-users] xm->xl migration in Xen 4.2.2



Hi Ian --

Adding  pci = [ '0000:07:11.6=0@1a' ] will have this effect which as you also pointed out that in the guest it will be function 0 (host function was 6)  :-

lspci -nn

00:00.0 Host bridge [0600]: Intel Corporation 440FX - 82441FX PMC [Natoma] [8086:1237] (rev 02)
00:01.0 ISA bridge [0601]: Intel Corporation 82371SB PIIX3 ISA [Natoma/Triton II] [8086:7000]
00:01.1 IDE interface [0101]: Intel Corporation 82371SB PIIX3 IDE [Natoma/Triton II] [8086:7010]
00:01.3 Bridge [0680]: Intel Corporation 82371AB/EB/MB PIIX4 ACPI [8086:7113] (rev 01)
00:02.0 VGA compatible controller [0300]: Cirrus Logic GD 5446 [1013:00b8]
00:03.0 Unknown class [ff80]: XenSource, Inc. Xen Platform Device [5853:0001] (rev 01)
00:1a.0 Ethernet controller [0200]: Intel Corporation 82559 Ethernet Controller Virtual Function [8086:10ed] (rev 01)


>IOW the =0@ specifies that the device should have function 0 inside the
>guest (where in your example it has fn 6 in the host). I think with the
>xl syntax you have the device will end up with function 6 instead of 0
>within the guest. Is that right?  

So that's exactly we don't want. Looks like 'xl' tool does not support specifying function in the guest?

However, even with xl, I see that output is similar:

00:00.0 Host bridge [0600]: Intel Corporation 440FX - 82441FX PMC [Natoma] [8086:1237] (rev 02)
00:01.0 ISA bridge [0601]: Intel Corporation 82371SB PIIX3 ISA [Natoma/Triton II] [8086:7000]
00:01.1 IDE interface [0101]: Intel Corporation 82371SB PIIX3 IDE [Natoma/Triton II] [8086:7010]
00:01.3 Bridge [0680]: Intel Corporation 82371AB/EB/MB PIIX4 ACPI [8086:7113] (rev 01)
00:02.0 VGA compatible controller [0300]: Cirrus Logic GD 5446 [1013:00b8]
00:03.0 Unknown class [ff80]: XenSource, Inc. Xen Platform Device [5853:0001] (rev 01)
00:1a.0 Ethernet controller [0200]: Intel Corporation 82559 Ethernet Controller Virtual Function [8086:10ed] (rev 01)


I'll send an email to xen-devel@ as you suggested.


Thanks,
/Saurabh

On Thu, Oct 31, 2013 at 9:08 AM, Ian Campbell <Ian.Campbell@xxxxxxxxxx> wrote:
On Mon, 2013-10-28 at 13:09 -0700, Saurabh Mishra wrote:
> Hi,
>
>
> One of the I noticed during migration from XM toolchain to XL in PCI
> Pass-through was that we used to specify target bdf in HVM guest as
>
>
> pci = [ '0000:07:11.6=0@1a' ]

What was the effect of this? I guess it passes through host device
0000:07:11.6 which appears as some device derived from "0@1a" in the
guest?

> However with XL, it now seems like this is the correct syntax:
>
>
> pci = [ '0000:07:11.6@1a' ]
>
>
> Is that correct? I've verified that it works but what about zero in
> '0@' that we used to specify in XM. Was it bus-id?

I've no idea -- this was part of the general problem with Xend ;-)

Where did you find this =0@1a syntax from? Perhaps that might give a
clue.

Trying to understand
tools/python/xen/util/pci.py:parse_pci_name_extended (which I think
might be parsing the above strings for xend) suggests that the syntax
is:

<domain>:<bus>:<slot>.<fn>=<fn'>@<vdevfn>

IOW the =0@ specifies that the device should have function 0 inside the
guest (where in your example it has fn 6 in the host). I think with the
xl syntax you have the device will end up with function 6 instead of 0
within the guest. Is that right?

If this is function remapping functionality which you need please can
you post to xen-devel@ explaining the usecase and the syntax you are
used to using the xend and the affect which it has on the PCI devices
which are seen by the guest (i.e. the lspci with xend and with xl).

Thanks,
Ian.



_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxx
http://lists.xen.org/xen-users

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.