Xen devel - Oct 2009 - Request for backport of 82599 quirks to 3.4.2

Keir,
 
I''d like to request that changset
http://xenbits.xensource.com/xen-unstable.hg?rev/091209f1b95c from xen unstable
be backported to the 3.4.2 release.
 
Ian,
 
I would also need the changes to pass-through.c in qemu backported.  The git
commit is a77dc89dde1b8b9331c0f746e34389d6a253755f from Aug. 4.
 
commit a77dc89dde1b8b9331c0f746e34389d6a253755f
Author: Ian Jackson <ian.jackson@eu.citrix.com>
Date:   Tue Aug 4 15:28:14 2009 +0100
 
    passthrough: support the assignment of the VF of Intel 82599 10GbE Controlle
    
    The datasheet is available at
    http://download.intel.com/design/network/datashts/82599_datasheet.pdf
    
    See ''Table 9.7. VF PCIe Configuration Space'' of the
datasheet, the PCI
    Express Capability Structure of the VF of Intel 82599 10GbE Controller looks
    trivial, e.g., the PCI Express Capabilities Register is 0, so the Capability
    Version is 0 and pt_pcie_size_init() would fail.
    
    We should not try to expose the PCIe cap of the device to guest.
    
    Signed-off-by: Dexuan Cui <dexuan.cui@intel.com>
 
This will allow us and other interested parties to develop and test our 82599
10Gbe adapters on Xen 3.4.2 stable when it becomes available.

Thanks,

- Greg Rose
Lan Access Division (LAD)
Intel Corp.


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

Rose, Gregory V writes ("Request for backport of 82599 quirks to
3.4.2"):
> commit a77dc89dde1b8b9331c0f746e34389d6a253755f
> Author: Ian Jackson <ian.jackson@eu.citrix.com>
> Date:   Tue Aug 4 15:28:14 2009 +0100
>  
>     passthrough: support the assignment of the VF of Intel 82599 10GbE
Controlle
If I remember rightly this was a quirk of this particular card.  I''d
be quite fine with putting that in the 3.4.x branch.

Just so we are clear: these two backports both serve the same purpose
but as far as I can tell having either of them separately is no worse
than having neither ?  So there''s no need to coordinate the change
across the trees ?

Thanks,
Ian.

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

Well they''re both required to pass a VF device through to a guest and
then have the VF device properly reset via FLR when the guest is destroyed or
shut down.  If the qemu quirk to allow pass through of the VF device is
committed without the associated quirk in pci.py to go ahead and issue and FLR
then there is a possibility that a VF device could be left in some unknown
state.  It''s a low probability I think but it does seem to exist.

- Greg
>-----Original Message-----
>From: Ian Jackson [mailto:Ian.Jackson@eu.citrix.com] 
>Sent: Thursday, October 22, 2009 10:36 AM
>To: Rose, Gregory V
>Cc: xen-devel@lists.xensource.com
>Subject: Re: Request for backport of 82599 quirks to 3.4.2
>
>Rose, Gregory V writes ("Request for backport of 82599 quirks 
>to 3.4.2"):
>> commit a77dc89dde1b8b9331c0f746e34389d6a253755f
>> Author: Ian Jackson <ian.jackson@eu.citrix.com>
>> Date:   Tue Aug 4 15:28:14 2009 +0100
>>  
>>     passthrough: support the assignment of the VF of Intel 
>82599 10GbE Controlle
>
>If I remember rightly this was a quirk of this particular card. 
I''d
>be quite fine with putting that in the 3.4.x branch.
>
>Just so we are clear: these two backports both serve the same purpose
>but as far as I can tell having either of them separately is no worse
>than having neither ?  So there''s no need to coordinate the change
>across the trees ?
>
>Thanks,
>Ian.
>
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Rose, Gregory V writes ("[Xen-devel] RE: Request for backport of 82599
quirks to 3.4.2"):
> Well they''re both required to pass a VF device through to a guest
and then have the VF device properly reset via FLR when the guest is destroyed
or shut down.  If the qemu quirk to allow pass through of the VF device is
committed without the associated quirk in pci.py to go ahead and issue and FLR
then there is a possibility that a VF device could be left in some unknown
state.  It''s a low probability I think but it does seem to exist.
Thanks for thinking about that.  Well, I''ll hold off until Keir
decides, in that case.

Ian.

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

On 22/10/2009 18:58, "Ian Jackson" <Ian.Jackson@eu.citrix.com>
wrote:
> Rose, Gregory V writes ("[Xen-devel] RE: Request for backport of 82599
quirks
> to 3.4.2"):
>> Well they''re both required to pass a VF device through to a
guest and then
>> have the VF device properly reset via FLR when the guest is destroyed
or shut
>> down.  If the qemu quirk to allow pass through of the VF device is
committed
>> without the associated quirk in pci.py to go ahead and issue and FLR
then
>> there is a possibility that a VF device could be left in some unknown
state.
>> It''s a low probability I think but it does seem to exist.
> 
> Thanks for thinking about that.  Well, I''ll hold off until Keir
> decides, in that case.
The only sync points that matter in 3.4-testing now are the -rc tags. So go
ahead and check it in and we''ll sync on -rc2.

 -- Keir



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