Xen project Mailing List

Hi Ian --

Thanks. Yes -- it's possible to assign multiple function in one pci line.

Is 'xl' being actively supported by Xen development community? and 'xm' will not supported at all in Xen 4.2.2+?

SuSE SP3 pack has Xen 4.2.2

Thanks

/Saurabh

On Tue, Nov 5, 2013 at 2:20 AM, Ian Campbell <Ian.Campbell@xxxxxxxxxx> wrote:

graft 22 ^
thanks

On Mon, 2013-11-04 at 10:29 -0800, Saurabh Mishra wrote:
> >FYI qemu-upstream xen passhthrough currently also doesn't support specifying a request
> > for a certain dev/function nr.

> But it seems to work in XM toolchain.

xm only supports the historical qemu-xen-traditional fork of qemu, not
the more modern qemu-xen ("upstream") stuff. xl supports both.

> For example :-

> pci = [ '0000:08:00.1=0,2=1,3=2,4=3@0a' ]

Oh wow, so it is possible to assign multiple functions in one go?
(lib)xl certainly doesn't know how to do that!

> ironpass3:~/sles11_sp2_gm # xm pci-list-assignable-devices
> 0000:08:00.1
> 0000:08:00.2
> 0000:08:00.3
> 0000:08:00.4

> ironpass3:~/sles11_sp2_gm # xm create sles11_sp2_gm.xenconfig
> Using config file "./sles11_sp2_gm.xenconfig".
> Started domain sles11_sp2_gm (id=5)

> ironpass3:~/sles11_sp2_gm # grep pci sles11_sp2_gm.xenconfig
> #pci = [ '0000:08:00.1=0@0a', '0000:08:00.2=0@0b', '0000:08:00.3=0@0c', '0000:08:00.4=0@0d' ]
> pci = [ '0000:08:00.1=0,2=1,3=2,4=3@0a' ]
> xen_platform_pci=0

> ironpass3:~/sles11_sp2_gm # lspci -nn -s 08:00
> 08:00.0 Co-processor [0b40]: Intel Corporation Device [8086:0434] (rev 10)
> 08:00.1 Ethernet controller [0200]: Intel Corporation DH8900CC Series Gigabit Network Connection [8086:0438] (rev 10)
> 08:00.2 Ethernet controller [0200]: Intel Corporation DH8900CC Series Gigabit Network Connection [8086:0438] (rev 10)
> 08:00.3 Ethernet controller [0200]: Intel Corporation DH8900CC Series Gigabit Network Connection [8086:0438] (rev 10)
> 08:00.4 Ethernet controller [0200]: Intel Corporation DH8900CC Series Gigabit Network Connection [8086:0438] (rev 10)
> 08:00.5 Co-processor [0b40]: Intel Corporation Device [8086:043e] (rev 10)
>
> ironpass3:~/sles11_sp2_gm # xm console sles11_sp2_gm
> linux-34o4:~ # 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:0a.0 Ethernet controller [0200]: Intel Corporation DH8900CC Series Gigabit Network Connection [8086:0438] (rev 10)
> 00:0a.1 Ethernet controller [0200]: Intel Corporation DH8900CC Series Gigabit Network Connection [8086:0438] (rev 10)
> 00:0a.2 Ethernet controller [0200]: Intel Corporation DH8900CC Series Gigabit Network Connection [8086:0438] (rev 10)
> 00:0a.3 Ethernet controller [0200]: Intel Corporation DH8900CC Series Gigabit Network Connection [8086:0438] (rev 10)

> >Do you happen to know (or can you easily do the experiment to find out)
> >what happens with '0000:07:11.6@1a' on xm? Does the guest see function 0
> >or function 6? If it is 0 then I think we can safely say xl will not
> >change, but if it is 6 we'll have to have a think...

> Each PCI- device have to have function 0. So in the above case it gets 0.

OK, so if xm treats 0000:07:11.6@1a as creating 00:1a.0 in the guest
then I think we can safely say that xl will not change in this regard.

> However, we may specify '0000:07:11.6=0@1a' and ''0000:07:11.8=1@1a'
> and XM does handle it as expected.

> However, xl does not allow us to specify device function in the guest.
> Is there a way specifying virtual function slot can become a
> parameter?

Not currently.

> After all, xm cfg file is supposed to be 100% compatible with 'xl'.

Right. This is a bug in xl IMHO. The reason I was asking about the XM
behaviour without was to determine the exact nature of what xl should be
doing.

I instantiated this issue as http://bugs.xenproject.org/xen/bug/22 in my
initial reply. It looks like you broke threading with your reply. The
control statement at the top of this mail ought to fix that up so that
this subthread is also recorded in the bug.

We would be happy to receive patches to fix this stuff up if you feel
able, I'm more than happy to mentor if need be.

> In Xen 4.2.2_06 version, is 'xl' preferred way to instantiate VMs? We
> currently use 'xm' but wanted to move to 'xl' because it has better
> support for NUMA alignment and memory backing.

xl became the default in 4.3 IIRC, although in reality xm has been
unmaintained for quite a while before this.

Ian.

Re: [Xen-devel] xl does not support specifying virtual function for passthrough device