lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Fri, 16 Dec 2016 18:39:42 +0000 From: KY Srinivasan <kys@...rosoft.com> To: Haiyang Zhang <haiyangz@...rosoft.com>, Stephen Hemminger <stephen@...workplumber.org>, Greg KH <gregkh@...uxfoundation.org> CC: "olaf@...fle.de" <olaf@...fle.de>, "jasowang@...hat.com" <jasowang@...hat.com>, "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>, "bjorn.helgaas@...il.com" <bjorn.helgaas@...il.com>, "apw@...onical.com" <apw@...onical.com>, "devel@...uxdriverproject.org" <devel@...uxdriverproject.org>, "leann.ogasawara@...onical.com" <leann.ogasawara@...onical.com> Subject: RE: [PATCH 3/3] hv_netvsc: Implement VF matching based on serial numbers > -----Original Message----- > From: Haiyang Zhang > Sent: Friday, December 16, 2016 7:21 AM > To: KY Srinivasan <kys@...rosoft.com>; Stephen Hemminger > <stephen@...workplumber.org>; Greg KH <gregkh@...uxfoundation.org> > Cc: olaf@...fle.de; jasowang@...hat.com; linux-kernel@...r.kernel.org; > bjorn.helgaas@...il.com; apw@...onical.com; > devel@...uxdriverproject.org; leann.ogasawara@...onical.com > Subject: RE: [PATCH 3/3] hv_netvsc: Implement VF matching based on serial > numbers > > > > > -----Original Message----- > > From: KY Srinivasan > > Sent: Thursday, December 15, 2016 8:11 PM > > To: Stephen Hemminger <stephen@...workplumber.org>; Greg KH > > <gregkh@...uxfoundation.org> > > Cc: olaf@...fle.de; jasowang@...hat.com; linux-kernel@...r.kernel.org; > > bjorn.helgaas@...il.com; apw@...onical.com; > devel@...uxdriverproject.org; > > leann.ogasawara@...onical.com; Haiyang Zhang > <haiyangz@...rosoft.com> > > Subject: RE: [PATCH 3/3] hv_netvsc: Implement VF matching based on > > serial numbers > > > > > > > > > -----Original Message----- > > > From: devel [mailto:driverdev-devel-bounces@...uxdriverproject.org] > On > > > Behalf Of Stephen Hemminger > > > Sent: Wednesday, December 14, 2016 3:52 PM > > > To: Greg KH <gregkh@...uxfoundation.org> > > > Cc: olaf@...fle.de; jasowang@...hat.com; linux- > kernel@...r.kernel.org; > > > bjorn.helgaas@...il.com; apw@...onical.com; > > > devel@...uxdriverproject.org; leann.ogasawara@...onical.com; Haiyang > > > Zhang <haiyangz@...rosoft.com> > > > Subject: Re: [PATCH 3/3] hv_netvsc: Implement VF matching based on > > serial > > > numbers > > > > > > Normally, that would work but in this case we have one driver (netvsc) > > > which is managing another driver which is unaware of Hyper-V or netvsc > > > drivers existence. The callback is happening in netvsc driver and it > > > needs to say "hey I know that SR-IOV device, it is associated with my > > > network device". This problem is how to know that N is associated with > > > V? The V device has to be a network device, that is easy. But then it > > > also has to be a PCI device, not to bad. But then the netvsc code > > > is matching based on hyper-V only PCI bus metadata (the serial #). > > > > > > The Microsoft developers made the rational decision not to go > > modifying > > > all the possible SR-IOV network devices from Intel and Mellanox to add > > > the functionality there. That would have been much worse. > > > > > > Maybe, rather than trying to do the management in the kernel it > > > could have been done better in user space. Unfortunately, this would > > > only move the problem. The PCI-hyperv host driver could expose serial > > > value through sysfs (with some pain). But the problem would be how > > > to make a new API to join the two V and N device. Doing a private > > > ioctl is worse than the notifier. > > > > All this has been discussed earlier in the thread. I think I have a > > solution > > to the problem: > > The only PCI (non-VF) NIC that may be present in the VM is the emulated > > NIC and > > we know exactly the device ID and vendor ID of this NIC. Furthermore, > > as a platform we are not going to be emulating additional NICs. So, > > if the PCI NIC is not the emulated NIC, it must be a VF and we can > > extract the > > serial number. > > How about direct pass-through NIC devices. Do they have vPCI serial > number? > And, the numbers should be different from VF NIC? This may not have a valid serial number; but is still a descendent of vmbus. K. Y > > Thanks, > - Haiyang
Powered by blists - more mailing lists