Xen 4.1 Feature Request List

Xen 4.1 Feature Request List

[Stephen Spector]

[-- Attachment #1.1: Type: text/plain, Size: 723 bytes --]

Xen Community:

As many of you are aware, the Xen 4.0 hypervisor is due to ship tomorrow (shhhh, don't tell anyone) and I wanted to get submissions underway for Xen 4.1 features. I have updated the Roadmap Wiki page (http://wiki.xensource.com/xenwiki/XenRoadMap) with a new section for Xen 4.1 features to be added. Feel free to add your ideas or send me your features and I will update the wiki. I also plan to update the Xen.org roadmap page at http://www.xen.org/products/xen_roadmap.html to be a list of 4.1 features tomorrow, after Xen 4.0 is announced.

Thanks.

Stephen Spector

Xen.org Community Manager
T: (772) 621-5062 | M: (954) 854-4257
stephen.spector@xen.org
http://blog.xen.org | @xen_com_mgr


[-- Attachment #1.2: Type: text/html, Size: 5733 bytes --]

[-- Attachment #2: Type: text/plain, Size: 137 bytes --]

_______________________________________________
Xen-users mailing list
Xen-users@lists.xensource.com
http://lists.xensource.com/xen-users

Re: [Xen-users] Xen 4.1 Feature Request List

[David Markey]

[-- Attachment #1.1: Type: text/plain, Size: 1161 bytes --]

Hi Stephen.

Might be a long shot, but id really like to see SPICE ported to Xen.

http://spice-space.org/



On 6 April 2010 18:41, Stephen Spector <stephen.spector@citrix.com> wrote:

>  Xen Community:
>
>
>
> As many of you are aware, the Xen 4.0 hypervisor is due to ship tomorrow
> (shhhh, don’t tell anyone) and I wanted to get submissions underway for Xen
> 4.1 features. I have updated the Roadmap Wiki page (
> http://wiki.xensource.com/xenwiki/XenRoadMap) with a new section for Xen
> 4.1 features to be added. Feel free to add your ideas or send me your
> features and I will update the wiki. I also plan to update the Xen.org
> roadmap page at http://www.xen.org/products/xen_roadmap.html to be a list
> of 4.1 features tomorrow, after Xen 4.0 is announced.
>
>
>
> Thanks.
>
>
>
> *Stephen Spector*
>
>
>
> Xen.org Community Manager
>
> *T:* (772) 621-5062 | *M:* (954) 854-4257
>
> stephen.spector@xen.org
>
> http://blog.xen.org | @xen_com_mgr
>
>
>
> _______________________________________________
> Xen-users mailing list
> Xen-users@lists.xensource.com
> http://lists.xensource.com/xen-users
>

[-- Attachment #1.2: Type: text/html, Size: 2295 bytes --]

[-- Attachment #2: Type: text/plain, Size: 138 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Re: Re: [Xen-users] Xen 4.1 Feature Request List

[Stefano Stabellini]

On Tue, 6 Apr 2010, David Markey wrote:
> Hi Stephen.
> 
> Might be a long shot, but id really like to see SPICE ported to Xen.
> http://spice-space.org/
> 

spice has to be ported to qemu first, then when we complete the merge
with upstream qemu, we'll inherit spice as well.

Re: Re: [Xen-users] Xen 4.1 Feature Request List

[Grant McWilliams]

[-- Attachment #1.1: Type: text/plain, Size: 518 bytes --]

On Wed, Apr 7, 2010 at 4:07 AM, Stefano Stabellini <
stefano.stabellini@eu.citrix.com> wrote:

> On Tue, 6 Apr 2010, David Markey wrote:
> > Hi Stephen.
> >
> > Might be a long shot, but id really like to see SPICE ported to Xen.
> > http://spice-space.org/
> >
>
> spice has to be ported to qemu first, then when we complete the merge
> with upstream qemu, we'll inherit spice as well.
>

I see Spice listed as being in RHEL 5.5 (with KVM). Is it already in qemu or
are they doing something
custom?

Grant McWilliams

[-- Attachment #1.2: Type: text/html, Size: 926 bytes --]

[-- Attachment #2: Type: text/plain, Size: 138 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Re: [Xen-devel] Re: Xen 4.1 Feature Request List

[Stefano Stabellini]

On Wed, 7 Apr 2010, Grant McWilliams wrote:
> On Wed, Apr 7, 2010 at 4:07 AM, Stefano Stabellini <stefano.stabellini@eu.citrix.com> wrote:
>       On Tue, 6 Apr 2010, David Markey wrote:
>       > Hi Stephen.
>       >
>       > Might be a long shot, but id really like to see SPICE ported to Xen.
>       > http://spice-space.org/
>       >
> 
> spice has to be ported to qemu first, then when we complete the merge
> with upstream qemu, we'll inherit spice as well.
> 
> 
> I see Spice listed as being in RHEL 5.5 (with KVM). Is it already in qemu or are they doing something
> custom?
> 
 
Spice is not in Qemu yet, they probably have a very big custom patch in
their patchqueue.

Re: [Xen-devel] Re: Xen 4.1 Feature Request List

[Pasi Kärkkäinen]

On Wed, Apr 07, 2010 at 04:15:29AM -0700, Grant McWilliams wrote:
>    On Wed, Apr 7, 2010 at 4:07 AM, Stefano Stabellini
>    <[1]stefano.stabellini@eu.citrix.com> wrote:
> 
>      On Tue, 6 Apr 2010, David Markey wrote:
>      > Hi Stephen.
>      >
>      > Might be a long shot, but id really like to see SPICE ported to Xen.
>      > [2]http://spice-space.org/
>      >
> 
>      spice has to be ported to qemu first, then when we complete the merge
>      with upstream qemu, we'll inherit spice as well.
> 
>    I see Spice listed as being in RHEL 5.5 (with KVM). Is it already in qemu
>    or are they doing something
>    custom?
> 

It's custom.  Spice hasn't been merged to upstream Qemu yet.

-- Pasi

Re: [Xen-devel] Re: Xen 4.1 Feature Request List

[David Markey]

[-- Attachment #1.1: Type: text/plain, Size: 933 bytes --]

Oh yes.

It would be great if we could have HVM PV drivers in kernel.org.


On 7 April 2010 12:27, Pasi Kärkkäinen <pasik@iki.fi> wrote:

> On Wed, Apr 07, 2010 at 04:15:29AM -0700, Grant McWilliams wrote:
> >    On Wed, Apr 7, 2010 at 4:07 AM, Stefano Stabellini
> >    <[1]stefano.stabellini@eu.citrix.com> wrote:
> >
> >      On Tue, 6 Apr 2010, David Markey wrote:
> >      > Hi Stephen.
> >      >
> >      > Might be a long shot, but id really like to see SPICE ported to
> Xen.
> >      > [2]http://spice-space.org/
> >      >
> >
> >      spice has to be ported to qemu first, then when we complete the
> merge
> >      with upstream qemu, we'll inherit spice as well.
> >
> >    I see Spice listed as being in RHEL 5.5 (with KVM). Is it already in
> qemu
> >    or are they doing something
> >    custom?
> >
>
> It's custom.  Spice hasn't been merged to upstream Qemu yet.
>
> -- Pasi
>
>

[-- Attachment #1.2: Type: text/html, Size: 1542 bytes --]

[-- Attachment #2: Type: text/plain, Size: 137 bytes --]

_______________________________________________
Xen-users mailing list
Xen-users@lists.xensource.com
http://lists.xensource.com/xen-users

Re: Re: [Xen-users] Xen 4.1 Feature Request List

[Stefano Stabellini]

On Wed, 7 Apr 2010, David Markey wrote:
> Oh yes.
> It would be great if we could have HVM PV drivers in kernel.org.
> 

Yes, it would. I'll work on that.

Re: [Xen-users] Xen 4.1 Feature Request List

[Grant McWilliams]

[-- Attachment #1.1: Type: text/plain, Size: 2071 bytes --]

On Tue, Apr 6, 2010 at 10:41 AM, Stephen Spector <stephen.spector@citrix.com
> wrote:

>  Xen Community:
>
>
>
> As many of you are aware, the Xen 4.0 hypervisor is due to ship tomorrow
> (shhhh, don’t tell anyone) and I wanted to get submissions underway for Xen
> 4.1 features. I have updated the Roadmap Wiki page (
> http://wiki.xensource.com/xenwiki/XenRoadMap) with a new section for Xen
> 4.1 features to be added. Feel free to add your ideas or send me your
> features and I will update the wiki. I also plan to update the Xen.org
> roadmap page at http://www.xen.org/products/xen_roadmap.html to be a list
> of 4.1 features tomorrow, after Xen 4.0 is announced.
>
>
>
> Thanks.
>
>
>
> *Stephen Spector*
>

These might not be wishes for 4.1 as some may be too big but they're my
wishlist anyway. Note they also might not be things that belong to the
Hypervisor but rather to tools associated with.


   1. Make qcow2 actually work and include backing files.
      1. If it can't be made to work then it should be taken out and not
      mentioned in the docs so we don't waste weeks trying to get it to work.
      2. Figure out why you can't start a VM with a disk image residing in a
   ramdisk (bug?)
   3. Nesting
      1. As silly as this feature sounds it may be why I leave Xen for KVM.
      This would be useful for teaching management of VMs. A student
could have a
      Dom0 and start up DomUs inside it without each on needing their
own physical
      machine.
      4. Install PV DomU from CD without FTP/NFS tricks.
   1. I don't care how it's done but it would be nice. The "install from
      network" shuffle can pose a complexity for people getting started in Xen.
      I'm aware that HVM does this because of it's use of Qemu but it would be
      nice everywhere. Maybe as Xen moves to Hybrid VMs instead of PV/HVM this
      will no longer be an issue.


I'm sure I'll think of others but that's off the top of my head. Like I said
maybe some of it would be Xen 5 stuff, I don't know.

[-- Attachment #1.2: Type: text/html, Size: 2796 bytes --]

[-- Attachment #2: Type: text/plain, Size: 138 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Re: [Xen-users] Xen 4.1 Feature Request List

[Pasi Kärkkäinen]

On Wed, Apr 07, 2010 at 04:13:07AM -0700, Grant McWilliams wrote:
> 
>    These might not be wishes for 4.1 as some may be too big but they're my
>    wishlist anyway. Note they also might not be things that belong to the
>    Hypervisor but rather to tools associated with.
> 
>     1. Make qcow2 actually work and include backing files.
> 

Have you checked out blktap2 VHD support? Does it work for you? 

See: http://wiki.xensource.com/xenwiki/XenCommonProblems
for links.

>          1. If it can't be made to work then it should be taken out and not
>             mentioned in the docs so we don't waste weeks trying to get it to
>             work.
> 

>From which docs?

>     2. Figure out why you can't start a VM with a disk image residing in a
>        ramdisk (bug?)

I have never tried this one. Which disk backend did you use? 

>     3. Nesting
> 
>          1. As silly as this feature sounds it may be why I leave Xen for
>             KVM. This would be useful for teaching management of VMs. A
>             student could have a Dom0 and start up DomUs inside it without
>             each on needing their own physical machine.
> 

There was a presentation about Xen 'nested' virtualization at Xen Summit 2009:
http://www.xen.org/files/xensummit_intel09/xensummit-nested-virt.pdf

Youtube also has some videos about the presentation.

>     4. Install PV DomU from CD without FTP/NFS tricks.
> 
>          1. I don't care how it's done but it would be nice. The "install
>             from network" shuffle can pose a complexity for people getting
>             started in Xen. I'm aware that HVM does this because of it's use
>             of Qemu but it would be nice everywhere. Maybe as Xen moves to
>             Hybrid VMs instead of PV/HVM this will no longer be an issue.
> 

There has been work for hybrid HVM+PV Xen guests recently by Intel and Citrix.

The problem of booting PV domU installers from a CD/.iso is the fact
that the CD needs to have a Xen PV kernel included! Many images don't have that.

This is changing now when distros ship kernels with pvops Xen domU support enabled,
it has been in the mainline Linux for a couple of years now.

>    I'm sure I'll think of others but that's off the top of my head. Like I
>    said maybe some of it would be Xen 5 stuff, I don't know.
> 

-- Pasi

Re: Xen 4.1 Feature Request List

[Grant McWilliams]

[-- Attachment #1.1: Type: text/plain, Size: 1965 bytes --]

On Wed, Apr 7, 2010 at 7:51 AM, Pasi Kärkkäinen <pasik@iki.fi> wrote:

> On Wed, Apr 07, 2010 at 04:13:07AM -0700, Grant McWilliams wrote:
> >
> >    These might not be wishes for 4.1 as some may be too big but they're
> my
> >    wishlist anyway. Note they also might not be things that belong to the
> >    Hypervisor but rather to tools associated with.
> >
> >     1. Make qcow2 actually work and include backing files.
> >
>
> Have you checked out blktap2 VHD support? Does it work for you?
>

I haven't. I thought it was only commercial Xenserver that supported VHD.




> See: http://wiki.xensource.com/xenwiki/XenCommonProblems
> for links.
>
> >          1. If it can't be made to work then it should be taken out and
> not
> >             mentioned in the docs so we don't waste weeks trying to get
> it to
> >             work.
> >
>
> From which docs?
>

The internet! :-) I assumed that qcow was in the docs since Xen supports it
and it's mentioned all over the forums. It very well might not be mentioned
in the docs but it has some support for qcow that no matter which version of
xen or Centos I used I ran into some bug that stopped me from using it. As
class as I got was to use qcow images as disks but with no backing store
which I don't think makes a whole lot of sense.


> >     2. Figure out why you can't start a VM with a disk image residing in
> a
> >        ramdisk (bug?)
>
> I have never tried this one. Which disk backend did you use?
>

I was using tap:aio disk images with Xen 3.4. I really wanted to use a qcow2
backing disk in a ram disk so all reads would be super fast then the writes
would go to the RAID. I then stepped down from that lofty goal and tried to
get any DomU to boot from any image in ramdisk and it would error
immediately. It's been a while now so I don't remember the error. I could
try it again though.



>
>
>
> -- Pasi
>
>
Grant McWilliams

[-- Attachment #1.2: Type: text/html, Size: 3068 bytes --]

[-- Attachment #2: Type: text/plain, Size: 137 bytes --]

_______________________________________________
Xen-users mailing list
Xen-users@lists.xensource.com
http://lists.xensource.com/xen-users

Re: [Xen-users] Xen 4.1 Feature Request List

[Pasi Kärkkäinen]

On Wed, Apr 07, 2010 at 01:59:40PM -0700, Grant McWilliams wrote:
>    On Wed, Apr 7, 2010 at 7:51 AM, Pasi KÀrkkÀinen <[1]pasik@iki.fi> wrote:
> 
>      On Wed, Apr 07, 2010 at 04:13:07AM -0700, Grant McWilliams wrote:
>      >
>      > Â  Â These might not be wishes for 4.1 as some may be too big but
>      they're my
>      > Â  Â wishlist anyway. Note they also might not be things that belong
>      to the
>      > Â  Â Hypervisor but rather to tools associated with.
>      >
>      > Â  Â  1. Make qcow2 actually work and include backing files.
>      >
> 
>      Have you checked out blktap2 VHD support? Does it work for you?
> 
>    I haven't. I thought it was only commercial Xenserver that supported VHD.
> 

Xen 4.0.0 includes blktap2 support in the tools: http://wiki.xensource.com/xenwiki/Xen4.0

You also need a kernel with the blktap2 driver:
http://wiki.xensource.com/xenwiki/XenKernelFeatures

(that XenKernelFeatures wiki page is still a work-in-progress and might not be complete yet).

> 
>      See: [2]http://wiki.xensource.com/xenwiki/XenCommonProblems
>      for links.
> 
>      > Â  Â  Â  Â  Â 1. If it can't be made to work then it should be taken
>      out and not
>      > Â  Â  Â  Â  Â  Â  mentioned in the docs so we don't waste weeks trying
>      to get it to
>      > Â  Â  Â  Â  Â  Â  work.
>      >
> 
>      From which docs?
> 
>    The internet! :-) I assumed that qcow was in the docs since Xen supports
>    it and it's mentioned all over the forums. It very well might not be
>    mentioned in the docs but it has some support for qcow that no matter
>    which version of xen or Centos I used I ran into some bug that stopped me
>    from using it. As class as I got was to use qcow images as disks but with
>    no backing store which I don't think makes a whole lot of sense.
>

I guess blktap2/vhd was developed because of qcow wasn't that good.
 
>      > Â  Â  2. Figure out why you can't start a VM with a disk image
>      residing in a
>      > Â  Â  Â  Â ramdisk (bug?)
> 
>      I have never tried this one. Which disk backend did you use?
> 
>    I was using tap:aio disk images with Xen 3.4. I really wanted to use a
>    qcow2 backing disk in a ram disk so all reads would be super fast then the
>    writes would go to the RAID. I then stepped down from that lofty goal and
>    tried to get any DomU to boot from any image in ramdisk and it would error
>    immediately. It's been a while now so I don't remember the error. I could
>    try it again though.
> 

Ok.

-- Pasi

Re: Re: [Xen-users] Xen 4.1 Feature Request List

[Jeremy Fitzhardinge]

On 04/07/2010 04:13 AM, Grant McWilliams wrote:
>
>    1. Figure out why you can't start a VM with a disk image residing
>       in a ramdisk (bug?)
>

What happens if you do that?

>    1. Nesting
>          1. As silly as this feature sounds it may be why I leave Xen
>             for KVM. This would be useful for teaching management of
>             VMs. A student could have a Dom0 and start up DomUs inside
>             it without each on needing their own physical machine.
>

Xen nests OK, so long as you're happy running purely PV guests within 
the inner Xen.

>         1.
>
>
>    1. Install PV DomU from CD without FTP/NFS tricks.
>          1. I don't care how it's done but it would be nice. The
>             "install from network" shuffle can pose a complexity for
>             people getting started in Xen. I'm aware that HVM does
>             this because of it's use of Qemu but it would be nice
>             everywhere. Maybe as Xen moves to Hybrid VMs instead of
>             PV/HVM this will no longer be an issue.
>

What I typically do is install systems as HVM, then just boot them as PV 
later on.  For Fedora installs, at least, it pretty much just works 
because they avoid having any direct device references for filesystems, 
etc.  It's a bit more fiddly without having HVM available.

     J

Re: Re: [Xen-users] Xen 4.1 Feature Request List

[Keir Fraser]

On 07/04/2010 18:17, "Jeremy Fitzhardinge" <jeremy@goop.org> wrote:

>>    1. Nesting
>>          1. As silly as this feature sounds it may be why I leave Xen
>>             for KVM. This would be useful for teaching management of
>>             VMs. A student could have a Dom0 and start up DomUs inside
>>             it without each on needing their own physical machine.
>> 
> 
> Xen nests OK, so long as you're happy running purely PV guests within
> the inner Xen.

There are patches imminently incoming to do this for HVM-on-HVM, for AMD SVM
at least.

 -- Keir

RE: [Xen-users] Xen 4.1 Feature Request List

[Jeff Sturm]

[-- Attachment #1.1: Type: text/plain, Size: 1210 bytes --]

It would be nice if XenFS, or something like it, ever came to fruition.
We've gotten by with clustered filesystems on our domU's, but these are
a bit heavyweight in comparison.

 

-Jeff

 

From: xen-users-bounces@lists.xensource.com
[mailto:xen-users-bounces@lists.xensource.com] On Behalf Of Stephen
Spector
Sent: Tuesday, April 06, 2010 1:41 PM
To: Xen-devel; Xen List
Subject: [Xen-users] Xen 4.1 Feature Request List

 

Xen Community:

 

As many of you are aware, the Xen 4.0 hypervisor is due to ship tomorrow
(shhhh, don't tell anyone) and I wanted to get submissions underway for
Xen 4.1 features. I have updated the Roadmap Wiki page
(http://wiki.xensource.com/xenwiki/XenRoadMap) with a new section for
Xen 4.1 features to be added. Feel free to add your ideas or send me
your features and I will update the wiki. I also plan to update the
Xen.org roadmap page at http://www.xen.org/products/xen_roadmap.html to
be a list of 4.1 features tomorrow, after Xen 4.0 is announced. 

 

Thanks. 

 

Stephen Spector

 

Xen.org Community Manager

T: (772) 621-5062 | M: (954) 854-4257

stephen.spector@xen.org 

http://blog.xen.org | @xen_com_mgr

 


[-- Attachment #1.2: Type: text/html, Size: 7238 bytes --]

[-- Attachment #2: Type: text/plain, Size: 138 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Re: Xen 4.1 Feature Request List

[Fantu]

On HVM domU make possible boot from cd/dvd from file, now is possible only
with do loop for "false physical device" and do work it

Stephen Spector wrote:
> 
> Xen Community:
> 
> As many of you are aware, the Xen 4.0 hypervisor is due to ship tomorrow
> (shhhh, don't tell anyone) and I wanted to get submissions underway for
> Xen 4.1 features. I have updated the Roadmap Wiki page
> (http://wiki.xensource.com/xenwiki/XenRoadMap) with a new section for Xen
> 4.1 features to be added. Feel free to add your ideas or send me your
> features and I will update the wiki. I also plan to update the Xen.org
> roadmap page at http://www.xen.org/products/xen_roadmap.html to be a list
> of 4.1 features tomorrow, after Xen 4.0 is announced.
> 
> Thanks.
> 
> Stephen Spector
> 
> Xen.org Community Manager
> T: (772) 621-5062 | M: (954) 854-4257
> stephen.spector@xen.org
> http://blog.xen.org | @xen_com_mgr
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
> 
> 

-- 
View this message in context: http://old.nabble.com/Xen-4.1-Feature-Request-List-tp28155211p28177904.html
Sent from the Xen - Dev mailing list archive at Nabble.com.

Re: Xen 4.1 Feature Request List

[Jeremy Fitzhardinge]

On 04/08/2010 05:33 AM, Fantu wrote:
> On HVM domU make possible boot from cd/dvd from file, now is possible only
> with do loop for "false physical device" and do work it
>   

Booting an HVM domain works from a CD/DVD image.  I use a statement of
the form:

    'file:/home/jeremy/win7.iso,hdc:cdrom,r'

Is that what you mean?

    J

Re: Xen 4.1 Feature Request List

[Fantu]

is already in xen 4.0 boot from cd in hvm on all and not phy? i not see in
changelog or commit comment and i not try in 4.0, if there is already sorry

Jeremy Fitzhardinge wrote:
> 
> On 04/08/2010 05:33 AM, Fantu wrote:
>> On HVM domU make possible boot from cd/dvd from file, now is possible
>> only
>> with do loop for "false physical device" and do work it
>>   
> 
> Booting an HVM domain works from a CD/DVD image.  I use a statement of
> the form:
> 
>     'file:/home/jeremy/win7.iso,hdc:cdrom,r'
> 
> Is that what you mean?
> 
>     J
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
> 
> 

-- 
View this message in context: http://old.nabble.com/Xen-4.1-Feature-Request-List-tp28155211p28182598.html
Sent from the Xen - Dev mailing list archive at Nabble.com.

Re: Xen 4.1 Feature Request List

[Jeremy Fitzhardinge]

On 04/08/2010 11:23 AM, Fantu wrote:
> is already in xen 4.0 boot from cd in hvm on all and not phy? i not see in
> changelog or commit comment and i not try in 4.0, if there is already sorry
>   

It has always worked.  It isn't a new feature.

    J

Re: Xen 4.1 Feature Request List

[Thomas Goirand]

What:
====
It'd be great to be able to do something like:

'exportpath:/var/mypath/myvps1,/,rw'

so that the folder /var/mypath/myvps1 of a dom0 would be somehow
exported to a domU as /. Both the domU and dom0 would have read/write
access to it.

Why:
===
I know it is possible to do this with an NFS export on the dom0 then
access it from domU over network, but NFS is slow and has lock issues.
Using an LVM slice is ok, but then the space not used by a domU cannot
be reused by other VMs on the physical server, resulting in a lot of waste.

Also, on the desktop, that'd be great to be able to have a folder shared
between multiple VMs.

Many emulator have this option (for example some Atari emulators). Why
not with Xen too?

Just my 2c of idea, without even knowing how much effort would be needed
for an implementation...

Thomas

Some test results on Xen 4.0 and 2.6.31 / 2.6.32 pvops kernels

[Carsten Schiers]

OK, I am still a bit fuzzy as I had to learn how to git and configure 
kernels, and I am still unsure whether I did everything 
right. Nevertheless, and even when I cannot provide a lot of details, I 
would like to inform you about some anomalies. 

Currently, I run Xen 3.4.1 and 2.6.18.8 kernels, 64 Bit Dom0 and some 32 
Bit and 64 Bit DomUs on a Gigabyte M56S-S3 / AMD 4050e 
with cpufreq on powernow-k8 in cpufreq=dom0-kernel mode. I make use of 
PCI Passthrough for DVB-C cards and onboard NIC, as well 
as for USB controller.



Compile problem on xen/stable-2.6.32
------------------------------------

I compiled 2.6.32.10-pvops for DomU only mode, resulting in compile 
error very similar to 

  
http://lists.xensource.com/archives/html/xen-devel/2010-03/msg00925.html

I get a "static declaration of 'xen_register_gsi' follows a non-static 
declaration, because I have set CONFIG_XEN_PCI_MSI and 
CONFIG_PCI_XEN, but not CONFIG_XEN_DOM0_PCI. It will disappear when 
compiling a DOM0 kernel.



PCI controller / 2nd Function? / working in xen/master-2.6.32.13, not 
working on xen/stable-2.6.32 on Xen 3.4.1
------------------------------------------------------------------------
---------------------------------------

It will allow passthrough of all mentioned devices except one of the PCI 
controllers. It will not be detected. Using 
xm pci-attach will produce an error:

  troi kernel: [   23.862294] ehci_hcd 0000:00:01.1: device not 
available because of BAR 0 [0xfc102000-0xfc1020ff] collisions
  troi kernel: [   61.942809] ohci_hcd 0000:00:01.0: device not 
available because of BAR 0 [0xfc104000-0xfc104fff] collisions

I first tried only with the 2nd function (or whatever it is called), but 
as you see, we have the same error with both put into 
the DomU.



nVidia forcedeth, working on pvops/Xen 3.4.1, not working on pvops/Xen 
4.0
------------------------------------------------------------------------
--

The whole experiment was done because when I use Xen 4.0 with my 
2.6.18.8 kernels, I cannot use the onboard NIC any longer. The 
driver forcedeth will report an error. So, as using the pvops DomU on 
Xen 3.4.1 worked, I tried to also use a pvops Dom0 underneath
Xen 4.0, but the problem seems to be related to the Xen 4.0, which is 
killing forcedeth MAC address detection. By the way: MSI has
never worked for me on that NIC. So I had pci=nomsi on kernel.

not working example (MAC is random):

  troi kernel: [    4.335591] forcedeth: Reverse Engineered nForce 
ethernet driver. Version 0.64.
  troi kernel: [    4.335811] forcedeth 0000:00:00.0: enabling device 
(0000 -> 0003)
  troi kernel: [    4.335942] forcedeth 0000:00:00.0: Xen PCI enabling 
IRQ: 23
  troi kernel: [    4.336016] forcedeth 0000:00:00.0: setting latency 
timer to 64
  troi kernel: [    4.336271] forcedeth 0000:00:00.0: Invalid Mac 
address detected: 00:00:00:00:00:00
  troi kernel: [    4.336295] forcedeth 0000:00:00.0: Please complain to 
your hardware vendor. Switching to a random MAC.
  troi kernel: [    4.860537] forcedeth 0000:00:00.0: ifname eth0, PHY 
OUI 0x732 @ 1, addr 5e:1a:09:69:77:5d
  troi kernel: [    4.860593] forcedeth 0000:00:00.0: highdma pwrctl 
mgmt gbit lnktim msi desc-v3

working example (real MAC, note different IRQ):
 
  troi kernel: [    1.133102] forcedeth: Reverse Engineered nForce 
ethernet driver. Version 0.64.
  troi kernel: [    1.133376] forcedeth 0000:00:01.0: enabling device 
(0000 -> 0003)
  troi kernel: [    1.133463] forcedeth 0000:00:01.0: Xen PCI enabling 
IRQ: 19
  troi kernel: [    1.652048] forcedeth 0000:00:01.0: ifname eth0, PHY 
OUI 0x732 @ 1, addr 00:1d:7d:e8:97:7b
  troi kernel: [    1.652139] forcedeth 0000:00:01.0: highdma pwrctl 
mgmt gbit lnktim msi desc-v3



powernow-k8 in pvops Dom0 doesn't work any longer with Xen 4.0
--------------------------------------------------------------

I found this in the logs, not idea currently what Xen 3.4.1 with pvops 
or Xen 4.0 with 2.6.18 kernel would say.

  data kernel: [    9.030558] powernow-k8: Found 1 AMD Athlon(tm) Dual 
Core Processor 4050e processors (2 cpu cores) (version 2.20.00)
  data kernel: [    9.030955] [Firmware Bug]: powernow-k8: No compatible 
ACPI _PSS objects found.
  data kernel: [    9.030957] [Firmware Bug]: powernow-k8: Try again 
with latest BIOS.

Best Regards,
Carsten.

Re: Some test results on Xen 4.0 and 2.6.31 / 2.6.32 pvops kernels

[Pasi Kärkkäinen]

On Thu, Apr 08, 2010 at 09:46:58PM +0200, Carsten Schiers wrote:
> 
> PCI controller / 2nd Function? / working in xen/master-2.6.32.13, not 
> working on xen/stable-2.6.32 on Xen 3.4.1
> ------------------------------------------------------------------------
> ---------------------------------------
> 
> It will allow passthrough of all mentioned devices except one of the PCI 
> controllers. It will not be detected. Using 
> xm pci-attach will produce an error:
> 
>   troi kernel: [   23.862294] ehci_hcd 0000:00:01.1: device not 
> available because of BAR 0 [0xfc102000-0xfc1020ff] collisions
>   troi kernel: [   61.942809] ohci_hcd 0000:00:01.0: device not 
> available because of BAR 0 [0xfc104000-0xfc104fff] collisions
> 
> I first tried only with the 2nd function (or whatever it is called), but 
> as you see, we have the same error with both put into 
> the DomU.
> 

Have you seen this wiki page?:
http://wiki.xensource.com/xenwiki/XenPCIpassthrough

Try the "I get "non-page-aligned MMIO BAR" error when trying to start the guest" thing.. maybe it helps? 



> 
> powernow-k8 in pvops Dom0 doesn't work any longer with Xen 4.0
> --------------------------------------------------------------
> 
> I found this in the logs, not idea currently what Xen 3.4.1 with pvops 
> or Xen 4.0 with 2.6.18 kernel would say.
> 
>   data kernel: [    9.030558] powernow-k8: Found 1 AMD Athlon(tm) Dual 
> Core Processor 4050e processors (2 cpu cores) (version 2.20.00)
>   data kernel: [    9.030955] [Firmware Bug]: powernow-k8: No compatible 
> ACPI _PSS objects found.
>   data kernel: [    9.030957] [Firmware Bug]: powernow-k8: Try again 
> with latest BIOS.
> 

I think xen.git xen/stable-2.6.32.x is still missing the acpi powermanagement patches..

-- Pasi

AW: Re: Some test results on Xen 4.0 and 2.6.31 / 2.6.32 pvops kernels

[Carsten Schiers]

Hi folks, some progress:

>> PCI controller / 2nd Function? / working in xen/master-2.6.32.13, not 

>> working on xen/stable-2.6.32 on Xen 3.4.1
>> 
------------------------------------------------------------------------
>> ---------------------------------------
>> 
>> It will allow passthrough of all mentioned devices except one of the 
PCI 
>> controllers. It will not be detected. Using 
>> xm pci-attach will produce an error:
>> 
>>   troi kernel: [   23.862294] ehci_hcd 0000:00:01.1: device not 
>> available because of BAR 0 [0xfc102000-0xfc1020ff] collisions
>>   troi kernel: [   61.942809] ohci_hcd 0000:00:01.0: device not 
>> available because of BAR 0 [0xfc104000-0xfc104fff] collisions
>> 
>> I first tried only with the 2nd function (or whatever it is called), 
but 
>> as you see, we have the same error with both put into 
>> the DomU.
>>
>
>Have you seen this wiki page?:
>http://wiki.xensource.com/xenwiki/XenPCIpassthrough
>
>Try the "I get "non-page-aligned MMIO BAR" error when trying to start 
the guest" thing.. maybe it helps? 

Did so and move to Xen 3.4.3-rc4 and latest 2.6.18.8 Dom0 kernel. It 
works now with pvops 2.6.32.10 DomU kernel!!! 

Thanks Pasi!!!

Eventually, you may put on the Wiki Page an example with more than one 
PCI device, so that hectic persons like
me see better that a) it's without parenthesis and b) a comma separated 
list ;o).

BR,
Carsten.

Re: Re: Some test results on Xen 4.0 and 2.6.31 / 2.6.32 pvops kernels

[Pasi Kärkkäinen]

On Sat, Apr 10, 2010 at 11:26:53AM +0200, Carsten Schiers wrote:
> Hi folks, some progress:
> 
> >> PCI controller / 2nd Function? / working in xen/master-2.6.32.13, not 
> 
> >> working on xen/stable-2.6.32 on Xen 3.4.1
> >> 
> ------------------------------------------------------------------------
> >> ---------------------------------------
> >> 
> >> It will allow passthrough of all mentioned devices except one of the 
> PCI 
> >> controllers. It will not be detected. Using 
> >> xm pci-attach will produce an error:
> >> 
> >>   troi kernel: [   23.862294] ehci_hcd 0000:00:01.1: device not 
> >> available because of BAR 0 [0xfc102000-0xfc1020ff] collisions
> >>   troi kernel: [   61.942809] ohci_hcd 0000:00:01.0: device not 
> >> available because of BAR 0 [0xfc104000-0xfc104fff] collisions
> >> 
> >> I first tried only with the 2nd function (or whatever it is called), 
> but 
> >> as you see, we have the same error with both put into 
> >> the DomU.
> >>
> >
> >Have you seen this wiki page?:
> >http://wiki.xensource.com/xenwiki/XenPCIpassthrough
> >
> >Try the "I get "non-page-aligned MMIO BAR" error when trying to start 
> the guest" thing.. maybe it helps? 
> 
> Did so and move to Xen 3.4.3-rc4 and latest 2.6.18.8 Dom0 kernel. It 
> works now with pvops 2.6.32.10 DomU kernel!!! 
> 
> Thanks Pasi!!!
> 
> Eventually, you may put on the Wiki Page an example with more than one 
> PCI device, so that hectic persons like
> me see better that a) it's without parenthesis and b) a comma separated 
> list ;o).
> 

Actually what's missing from the wiki? :) It already has examples for multiple devices..

-- Pasi

Re: Some test results on Xen 4.0 and 2.6.31 / 2.6.32 pvops kernels

[Konrad Rzeszutek Wilk]

On Thu, Apr 08, 2010 at 09:46:58PM +0200, Carsten Schiers wrote:
> OK, I am still a bit fuzzy as I had to learn how to git and configure 
> kernels, and I am still unsure whether I did everything 
> right. Nevertheless, and even when I cannot provide a lot of details, I 
> would like to inform you about some anomalies. 
> 
> Currently, I run Xen 3.4.1 and 2.6.18.8 kernels, 64 Bit Dom0 and some 32 
> Bit and 64 Bit DomUs on a Gigabyte M56S-S3 / AMD 4050e 
> with cpufreq on powernow-k8 in cpufreq=dom0-kernel mode. I make use of 
> PCI Passthrough for DVB-C cards and onboard NIC, as well 
> as for USB controller.
> 
> 
> 
> Compile problem on xen/stable-2.6.32
> ------------------------------------
> 
> I compiled 2.6.32.10-pvops for DomU only mode, resulting in compile 
> error very similar to 
> 
>   
> http://lists.xensource.com/archives/html/xen-devel/2010-03/msg00925.html
> 
> I get a "static declaration of 'xen_register_gsi' follows a non-static 
> declaration, because I have set CONFIG_XEN_PCI_MSI and 
> CONFIG_PCI_XEN, but not CONFIG_XEN_DOM0_PCI. It will disappear when 
> compiling a DOM0 kernel.
> 
Can you do a copy-n-paste of your compile problem, please?
> 
> 
> PCI controller / 2nd Function? / working in xen/master-2.6.32.13, not 
> working on xen/stable-2.6.32 on Xen 3.4.1
> ------------------------------------------------------------------------
> ---------------------------------------
> 
> It will allow passthrough of all mentioned devices except one of the PCI 
> controllers. It will not be detected. Using 
> xm pci-attach will produce an error:
> 
>   troi kernel: [   23.862294] ehci_hcd 0000:00:01.1: device not 
> available because of BAR 0 [0xfc102000-0xfc1020ff] collisions
>   troi kernel: [   61.942809] ohci_hcd 0000:00:01.0: device not 
> available because of BAR 0 [0xfc104000-0xfc104fff] collisions

How much memory did you assign to the guest? If it is below 4GB, say 2GB
did you see these errors?

> nVidia forcedeth, working on pvops/Xen 3.4.1, not working on pvops/Xen 
> 4.0


> ------------------------------------------------------------------------
> --
> 
> The whole experiment was done because when I use Xen 4.0 with my 
> 2.6.18.8 kernels, I cannot use the onboard NIC any longer. The 
> driver forcedeth will report an error. So, as using the pvops DomU on 
> Xen 3.4.1 worked, I tried to also use a pvops Dom0 underneath

So.. DomU and Dom0 with the same kernel works?

> Xen 4.0, but the problem seems to be related to the Xen 4.0, which is 
> killing forcedeth MAC address detection. By the way: MSI has
> never worked for me on that NIC. So I had pci=nomsi on kernel.
> 
> not working example (MAC is random):
> 
>   troi kernel: [    4.335591] forcedeth: Reverse Engineered nForce 
> ethernet driver. Version 0.64.
>   troi kernel: [    4.335811] forcedeth 0000:00:00.0: enabling device 
> (0000 -> 0003)
>   troi kernel: [    4.335942] forcedeth 0000:00:00.0: Xen PCI enabling 
> IRQ: 23
>   troi kernel: [    4.336016] forcedeth 0000:00:00.0: setting latency 
> timer to 64
>   troi kernel: [    4.336271] forcedeth 0000:00:00.0: Invalid Mac 
> address detected: 00:00:00:00:00:00
>   troi kernel: [    4.336295] forcedeth 0000:00:00.0: Please complain to 
> your hardware vendor. Switching to a random MAC.
>   troi kernel: [    4.860537] forcedeth 0000:00:00.0: ifname eth0, PHY 
> OUI 0x732 @ 1, addr 5e:1a:09:69:77:5d
>   troi kernel: [    4.860593] forcedeth 0000:00:00.0: highdma pwrctl 
> mgmt gbit lnktim msi desc-v3
> 
> working example (real MAC, note different IRQ):
>  
>   troi kernel: [    1.133102] forcedeth: Reverse Engineered nForce 
> ethernet driver. Version 0.64.
>   troi kernel: [    1.133376] forcedeth 0000:00:01.0: enabling device 
> (0000 -> 0003)
>   troi kernel: [    1.133463] forcedeth 0000:00:01.0: Xen PCI enabling 
> IRQ: 19
>   troi kernel: [    1.652048] forcedeth 0000:00:01.0: ifname eth0, PHY 
> OUI 0x732 @ 1, addr 00:1d:7d:e8:97:7b
>   troi kernel: [    1.652139] forcedeth 0000:00:01.0: highdma pwrctl 
> mgmt gbit lnktim msi desc-v3

I got lost in your description. The failing case happens when
your Dom0 is 2.6.18 or the 2.6.31 (or 2.6.32?) And is the DomU pv-ops
or 2.6.18?

Re: Xen 4.1 Feature Request List

[Christian Tramnitz]

08.04.2010 21:00, Thomas Goirand wrote:
> What:
> ====
> It'd be great to be able to do something like:
>
> 'exportpath:/var/mypath/myvps1,/,rw'
>
> so that the folder /var/mypath/myvps1 of a dom0 would be somehow
> exported to a domU as /. Both the domU and dom0 would have read/write
> access to it.

Thats already work in progress in qemu for "paravirtual file system 
passthrough" which is what you request I guess.

Best regards,
    Christian

Re: Xen 4.1 Feature Request List

[Vincent, Pradeep]

[-- Attachment #1.1: Type: text/plain, Size: 1411 bytes --]

Multi-queue functionality in netfront/netbk drivers would be very useful in improving aggregate network throughput. This is complementary to leveraging VMQ functionality via Netchannel2.

For Dom-0 transmit queue logic, a simple mechanism to map physical NIC's receive queues to Vif's transmit queues and vice-versa would also be very useful and will help Dom-0 leverage NIC's hardware based hashing functionality such as RSS and guest kernel's transmit queue functionality for end-to-end network throughput enhancement.

Please let me know if you have any questions.

Thanks,

- Pradeep Vincent


On 4/6/10 10:41 AM, "Stephen Spector" <stephen.spector@citrix.com> wrote:

Xen Community:

As many of you are aware, the Xen 4.0 hypervisor is due to ship tomorrow (shhhh, don't tell anyone) and I wanted to get submissions underway for Xen 4.1 features. I have updated the Roadmap Wiki page (http://wiki.xensource.com/xenwiki/XenRoadMap) with a new section for Xen 4.1 features to be added. Feel free to add your ideas or send me your features and I will update the wiki. I also plan to update the Xen.org roadmap page at http://www.xen.org/products/xen_roadmap.html to be a list of 4.1 features tomorrow, after Xen 4.0 is announced.

Thanks.

Stephen Spector

Xen.org Community Manager
T: (772) 621-5062 | M: (954) 854-4257
stephen.spector@xen.org
http://blog.xen.org | @xen_com_mgr



[-- Attachment #1.2: Type: text/html, Size: 2135 bytes --]

[-- Attachment #2: Type: text/plain, Size: 138 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Re: Xen 4.1 Feature Request List

[Juergen Gross]

Stephen Spector wrote:
> Xen Community:
> 
>  
> 
> As many of you are aware, the Xen 4.0 hypervisor is due to ship tomorrow
> (shhhh, don’t tell anyone) and I wanted to get submissions underway for
> Xen 4.1 features. I have updated the Roadmap Wiki page
> (http://wiki.xensource.com/xenwiki/XenRoadMap) with a new section for
> Xen 4.1 features to be added. Feel free to add your ideas or send me
> your features and I will update the wiki. I also plan to update the
> Xen.org roadmap page at http://www.xen.org/products/xen_roadmap.html to
> be a list of 4.1 features tomorrow, after Xen 4.0 is announced.

Support of cpupools in Xen (Patches already sent).


Juergen

-- 
Juergen Gross                 Principal Developer Operating Systems
TSP ES&S SWE OS6                       Telephone: +49 (0) 89 3222 2967
Fujitsu Technology Solutions              e-mail: juergen.gross@ts.fujitsu.com
Domagkstr. 28                           Internet: ts.fujitsu.com
D-80807 Muenchen                 Company details: ts.fujitsu.com/imprint.html

AW: Re: Some test results on Xen 4.0 and 2.6.31 / 2.6.32 pvops kernels

[Carsten Schiers]

Two additional infos: here lspci of the two USB controllers. The 00:02.0 
is passed into another DomU. I 
should mention that I think the 00:02.0 is going down in case I pass 
00:02.1 into the 2.6.32 domain, but
not if I pass it into the 2.6.31 domain. Find what the other DomU says 
below.

00:02.0 USB Controller: nVidia Corporation MCP65 USB Controller (rev a3) 
(prog-if 10 [OHCI])
        Subsystem: Giga-byte Technology Device 5004
        Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- 
ParErr- Stepping- SERR- FastB2B- DisINTx-
        Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- 
<TAbort- <MAbort- >SERR- <PERR- INTx-
        Latency: 0 (750ns min, 250ns max)
        Interrupt: pin A routed to IRQ 21
        Region 0: Memory at c0200000 (32-bit, non-prefetchable) 
[size=4K]
        Capabilities: [44] Power Management version 2
                Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA 
PME(D0+,D1+,D2+,D3hot+,D3cold+)
                Status: D0 PME-Enable- DSel=0 DScale=0 PME-
        Kernel driver in use: pciback
        Kernel modules: ohci-hcd

00:02.1 USB Controller: nVidia Corporation MCP65 USB Controller (rev a3) 
(prog-if 20 [EHCI])
        Subsystem: Giga-byte Technology Device 5004
        Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- 
ParErr- Stepping- SERR- FastB2B- DisINTx-
        Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- 
<TAbort- <MAbort- >SERR- <PERR- INTx-
        Interrupt: pin B routed to IRQ 20
        Region 0: Memory at c0201000 (32-bit, non-prefetchable) 
[disabled] [size=256]
        Capabilities: [44] Debug port: BAR=1 offset=0098
        Capabilities: [80] Power Management version 2
                Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA 
PME(D0+,D1+,D2+,D3hot+,D3cold+)
                Status: D0 PME-Enable- DSel=0 DScale=0 PME+
        Kernel driver in use: pciback
        Kernel modules: ehci-hcd

Apr 11 16:27:26 uhura kernel: fcusb: Rx URB status: -110
Apr 11 16:27:26 uhura kernel: usb 1-2: USB disconnect, address 3
Apr 11 16:27:26 uhura kernel: kcapi: card 1 down.
Apr 11 16:27:26 uhura kernel: kcapi: Controller 1: fcusb-0003 
unregistered
Apr 11 16:27:26 uhura kernel: fcusb: Driver 'fcusb' detached
Apr 11 16:27:26 uhura kernel: usb 1-2: new full speed USB device using 
ohci_hcd and address 4
Apr 11 16:27:27 uhura kernel: usb 1-2: configuration #1 chosen from 1 
choice
Apr 11 16:27:27 uhura kernel: fcusb: Driver 'fcusb' attached to stack. 
(152)
Apr 11 16:27:27 uhura kernel: fcusb: Stack version 3.11-04
Apr 11 16:27:27 uhura kernel: kcapi: Controller 1: fcusb-0004 attached
Apr 11 16:27:27 uhura kernel: kcapi: card 1 "fcusb-0004" ready.
Apr 11 16:28:24 uhura kernel: fcusb: Rx URB status: -110
Apr 11 16:28:24 uhura kernel: usb 1-2: USB disconnect, address 4
Apr 11 16:28:25 uhura kernel: kcapi: card 1 down.
Apr 11 16:28:25 uhura kernel: kcapi: Controller 1: fcusb-0004 
unregistered
Apr 11 16:28:25 uhura kernel: fcusb: Driver 'fcusb' detached
Apr 11 16:28:25 uhura kernel: usb 1-2: new full speed USB device using 
ohci_hcd and address 5
Apr 11 16:28:25 uhura kernel: usb 1-2: configuration #1 chosen from 1 
choice
Apr 11 16:28:25 uhura kernel: fcusb: Driver 'fcusb' attached to stack. 
(152)
Apr 11 16:28:25 uhura kernel: fcusb: Stack version 3.11-04
Apr 11 16:28:25 uhura kernel: kcapi: Controller 1: fcusb-0005 attached
Apr 11 16:28:25 uhura kernel: kcapi: card 1 "fcusb-0005" ready.

BR,
Carsten.


-----Ursprüngliche Nachricht-----
Von: Carsten Schiers 
Gesendet: Sonntag, 11. April 2010 16:33
An: xen-devel
Cc: jeremy; konrad.wilk
Betreff: AW: Re: [Xen-devel] Some test results on Xen 4.0 and 2.6.31 / 
2.6.32 pvops kernels

Hi,

I am sorry to say that I mixed something. What does work now is 
2.6.31.13 kernel. The error
messages are gone now for 2.6.32.11, but it is still not functioning. 

So, with the 2.6.32.11 kernel, it will not recognize the same USB 
controller that is recognized 
by 2.6.31.13. 

When booting:

[    0.168388] pcifront pci-0: Creating PCI Frontend Bus 0000:00
[    0.325746]   alloc irq_desc for 503 on node 0
[    0.325753]   alloc kstat_irqs on node 0

When I detach and attach from Dom0, it will log in the DomU:

[  202.660279] pcifront pci-0: Rescanning PCI Frontend Bus 0000:00
[  202.848550] pcifront pci-0: backend going away!
[  202.857153] pcifront pci-0: Disconnecting PCI Frontend Buses
[  202.903310] pcifront pci-0: 22 freeing event channel 9
[  224.234600] pcifront pci-0: Installing PCI frontend
[  224.237069] pcifront pci-0: Creating PCI Frontend Bus 0000:00

In Dom0 we have:

ACPI: PCI interrupt for device 0000:00:02.1 disabled
pciback: vpci: 0000:00:02.1: assign to virtual slot 0

For reference, the log entries when I detach/attach the device in 
2.6.31.13:

[   47.250686] usb usb1: USB disconnect, address 1
[   47.251155] ehci_hcd 0000:00:00.1: USB bus 1 deregistered
[   47.349616] pcifront pci-0: Rescanning PCI Frontend Bus 0000:00
[   47.938006] pcifront pci-0: backend going away!
[   47.941640] pcifront pci-0: Disconnecting PCI Frontend Buses
[   47.946981] pcifront pci-0: Device is in 6 state. Need to change 
state on the privileged domain.
[   47.952364] pcifront pci-0: Device is in 0 state. Need to change 
state on the privileged domain.
[   47.957636] pcifront pci-0: 22 freeing event channel 9
[   58.832396] pcifront pci-0: Device is in 2 state. Need to change 
state on the privileged domain.
[   58.840387] pcifront pci-0: Device is in 3 state. Need to change 
state on the privileged domain.
[   58.868584] pcifront pci-0: Installing PCI frontend
[   58.869661] pcifront pci-0: Creating PCI Frontend Bus 0000:00
[   59.487005] ehci_hcd 0000:00:00.1: enabling device (0000 -> 0002)
[   59.487005] ehci_hcd 0000:00:00.1: Xen PCI enabling IRQ: 20
[   59.487005] xen_allocate_pirq: returning irq 20 for gsi 20
[   59.487005] ehci_hcd 0000:00:00.1: EHCI Host Controller
[   59.491270] ehci_hcd 0000:00:00.1: new USB bus registered, assigned 
bus number 1
[   59.491409] ehci_hcd 0000:00:00.1: Enabling legacy PCI PM
[   59.491462] ehci_hcd 0000:00:00.1: debug port 1
[   59.491534] ehci_hcd 0000:00:00.1: irq 20, io mem 0xc0201000
[   59.497088] ehci_hcd 0000:00:00.1: USB 2.0 started, EHCI 1.00
[   59.497182] usb usb1: New USB device found, idVendor=1d6b, 
idProduct=0002
[   59.497194] usb usb1: New USB device strings: Mfr=3, Product=2, 
SerialNumber=1
[   59.497207] usb usb1: Product: EHCI Host Controller
[   59.497216] usb usb1: Manufacturer: Linux 2.6.31.13-pvops-686 
ehci_hcd
[   59.497228] usb usb1: SerialNumber: 0000:00:00.1
[   59.497363] usb usb1: configuration #1 chosen from 1 choice
[   59.497447] hub 1-0:1.0: USB hub found
[   59.497643] hub 1-0:1.0: 10 ports detected

Relevant XEN config entries in 2.6.32.11:

CONFIG_XEN=y
CONFIG_XEN_MAX_DOMAIN_MEMORY=8
CONFIG_XEN_SAVE_RESTORE=y
# CONFIG_XEN_DEBUG_FS is not set
CONFIG_SWIOTLB_XEN=y
CONFIG_MICROCODE_XEN=y
CONFIG_XEN_DOM0=y
CONFIG_XEN_PRIVILEGED_GUEST=y
CONFIG_XEN_DOM0_PCI=y
CONFIG_XEN_PCI_PASSTHROUGH=y
CONFIG_PCI_XEN=y
CONFIG_XEN_PCIDEV_FRONTEND=y
CONFIG_XEN_BLKDEV_FRONTEND=y
CONFIG_NETXEN_NIC=m
CONFIG_XEN_NETDEV_FRONTEND=y
CONFIG_XEN_KBDDEV_FRONTEND=y
CONFIG_HVC_XEN=y
CONFIG_XEN_FBDEV_FRONTEND=y
CONFIG_XEN_BALLOON=y
CONFIG_XEN_SCRUB_PAGES=y
CONFIG_XEN_DEV_EVTCHN=y
CONFIG_XEN_BACKEND=y
CONFIG_XEN_NETDEV_BACKEND=y
CONFIG_XEN_BLKDEV_BACKEND=y
CONFIG_XEN_BLKDEV_TAP=y
CONFIG_XEN_BLKBACK_PAGEMAP=y
CONFIG_XEN_PCIDEV_BACKEND=y
CONFIG_XEN_PCIDEV_BACKEND_VPCI=y
# CONFIG_XEN_PCIDEV_BACKEND_PASS is not set
# CONFIG_XEN_PCIDEV_BACKEND_SLOT is not set
# CONFIG_XEN_PCIDEV_BACKEND_CONTROLLER is not set
# CONFIG_XEN_PCIDEV_BE_DEBUG is not set
CONFIG_XENFS=y
CONFIG_XEN_COMPAT_XENFS=y
CONFIG_XEN_SYS_HYPERVISOR=y
CONFIG_XEN_XENBUS_FRONTEND=y
# CONFIG_XEN_GNTDEV is not set
CONFIG_XEN_S3=y

BR,
Carsten.

-----Ursprüngliche Nachricht-----
Von: Carsten Schiers 
Gesendet: Samstag, 10. April 2010 11:27
An: 'Pasi Kärkkäinen'
Cc: 'xen-devel'; 'jeremy'; 'konrad.wilk'
Betreff: AW: Re: [Xen-devel] Some test results on Xen 4.0 and 2.6.31 / 
2.6.32 pvops kernels

Hi folks, some progress:

>> PCI controller / 2nd Function? / working in xen/master-2.6.32.13, not 


>> working on xen/stable-2.6.32 on Xen 3.4.1
>> 
------------------------------------------------------------------------
>> ---------------------------------------
>> 
>> It will allow passthrough of all mentioned devices except one of the 
PCI 
>> controllers. It will not be detected. Using 
>> xm pci-attach will produce an error:
>> 
>>   troi kernel: [   23.862294] ehci_hcd 0000:00:01.1: device not 
>> available because of BAR 0 [0xfc102000-0xfc1020ff] collisions
>>   troi kernel: [   61.942809] ohci_hcd 0000:00:01.0: device not 
>> available because of BAR 0 [0xfc104000-0xfc104fff] collisions
>> 
>> I first tried only with the 2nd function (or whatever it is called), 
but 
>> as you see, we have the same error with both put into 
>> the DomU.
>>
>
>Have you seen this wiki page?:
>http://wiki.xensource.com/xenwiki/XenPCIpassthrough
>
>Try the "I get "non-page-aligned MMIO BAR" error when trying to start 
the guest" thing.. maybe it helps? 

Did so and move to Xen 3.4.3-rc4 and latest 2.6.18.8 Dom0 kernel. It 
works now with pvops 2.6.32.10 DomU kernel!!! 

Thanks Pasi!!!

Eventually, you may put on the Wiki Page an example with more than one 
PCI device, so that hectic persons like
me see better that a) it's without parenthesis and b) a comma separated 
list ;o).

BR,
Carsten.




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

AW: Re: Some test results on Xen 4.0 and 2.6.31 / 2.6.32 pvops kernels

[Carsten Schiers]

Yet another note: the kernel messages that break 00:02.0 come up when I use 2.6.31 kernel,
that means, if it is passing through the 00:02.1 into the pvops DomU, it will break 00:02.0.

Please note that this will work with 2.6.18.8

BR,
Carsten.

----- Originalnachricht -----
Von: Carsten Schiers <carsten@schiers.de>
Gesendet: Son, 11.4.2010 16:45
An: xen-devel <xen-devel@lists.xensource.com>
Cc: jeremy <jeremy@goop.org> ; konrad.wilk <konrad.wilk@oracle.com>
Betreff: AW: Re: [Xen-devel] Some test results on Xen 4.0 and 2.6.31 / 2.6.32 pvops kernels

Two additional infos: here lspci of the two USB controllers. The 00:02.0 is passed into another DomU. I 
should mention that I think the 00:02.0 is going down in case I pass 00:02.1 into the 2.6.32 domain, but
not if I pass it into the 2.6.31 domain. Find what the other DomU says below.

00:02.0 USB Controller: nVidia Corporation MCP65 USB Controller (rev a3) (prog-if 10 [OHCI])
        Subsystem: Giga-byte Technology Device 5004
        Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
        Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
        Latency: 0 (750ns min, 250ns max)
        Interrupt: pin A routed to IRQ 21
        Region 0: Memory at c0200000 (32-bit, non-prefetchable) [size=4K]
        Capabilities: [44] Power Management version 2
                Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot+,D3cold+)
                Status: D0 PME-Enable- DSel=0 DScale=0 PME-
        Kernel driver in use: pciback
        Kernel modules: ohci-hcd

00:02.1 USB Controller: nVidia Corporation MCP65 USB Controller (rev a3) (prog-if 20 [EHCI])
        Subsystem: Giga-byte Technology Device 5004
        Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
        Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
        Interrupt: pin B routed to IRQ 20
        Region 0: Memory at c0201000 (32-bit, non-prefetchable) [disabled] [size=256]
        Capabilities: [44] Debug port: BAR=1 offset=0098
        Capabilities: [80] Power Management version 2
                Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot+,D3cold+)
                Status: D0 PME-Enable- DSel=0 DScale=0 PME+
        Kernel driver in use: pciback
        Kernel modules: ehci-hcd

Apr 11 16:27:26 uhura kernel: fcusb: Rx URB status: -110
Apr 11 16:27:26 uhura kernel: usb 1-2: USB disconnect, address 3
Apr 11 16:27:26 uhura kernel: kcapi: card 1 down.
Apr 11 16:27:26 uhura kernel: kcapi: Controller 1: fcusb-0003 unregistered
Apr 11 16:27:26 uhura kernel: fcusb: Driver 'fcusb' detached
Apr 11 16:27:26 uhura kernel: usb 1-2: new full speed USB device using ohci_hcd and address 4
Apr 11 16:27:27 uhura kernel: usb 1-2: configuration #1 chosen from 1 choice
Apr 11 16:27:27 uhura kernel: fcusb: Driver 'fcusb' attached to stack. (152)
Apr 11 16:27:27 uhura kernel: fcusb: Stack version 3.11-04
Apr 11 16:27:27 uhura kernel: kcapi: Controller 1: fcusb-0004 attached
Apr 11 16:27:27 uhura kernel: kcapi: card 1 "fcusb-0004" ready.
Apr 11 16:28:24 uhura kernel: fcusb: Rx URB status: -110
Apr 11 16:28:24 uhura kernel: usb 1-2: USB disconnect, address 4
Apr 11 16:28:25 uhura kernel: kcapi: card 1 down.
Apr 11 16:28:25 uhura kernel: kcapi: Controller 1: fcusb-0004 unregistered
Apr 11 16:28:25 uhura kernel: fcusb: Driver 'fcusb' detached
Apr 11 16:28:25 uhura kernel: usb 1-2: new full speed USB device using ohci_hcd and address 5
Apr 11 16:28:25 uhura kernel: usb 1-2: configuration #1 chosen from 1 choice
Apr 11 16:28:25 uhura kernel: fcusb: Driver 'fcusb' attached to stack. (152)
Apr 11 16:28:25 uhura kernel: fcusb: Stack version 3.11-04
Apr 11 16:28:25 uhura kernel: kcapi: Controller 1: fcusb-0005 attached
Apr 11 16:28:25 uhura kernel: kcapi: card 1 "fcusb-0005" ready.

BR,
Carsten.


-----Ursprüngliche Nachricht-----
Von: Carsten Schiers 
Gesendet: Sonntag, 11. April 2010 16:33
An: xen-devel
Cc: jeremy; konrad.wilk
Betreff: AW: Re: [Xen-devel] Some test results on Xen 4.0 and 2.6.31 / 2.6.32 pvops kernels

Hi,

I am sorry to say that I mixed something. What does work now is 
2.6.31.13 kernel. The error
messages are gone now for 2.6.32.11, but it is still not functioning. 

So, with the 2.6.32.11 kernel, it will not recognize the same USB 
controller that is recognized 
by 2.6.31.13. 

When booting:

[    0.168388] pcifront pci-0: Creating PCI Frontend Bus 0000:00
[    0.325746]   alloc irq_desc for 503 on node 0
[    0.325753]   alloc kstat_irqs on node 0

When I detach and attach from Dom0, it will log in the DomU:

[  202.660279] pcifront pci-0: Rescanning PCI Frontend Bus 0000:00
[  202.848550] pcifront pci-0: backend going away!
[  202.857153] pcifront pci-0: Disconnecting PCI Frontend Buses
[  202.903310] pcifront pci-0: 22 freeing event channel 9
[  224.234600] pcifront pci-0: Installing PCI frontend
[  224.237069] pcifront pci-0: Creating PCI Frontend Bus 0000:00

In Dom0 we have:

ACPI: PCI interrupt for device 0000:00:02.1 disabled
pciback: vpci: 0000:00:02.1: assign to virtual slot 0

For reference, the log entries when I detach/attach the device in 
2.6.31.13:

[   47.250686] usb usb1: USB disconnect, address 1
[   47.251155] ehci_hcd 0000:00:00.1: USB bus 1 deregistered
[   47.349616] pcifront pci-0: Rescanning PCI Frontend Bus 0000:00
[   47.938006] pcifront pci-0: backend going away!
[   47.941640] pcifront pci-0: Disconnecting PCI Frontend Buses
[   47.946981] pcifront pci-0: Device is in 6 state. Need to change 
state on the privileged domain.
[   47.952364] pcifront pci-0: Device is in 0 state. Need to change 
state on the privileged domain.
[   47.957636] pcifront pci-0: 22 freeing event channel 9
[   58.832396] pcifront pci-0: Device is in 2 state. Need to change 
state on the privileged domain.
[   58.840387] pcifront pci-0: Device is in 3 state. Need to change 
state on the privileged domain.
[   58.868584] pcifront pci-0: Installing PCI frontend
[   58.869661] pcifront pci-0: Creating PCI Frontend Bus 0000:00
[   59.487005] ehci_hcd 0000:00:00.1: enabling device (0000 -> 0002)
[   59.487005] ehci_hcd 0000:00:00.1: Xen PCI enabling IRQ: 20
[   59.487005] xen_allocate_pirq: returning irq 20 for gsi 20
[   59.487005] ehci_hcd 0000:00:00.1: EHCI Host Controller
[   59.491270] ehci_hcd 0000:00:00.1: new USB bus registered, assigned 
bus number 1
[   59.491409] ehci_hcd 0000:00:00.1: Enabling legacy PCI PM
[   59.491462] ehci_hcd 0000:00:00.1: debug port 1
[   59.491534] ehci_hcd 0000:00:00.1: irq 20, io mem 0xc0201000
[   59.497088] ehci_hcd 0000:00:00.1: USB 2.0 started, EHCI 1.00
[   59.497182] usb usb1: New USB device found, idVendor=1d6b, 
idProduct=0002
[   59.497194] usb usb1: New USB device strings: Mfr=3, Product=2, 
SerialNumber=1
[   59.497207] usb usb1: Product: EHCI Host Controller
[   59.497216] usb usb1: Manufacturer: Linux 2.6.31.13-pvops-686 
ehci_hcd
[   59.497228] usb usb1: SerialNumber: 0000:00:00.1
[   59.497363] usb usb1: configuration #1 chosen from 1 choice
[   59.497447] hub 1-0:1.0: USB hub found
[   59.497643] hub 1-0:1.0: 10 ports detected

Relevant XEN config entries in 2.6.32.11:

CONFIG_XEN=y
CONFIG_XEN_MAX_DOMAIN_MEMORY=8
CONFIG_XEN_SAVE_RESTORE=y
# CONFIG_XEN_DEBUG_FS is not set
CONFIG_SWIOTLB_XEN=y
CONFIG_MICROCODE_XEN=y
CONFIG_XEN_DOM0=y
CONFIG_XEN_PRIVILEGED_GUEST=y
CONFIG_XEN_DOM0_PCI=y
CONFIG_XEN_PCI_PASSTHROUGH=y
CONFIG_PCI_XEN=y
CONFIG_XEN_PCIDEV_FRONTEND=y
CONFIG_XEN_BLKDEV_FRONTEND=y
CONFIG_NETXEN_NIC=m
CONFIG_XEN_NETDEV_FRONTEND=y
CONFIG_XEN_KBDDEV_FRONTEND=y
CONFIG_HVC_XEN=y
CONFIG_XEN_FBDEV_FRONTEND=y
CONFIG_XEN_BALLOON=y
CONFIG_XEN_SCRUB_PAGES=y
CONFIG_XEN_DEV_EVTCHN=y
CONFIG_XEN_BACKEND=y
CONFIG_XEN_NETDEV_BACKEND=y
CONFIG_XEN_BLKDEV_BACKEND=y
CONFIG_XEN_BLKDEV_TAP=y
CONFIG_XEN_BLKBACK_PAGEMAP=y
CONFIG_XEN_PCIDEV_BACKEND=y
CONFIG_XEN_PCIDEV_BACKEND_VPCI=y
# CONFIG_XEN_PCIDEV_BACKEND_PASS is not set
# CONFIG_XEN_PCIDEV_BACKEND_SLOT is not set
# CONFIG_XEN_PCIDEV_BACKEND_CONTROLLER is not set
# CONFIG_XEN_PCIDEV_BE_DEBUG is not set
CONFIG_XENFS=y
CONFIG_XEN_COMPAT_XENFS=y
CONFIG_XEN_SYS_HYPERVISOR=y
CONFIG_XEN_XENBUS_FRONTEND=y
# CONFIG_XEN_GNTDEV is not set
CONFIG_XEN_S3=y

BR,
Carsten.

-----Ursprüngliche Nachricht-----
Von: Carsten Schiers 
Gesendet: Samstag, 10. April 2010 11:27
An: 'Pasi Kärkkäinen'
Cc: 'xen-devel'; 'jeremy'; 'konrad.wilk'
Betreff: AW: Re: [Xen-devel] Some test results on Xen 4.0 and 2.6.31 / 
2.6.32 pvops kernels

Hi folks, some progress:

>> PCI controller / 2nd Function? / working in xen/master-2.6.32.13, not 

>> working on xen/stable-2.6.32 on Xen 3.4.1
>> 
------------------------------------------------------------------------
>> ---------------------------------------
>> 
>> It will allow passthrough of all mentioned devices except one of the 
PCI 
>> controllers. It will not be detected. Using 
>> xm pci-attach will produce an error:
>> 
>>   troi kernel: [   23.862294] ehci_hcd 0000:00:01.1: device not 
>> available because of BAR 0 [0xfc102000-0xfc1020ff] collisions
>>   troi kernel: [   61.942809] ohci_hcd 0000:00:01.0: device not 
>> available because of BAR 0 [0xfc104000-0xfc104fff] collisions
>> 
>> I first tried only with the 2nd function (or whatever it is called), 
but 
>> as you see, we have the same error with both put into 
>> the DomU.
>>
>
>Have you seen this wiki page?:
>http://wiki.xensource.com/xenwiki/XenPCIpassthrough
>
>Try the "I get "non-page-aligned MMIO BAR" error when trying to start 
the guest" thing.. maybe it helps? 

Did so and move to Xen 3.4.3-rc4 and latest 2.6.18.8 Dom0 kernel. It 
works now with pvops 2.6.32.10 DomU kernel!!! 

Thanks Pasi!!!

Eventually, you may put on the Wiki Page an example with more than one 
PCI device, so that hectic persons like
me see better that a) it's without parenthesis and b) a comma separated 
list ;o).

BR,
Carsten.




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Re: Re: Some test results on Xen 4.0 and 2.6.31 / 2.6.32 pvops kernels

[Pasi Kärkkäinen]

On Mon, Apr 12, 2010 at 03:01:33PM +0200, Carsten Schiers wrote:
> Yet another note: the kernel messages that break 00:02.0 come up when I use 2.6.31 kernel,
> that means, if it is passing through the 00:02.1 into the pvops DomU, it will break 00:02.0.
> 
> Please note that this will work with 2.6.18.8
> 

Maybe both of these devices need to be passed through at the same time to the same guest, 
since they're part of the same device? 

-- Pasi


> BR,
> Carsten.
> 
> ----- Originalnachricht -----
> Von: Carsten Schiers <carsten@schiers.de>
> Gesendet: Son, 11.4.2010 16:45
> An: xen-devel <xen-devel@lists.xensource.com>
> Cc: jeremy <jeremy@goop.org> ; konrad.wilk <konrad.wilk@oracle.com>
> Betreff: AW: Re: [Xen-devel] Some test results on Xen 4.0 and 2.6.31 / 2.6.32 pvops kernels
> 
> Two additional infos: here lspci of the two USB controllers. The 00:02.0 is passed into another DomU. I 
> should mention that I think the 00:02.0 is going down in case I pass 00:02.1 into the 2.6.32 domain, but
> not if I pass it into the 2.6.31 domain. Find what the other DomU says below.
> 
> 00:02.0 USB Controller: nVidia Corporation MCP65 USB Controller (rev a3) (prog-if 10 [OHCI])
>         Subsystem: Giga-byte Technology Device 5004
>         Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
>         Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
>         Latency: 0 (750ns min, 250ns max)
>         Interrupt: pin A routed to IRQ 21
>         Region 0: Memory at c0200000 (32-bit, non-prefetchable) [size=4K]
>         Capabilities: [44] Power Management version 2
>                 Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot+,D3cold+)
>                 Status: D0 PME-Enable- DSel=0 DScale=0 PME-
>         Kernel driver in use: pciback
>         Kernel modules: ohci-hcd
> 
> 00:02.1 USB Controller: nVidia Corporation MCP65 USB Controller (rev a3) (prog-if 20 [EHCI])
>         Subsystem: Giga-byte Technology Device 5004
>         Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
>         Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
>         Interrupt: pin B routed to IRQ 20
>         Region 0: Memory at c0201000 (32-bit, non-prefetchable) [disabled] [size=256]
>         Capabilities: [44] Debug port: BAR=1 offset=0098
>         Capabilities: [80] Power Management version 2
>                 Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot+,D3cold+)
>                 Status: D0 PME-Enable- DSel=0 DScale=0 PME+
>         Kernel driver in use: pciback
>         Kernel modules: ehci-hcd
> 
> Apr 11 16:27:26 uhura kernel: fcusb: Rx URB status: -110
> Apr 11 16:27:26 uhura kernel: usb 1-2: USB disconnect, address 3
> Apr 11 16:27:26 uhura kernel: kcapi: card 1 down.
> Apr 11 16:27:26 uhura kernel: kcapi: Controller 1: fcusb-0003 unregistered
> Apr 11 16:27:26 uhura kernel: fcusb: Driver 'fcusb' detached
> Apr 11 16:27:26 uhura kernel: usb 1-2: new full speed USB device using ohci_hcd and address 4
> Apr 11 16:27:27 uhura kernel: usb 1-2: configuration #1 chosen from 1 choice
> Apr 11 16:27:27 uhura kernel: fcusb: Driver 'fcusb' attached to stack. (152)
> Apr 11 16:27:27 uhura kernel: fcusb: Stack version 3.11-04
> Apr 11 16:27:27 uhura kernel: kcapi: Controller 1: fcusb-0004 attached
> Apr 11 16:27:27 uhura kernel: kcapi: card 1 "fcusb-0004" ready.
> Apr 11 16:28:24 uhura kernel: fcusb: Rx URB status: -110
> Apr 11 16:28:24 uhura kernel: usb 1-2: USB disconnect, address 4
> Apr 11 16:28:25 uhura kernel: kcapi: card 1 down.
> Apr 11 16:28:25 uhura kernel: kcapi: Controller 1: fcusb-0004 unregistered
> Apr 11 16:28:25 uhura kernel: fcusb: Driver 'fcusb' detached
> Apr 11 16:28:25 uhura kernel: usb 1-2: new full speed USB device using ohci_hcd and address 5
> Apr 11 16:28:25 uhura kernel: usb 1-2: configuration #1 chosen from 1 choice
> Apr 11 16:28:25 uhura kernel: fcusb: Driver 'fcusb' attached to stack. (152)
> Apr 11 16:28:25 uhura kernel: fcusb: Stack version 3.11-04
> Apr 11 16:28:25 uhura kernel: kcapi: Controller 1: fcusb-0005 attached
> Apr 11 16:28:25 uhura kernel: kcapi: card 1 "fcusb-0005" ready.
> 
> BR,
> Carsten.
> 
> 
> -----Ursprüngliche Nachricht-----
> Von: Carsten Schiers 
> Gesendet: Sonntag, 11. April 2010 16:33
> An: xen-devel
> Cc: jeremy; konrad.wilk
> Betreff: AW: Re: [Xen-devel] Some test results on Xen 4.0 and 2.6.31 / 2.6.32 pvops kernels
> 
> Hi,
> 
> I am sorry to say that I mixed something. What does work now is 
> 2.6.31.13 kernel. The error
> messages are gone now for 2.6.32.11, but it is still not functioning. 
> 
> So, with the 2.6.32.11 kernel, it will not recognize the same USB 
> controller that is recognized 
> by 2.6.31.13. 
> 
> When booting:
> 
> [    0.168388] pcifront pci-0: Creating PCI Frontend Bus 0000:00
> [    0.325746]   alloc irq_desc for 503 on node 0
> [    0.325753]   alloc kstat_irqs on node 0
> 
> When I detach and attach from Dom0, it will log in the DomU:
> 
> [  202.660279] pcifront pci-0: Rescanning PCI Frontend Bus 0000:00
> [  202.848550] pcifront pci-0: backend going away!
> [  202.857153] pcifront pci-0: Disconnecting PCI Frontend Buses
> [  202.903310] pcifront pci-0: 22 freeing event channel 9
> [  224.234600] pcifront pci-0: Installing PCI frontend
> [  224.237069] pcifront pci-0: Creating PCI Frontend Bus 0000:00
> 
> In Dom0 we have:
> 
> ACPI: PCI interrupt for device 0000:00:02.1 disabled
> pciback: vpci: 0000:00:02.1: assign to virtual slot 0
> 
> For reference, the log entries when I detach/attach the device in 
> 2.6.31.13:
> 
> [   47.250686] usb usb1: USB disconnect, address 1
> [   47.251155] ehci_hcd 0000:00:00.1: USB bus 1 deregistered
> [   47.349616] pcifront pci-0: Rescanning PCI Frontend Bus 0000:00
> [   47.938006] pcifront pci-0: backend going away!
> [   47.941640] pcifront pci-0: Disconnecting PCI Frontend Buses
> [   47.946981] pcifront pci-0: Device is in 6 state. Need to change 
> state on the privileged domain.
> [   47.952364] pcifront pci-0: Device is in 0 state. Need to change 
> state on the privileged domain.
> [   47.957636] pcifront pci-0: 22 freeing event channel 9
> [   58.832396] pcifront pci-0: Device is in 2 state. Need to change 
> state on the privileged domain.
> [   58.840387] pcifront pci-0: Device is in 3 state. Need to change 
> state on the privileged domain.
> [   58.868584] pcifront pci-0: Installing PCI frontend
> [   58.869661] pcifront pci-0: Creating PCI Frontend Bus 0000:00
> [   59.487005] ehci_hcd 0000:00:00.1: enabling device (0000 -> 0002)
> [   59.487005] ehci_hcd 0000:00:00.1: Xen PCI enabling IRQ: 20
> [   59.487005] xen_allocate_pirq: returning irq 20 for gsi 20
> [   59.487005] ehci_hcd 0000:00:00.1: EHCI Host Controller
> [   59.491270] ehci_hcd 0000:00:00.1: new USB bus registered, assigned 
> bus number 1
> [   59.491409] ehci_hcd 0000:00:00.1: Enabling legacy PCI PM
> [   59.491462] ehci_hcd 0000:00:00.1: debug port 1
> [   59.491534] ehci_hcd 0000:00:00.1: irq 20, io mem 0xc0201000
> [   59.497088] ehci_hcd 0000:00:00.1: USB 2.0 started, EHCI 1.00
> [   59.497182] usb usb1: New USB device found, idVendor=1d6b, 
> idProduct=0002
> [   59.497194] usb usb1: New USB device strings: Mfr=3, Product=2, 
> SerialNumber=1
> [   59.497207] usb usb1: Product: EHCI Host Controller
> [   59.497216] usb usb1: Manufacturer: Linux 2.6.31.13-pvops-686 
> ehci_hcd
> [   59.497228] usb usb1: SerialNumber: 0000:00:00.1
> [   59.497363] usb usb1: configuration #1 chosen from 1 choice
> [   59.497447] hub 1-0:1.0: USB hub found
> [   59.497643] hub 1-0:1.0: 10 ports detected
> 
> Relevant XEN config entries in 2.6.32.11:
> 
> CONFIG_XEN=y
> CONFIG_XEN_MAX_DOMAIN_MEMORY=8
> CONFIG_XEN_SAVE_RESTORE=y
> # CONFIG_XEN_DEBUG_FS is not set
> CONFIG_SWIOTLB_XEN=y
> CONFIG_MICROCODE_XEN=y
> CONFIG_XEN_DOM0=y
> CONFIG_XEN_PRIVILEGED_GUEST=y
> CONFIG_XEN_DOM0_PCI=y
> CONFIG_XEN_PCI_PASSTHROUGH=y
> CONFIG_PCI_XEN=y
> CONFIG_XEN_PCIDEV_FRONTEND=y
> CONFIG_XEN_BLKDEV_FRONTEND=y
> CONFIG_NETXEN_NIC=m
> CONFIG_XEN_NETDEV_FRONTEND=y
> CONFIG_XEN_KBDDEV_FRONTEND=y
> CONFIG_HVC_XEN=y
> CONFIG_XEN_FBDEV_FRONTEND=y
> CONFIG_XEN_BALLOON=y
> CONFIG_XEN_SCRUB_PAGES=y
> CONFIG_XEN_DEV_EVTCHN=y
> CONFIG_XEN_BACKEND=y
> CONFIG_XEN_NETDEV_BACKEND=y
> CONFIG_XEN_BLKDEV_BACKEND=y
> CONFIG_XEN_BLKDEV_TAP=y
> CONFIG_XEN_BLKBACK_PAGEMAP=y
> CONFIG_XEN_PCIDEV_BACKEND=y
> CONFIG_XEN_PCIDEV_BACKEND_VPCI=y
> # CONFIG_XEN_PCIDEV_BACKEND_PASS is not set
> # CONFIG_XEN_PCIDEV_BACKEND_SLOT is not set
> # CONFIG_XEN_PCIDEV_BACKEND_CONTROLLER is not set
> # CONFIG_XEN_PCIDEV_BE_DEBUG is not set
> CONFIG_XENFS=y
> CONFIG_XEN_COMPAT_XENFS=y
> CONFIG_XEN_SYS_HYPERVISOR=y
> CONFIG_XEN_XENBUS_FRONTEND=y
> # CONFIG_XEN_GNTDEV is not set
> CONFIG_XEN_S3=y
> 
> BR,
> Carsten.
> 
> -----Ursprüngliche Nachricht-----
> Von: Carsten Schiers 
> Gesendet: Samstag, 10. April 2010 11:27
> An: 'Pasi Kärkkäinen'
> Cc: 'xen-devel'; 'jeremy'; 'konrad.wilk'
> Betreff: AW: Re: [Xen-devel] Some test results on Xen 4.0 and 2.6.31 / 
> 2.6.32 pvops kernels
> 
> Hi folks, some progress:
> 
> >> PCI controller / 2nd Function? / working in xen/master-2.6.32.13, not 
> 
> >> working on xen/stable-2.6.32 on Xen 3.4.1
> >> 
> ------------------------------------------------------------------------
> >> ---------------------------------------
> >> 
> >> It will allow passthrough of all mentioned devices except one of the 
> PCI 
> >> controllers. It will not be detected. Using 
> >> xm pci-attach will produce an error:
> >> 
> >>   troi kernel: [   23.862294] ehci_hcd 0000:00:01.1: device not 
> >> available because of BAR 0 [0xfc102000-0xfc1020ff] collisions
> >>   troi kernel: [   61.942809] ohci_hcd 0000:00:01.0: device not 
> >> available because of BAR 0 [0xfc104000-0xfc104fff] collisions
> >> 
> >> I first tried only with the 2nd function (or whatever it is called), 
> but 
> >> as you see, we have the same error with both put into 
> >> the DomU.
> >>
> >
> >Have you seen this wiki page?:
> >http://wiki.xensource.com/xenwiki/XenPCIpassthrough
> >
> >Try the "I get "non-page-aligned MMIO BAR" error when trying to start 
> the guest" thing.. maybe it helps? 
> 
> Did so and move to Xen 3.4.3-rc4 and latest 2.6.18.8 Dom0 kernel. It 
> works now with pvops 2.6.32.10 DomU kernel!!! 
> 
> Thanks Pasi!!!
> 
> Eventually, you may put on the Wiki Page an example with more than one 
> PCI device, so that hectic persons like
> me see better that a) it's without parenthesis and b) a comma separated 
> list ;o).
> 
> BR,
> Carsten.
> 
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel