On Tue, 2013-08-20 at 04:18 +0100, Al Viro wrote:
> On Wed, Aug 14, 2013 at 04:42:14PM -0600, Bjorn Helgaas wrote:
> > [+cc Al, linux-fsdevel for fdget/fdput usage]
>
> fdget/fdput use looks sane, the only thing is that I would rather
> have an explicit include of linux/file.h instead of relying u
On Wed, Aug 14, 2013 at 04:42:14PM -0600, Bjorn Helgaas wrote:
> [+cc Al, linux-fsdevel for fdget/fdput usage]
fdget/fdput use looks sane, the only thing is that I would rather
have an explicit include of linux/file.h instead of relying upon
linux/eventfd.h pulling it. Incidentally, there are onl
On Mon, 2013-08-19 at 16:59 -0600, Alex Williamson wrote:
> On Tue, 2013-08-20 at 08:42 +1000, Benjamin Herrenschmidt wrote:
> > On Mon, 2013-08-19 at 14:02 -0600, Bjorn Helgaas wrote:
> > > I guess. And supply the pci_slot rather than the pci_dev? I'm a
> > > little bit worried because the idea
On Tue, 2013-08-20 at 08:44 +1000, Benjamin Herrenschmidt wrote:
> On Mon, 2013-08-19 at 14:20 -0600, Alex Williamson wrote:
> > I try to handle the slot as opaque, only caring that the slot pointer
> > matches, so I think our implementation is ok... so long as we only get
> > one driver claiming t
On Tue, 2013-08-20 at 08:42 +1000, Benjamin Herrenschmidt wrote:
> On Mon, 2013-08-19 at 14:02 -0600, Bjorn Helgaas wrote:
> > I guess. And supply the pci_slot rather than the pci_dev? I'm a
> > little bit worried because the idea of a "slot" is not well-defined in
> > the spec, and we have sort
On Mon, 2013-08-19 at 14:20 -0600, Alex Williamson wrote:
> I try to handle the slot as opaque, only caring that the slot pointer
> matches, so I think our implementation is ok... so long as we only get
> one driver claiming to manage a slot, but that's not a vfio problem ;)
> Thanks,
By why bothe
On Mon, 2013-08-19 at 14:02 -0600, Bjorn Helgaas wrote:
> I guess. And supply the pci_slot rather than the pci_dev? I'm a
> little bit worried because the idea of a "slot" is not well-defined in
> the spec, and we have sort of an ad hoc method of discovering and
> managing them, e.g., acpiphp and
On Mon, 2013-08-19 at 14:02 -0600, Bjorn Helgaas wrote:
> On Mon, Aug 19, 2013 at 12:41 PM, Alex Williamson
> wrote:
> > On Wed, 2013-08-14 at 17:06 -0600, Alex Williamson wrote:
> >> On Wed, 2013-08-14 at 16:42 -0600, Bjorn Helgaas wrote:
> >> > On Wed, Aug 14, 2013 at 2:10 PM, Alex Williamson
>
On Mon, Aug 19, 2013 at 12:41 PM, Alex Williamson
wrote:
> On Wed, 2013-08-14 at 17:06 -0600, Alex Williamson wrote:
>> On Wed, 2013-08-14 at 16:42 -0600, Bjorn Helgaas wrote:
>> > On Wed, Aug 14, 2013 at 2:10 PM, Alex Williamson
>> > wrote:
>> > > +static int vfio_pci_for_each_slot_or_bus(struc
On Wed, 2013-08-14 at 17:06 -0600, Alex Williamson wrote:
> On Wed, 2013-08-14 at 16:42 -0600, Bjorn Helgaas wrote:
> > [+cc Al, linux-fsdevel for fdget/fdput usage]
> >
> > On Wed, Aug 14, 2013 at 2:10 PM, Alex Williamson
> > wrote:
> > > The current VFIO_DEVICE_RESET interface only maps to PCI
On Wed, 2013-08-14 at 16:42 -0600, Bjorn Helgaas wrote:
> [+cc Al, linux-fsdevel for fdget/fdput usage]
>
> On Wed, Aug 14, 2013 at 2:10 PM, Alex Williamson
> wrote:
> > The current VFIO_DEVICE_RESET interface only maps to PCI use cases
> > where we can isolate the reset to the individual PCI fun
[+cc Al, linux-fsdevel for fdget/fdput usage]
On Wed, Aug 14, 2013 at 2:10 PM, Alex Williamson
wrote:
> The current VFIO_DEVICE_RESET interface only maps to PCI use cases
> where we can isolate the reset to the individual PCI function. This
> means the device must support FLR (PCIe or AF), PM re
12 matches
Mail list logo
