Add a helper function in PCI IOV to get VF device
in [Kernel]
|
Prev: linux-next: manual merge of the drbd tree with Linus' tree
Next: [RFC] lp_events: an lternitive to suspend blocker user mode and kernel API
From: Frank Pan on 3 Jun 2010 22:30 > Frank, I still don't understand what you're trying to do here. What's the use case? What is the end goal that you're trying to get to? > > What information do you need about the VF, and why? �SR-IOV works properly today without this stuff. > > If we can understand what you're trying to do, then maybe we can help. Sorry, I used to think of this issue is common, but maybe not. I'm hacking igb to add support of VF migration. Migration is emerging as a standard of PCI IOV, but has not implemented in intel 82576(igb). The idea is interact with VF's MMIO/PCI configuration in the physical machine, which only PF's driver exists. This work started by userspace. All I know is the PCI BDF of the VF, because give BDF to the VMM is enough to assign a VF to a VM. So here comes the first issue, neither userspace nor PF driver knows the map from VF's ID to BDF. My plan is communicating with PF's driver by sysfs, so I repeatly complain about the sysfs issue. PF can access VF's BAR when it knows VF's ID. On the other hand, PF can access VF's PCI configuration only when if knows VF's BDF. This is the second issue. Even when userspace calculated and gave it an id, PF driver still cannot access the PCI configuration of VF. Really thanks for your help. I'm new on both kernel scope and English scope. :) -- Frank Pan Computer Science and Technology Tsinghua University -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Frank Pan on 3 Jun 2010 22:50 > VF is often loaded on the physical machine. �There's also a networking > specific mechanism for querying and configuring a VF via the PF. ? I don't really understand. What do you mean load? I don't think physical machine is able to use it as a hardware device. > While your patch is simple, it's unclear to me what your end goal is. > The patch itself only adds a function. if you showed how you are > planning to use it, that would really help. Currently my hack is applied on 2.6.18 because of xen's limitation. As Mitch says, igb driver is significantly different with recent ones. On the other hand, my hack just exposes several PCI configuration and MMIO registers to the sysfs, you will only understand the use case when you also see the userspace hacks. > It's especially confusing that you are comparing your patch with > symlinks visible in sysfs. That's my fault. The most recent reply explains it. Thanks for reply. -- Frank Pan Computer Science and Technology Tsinghua University -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Jesse Barnes on 8 Jun 2010 17:40 On Tue, 1 Jun 2010 13:05:25 +0800 Frank Pan <frankpzh(a)gmail.com> wrote: > Greetings, > > The motivation is make VF device visible to PF driver. PF driver > may need this to access VF's PCI configuration. > Another use case is in sysfs symbolic linking. Some of VF's sysfs > entries are created by PF driver. For example, /sys/class/net/ethx/vfx > in Intel 82576 NIC driver. Makeing a symbolic link from VF's pci device > to this path also must be done in PF's driver. > > Currently, there is no hint about VF's bus/devfn in PF's pci_dev. > The offset and stride entries(which are used to calculate bus/devfn > of VF devices) in VF's PCI configuration is also invisible in PF's > driver. So IMO this helper function is needed. > > Any reply is appreciated, THX. > > (ps: gmail will do line wrap/tab replace, use attachment instead to patch) Per the discussion in this thread it sounds like this really has nothing to do with sysfs and more to do with being a convenient API for drivers. Is that correct? If so, and assuming there's not some other way of getting this info from a driver, I'm ok with it, but it should be submitted as part of a patchset including driver code that uses it. -- Jesse Barnes, Intel Open Source Technology Center -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Chris Wright on 8 Jun 2010 18:20 * Frank Pan (frankpzh(a)gmail.com) wrote: > > VF is often loaded on the physical machine. �There's also a networking > > specific mechanism for querying and configuring a VF via the PF. > ? I don't really understand. What do you mean load? I don't think > physical machine is able to use it as a hardware device. Yes, it is possible. Your example of igb...igbvf driver can be loaded on physical machine and drive a VF instance. In fact, this is a pretty normal mode for KVM. > > While your patch is simple, it's unclear to me what your end goal is. > > The patch itself only adds a function. if you showed how you are > > planning to use it, that would really help. > Currently my hack is applied on 2.6.18 because of xen's limitation. As > Mitch says, igb driver is significantly different with recent ones. On > the other hand, my hack just exposes several PCI configuration and > MMIO registers to the sysfs, you will only understand the use case > when you also see the userspace hacks. OK, but this sounds like the wrong approach. We already have a mechanism for using the PF to program a VF. Have a look at the netlink interface. Specifically, do_setvfinfo(). thanks, -chris -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Frank Pan on 11 Jun 2010 03:50
> Per the discussion in this thread it sounds like this really has > nothing to do with sysfs and more to do with being a convenient API for > drivers. Yes. > Is that correct? If so, and assuming there's not some other way of > getting this info from a driver, I'm ok with it, but it should be > submitted as part of a patchset including driver code that uses it. Yes, I may submit them all after the driver hack is complete. I put the issue here to get response of some thing like, is this change possible? or is there a better way to do it? Thanks for reply. -- Frank Pan Computer Science and Technology Tsinghua University -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |