From xen-devel-bounces@lists.xen.org Wed Nov 06 10:03:36 2013 Received: (at maildrop) by bugs.xenproject.org; 6 Nov 2013 10:03:36 +0000 Received: from lists.xen.org ([50.57.142.19]) by bugs.xenproject.org with esmtp (Exim 4.80) (envelope-from ) id 1VdzxY-0007QQ-Mk for xen-devel-maildrop-Eithu9ie@bugs.xenproject.org; Wed, 06 Nov 2013 10:03:36 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Vdztq-00055f-RK; Wed, 06 Nov 2013 09:59:46 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Vdqd3-0003tH-OQ for xen-devel@lists.xen.org; Wed, 06 Nov 2013 00:05:50 +0000 Received: from [193.109.254.147:12251] by server-7.bemta-14.messagelabs.com id B0/5B-14870-DD789725; Wed, 06 Nov 2013 00:05:49 +0000 X-Env-Sender: saurabh.globe@gmail.com X-Msg-Ref: server-14.tower-27.messagelabs.com!1383696346!892999!1 X-Originating-IP: [209.85.220.169] X-SpamReason: No, hits=1.7 required=7.0 tests=BODY_RANDOM_LONG, HTML_20_30, HTML_MESSAGE, ML_RADAR_SPEW_LINKS_14, RCVD_BY_IP, spamassassin: X-StarScan-Received: X-StarScan-Version: 6.9.13; banners=-,-,- X-VirusChecked: Checked Received: (qmail 13555 invoked from network); 6 Nov 2013 00:05:47 -0000 Received: from mail-vc0-f169.google.com (HELO mail-vc0-f169.google.com) (209.85.220.169) by server-14.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 6 Nov 2013 00:05:47 -0000 Received: by mail-vc0-f169.google.com with SMTP id hu8so6124208vcb.14 for ; Tue, 05 Nov 2013 16:05:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=CcVA2VJiPG3/BmQpjUnlEX1FqD8ZmNaHUbzqDSFMlcY=; b=aNCU1mTu7u8gYXXnRj77tq9+b3La25T6Hf5Qavixh6VPi4ILQa/+ejm/HKk7u4QvET L405PaBzkp9SWUBnedYya6PmMW8jzaBR/2ryJ8+XnWeM7jWc5p2aiKz7lnujEguKb5hy 75rOk4lzkQf6/Tu6jgrvVYFvpiE4OdEK8at7XJXJ1Gko+3tWONgImKXT2vzw5AwnrwQ4 8zr4aYYyAgU9tf/tle5F2cUwBtHoy5+KlRx6hRzLRNdcxJj9bXG/HgMuGnVh6ltemyLC oOZmYJtTPTnBwXUYlsYuSZJg2LV9bXDs75XpeQB9ihRNHForBMdk/e83ahwHtB/qHlNS 4Log== MIME-Version: 1.0 X-Received: by 10.220.101.208 with SMTP id d16mr66443vco.63.1383696346029; Tue, 05 Nov 2013 16:05:46 -0800 (PST) Received: by 10.58.97.197 with HTTP; Tue, 5 Nov 2013 16:05:45 -0800 (PST) In-Reply-To: <1383646812.13961.40.camel@kazak.uk.xensource.com> References: <1383646812.13961.40.camel@kazak.uk.xensource.com> Date: Tue, 5 Nov 2013 16:05:45 -0800 Message-ID: From: Saurabh Mishra To: Ian Campbell X-Mailman-Approved-At: Wed, 06 Nov 2013 09:59:45 +0000 Cc: xen-devel@lists.xen.org Subject: Re: [Xen-devel] xl does not support specifying virtual function for passthrough device X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1062337911097953209==" Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org --===============1062337911097953209== Content-Type: multipart/alternative; boundary=047d7b3441122ea34704ea76e94f --047d7b3441122ea34704ea76e94f Content-Type: text/plain; charset=ISO-8859-1 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 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. > > > --047d7b3441122ea34704ea76e94f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Ian --

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

I= s 'xl' being actively supported by Xen development community? and &= #39;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 <<= a href=3D"mailto:Ian.Campbell@citrix.com" target=3D"_blank">Ian.Campbell@ci= trix.com> 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 supp= ort 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, no= t
the more modern qemu-xen ("upstream") stuff. xl supports both.

> =A0For example :-

> pci =3D [ '0000:08:00.1=3D0,2=3D1,3=3D2,4=3D3@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=3D5)

> ironpass3:~/sles11_sp2_gm # grep pci sles11_sp= 2_gm.xenconfig
> #pci =3D [ '0000:08:00.1=3D0@0a', '0000:08:00.2=3D0@0b'= ;, '0000:08:00.3=3D0@0c', '0000:08:00.4=3D0@0d' ]
> pci =3D [ '0000:08:00.1=3D0,2=3D1,3=3D2,4=3D3@0a' ]
> xen_platform_pci=3D0

> 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 [Nat= oma] [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 [Nat= oma/Triton II] [8086:7010]
> 00:01.3 Bridge [0680]: Intel Corporation 82371AB/EB/MB PIIX4 ACPI [808= 6:7113] (rev 01)
> 00:02.0 VGA compatible controller [0300]: Cirrus Logic GD 5446 [1013:0= 0b8]
> 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 d= o 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 n= ot
> >change, but if it is 6 we'll have to have a think...

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

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

> However, =A0we may specify '0000:07:11.6=3D0@1a' and ''= ;0000:07:11.8=3D1@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&= #39;.

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.



--047d7b3441122ea34704ea76e94f-- --===============1062337911097953209== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============1062337911097953209==--