On 10/02/2017 03:10 PM, David Woodhouse wrote:
On Mon, 2017-10-02 at 14:52 -0400, Don Dutile wrote:
On 10/02/2017 08:35 AM, David Woodhouse wrote:
This would allow you to enable SR-IOV on a PF before its driver is
loaded, right? Even when that driver *is* going to need to perform
resource manag
On Mon, 2017-10-02 at 14:52 -0400, Don Dutile wrote:
> On 10/02/2017 08:35 AM, David Woodhouse wrote:
> > This would allow you to enable SR-IOV on a PF before its driver is
> > loaded, right? Even when that driver *is* going to need to perform
> > resource management for those VFs?
> >
> > Would e
On 10/02/2017 08:35 AM, David Woodhouse wrote:
On Thu, 2017-09-28 at 12:56 -0400, Don Dutile wrote:
Well, my point is more like: why put it in uio?
why not make it available via pcie, setup while/if no driver attached?
i.e., other non-uio users can use the mechanism like libvirt? ...
if a PF
On Thu, 2017-09-28 at 12:56 -0400, Don Dutile wrote:
> Well, my point is more like: why put it in uio?
> why not make it available via pcie, setup while/if no driver attached?
> i.e., other non-uio users can use the mechanism like libvirt? ...
> if a PF driver isn't required.
This would allow
On 09/28/2017 11:52 AM, David Woodhouse wrote:
On Thu, 2017-09-28 at 11:05 -0400, Don Dutile wrote:
ah, nickel summary: no in-kernel driver w/.sriov-configure method.
if so, now I'm up to speed with you
h
so, that would imply we need an in-kernel, pcie-common, .sriov-
configure metho
On Thu, 2017-09-28 at 11:05 -0400, Don Dutile wrote:
> ah, nickel summary: no in-kernel driver w/.sriov-configure method.
> if so, now I'm up to speed with you
> h
> so, that would imply we need an in-kernel, pcie-common, .sriov-
> configure method
> that's invoked if a driver isn't bou
On 09/28/2017 09:46 AM, David Woodhouse wrote:
On Thu, 2017-09-28 at 08:22 -0400, Don Dutile wrote:
After reading Alex's response, I now understand Dave's question
better and why the patch won't work in general.
UIO doesn't work "in general". It requires a very *specific* userspace
driver for
On Thu, 2017-09-28 at 08:22 -0400, Don Dutile wrote:
>
> After reading Alex's response, I now understand Dave's question
> better and why the patch won't work in general.
UIO doesn't work "in general". It requires a very *specific* userspace
driver for the hardware in question, which needs to kno
On 09/27/2017 07:06 PM, Alexander Duyck wrote:
On Wed, Sep 27, 2017 at 3:20 PM, David Woodhouse wrote:
On Wed, 2017-09-27 at 17:00 -0500, Bjorn Helgaas wrote:
IIUC, this question is basically "why doesn't the PCI core enable IOV
automatically when it sees an IOV-capable device?"
I think one
On 09/27/2017 06:00 PM, Bjorn Helgaas wrote:
[+cc Don, Alex D, Alex W, Bryant, Bodong, Michael, kvm list]
On Wed, Sep 27, 2017 at 01:59:22PM +0100, David Woodhouse wrote:
From: David Woodhouse
Allow userspace to configure SR-IOV VFs through sysfs.
Currently, we need an in-kernel driver to pe
On Wed, Sep 27, 2017 at 3:20 PM, David Woodhouse wrote:
> On Wed, 2017-09-27 at 17:00 -0500, Bjorn Helgaas wrote:
>>
>>
>> IIUC, this question is basically "why doesn't the PCI core enable IOV
>> automatically when it sees an IOV-capable device?"
>>
>> I think one reason is that an admin might wan
On Wed, 2017-09-27 at 17:00 -0500, Bjorn Helgaas wrote:
>
>
> IIUC, this question is basically "why doesn't the PCI core enable IOV
> automatically when it sees an IOV-capable device?"
>
> I think one reason is that an admin might want to control the number
> of VFs we enable (e.g., via 1789382a
[+cc Don, Alex D, Alex W, Bryant, Bodong, Michael, kvm list]
On Wed, Sep 27, 2017 at 01:59:22PM +0100, David Woodhouse wrote:
> From: David Woodhouse
>
> Allow userspace to configure SR-IOV VFs through sysfs.
>
> Currently, we need an in-kernel driver to permit this. But sometimes
> *all* we wa
13 matches
Mail list logo
