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
alex.william...@redhat.com wrote:
The current VFIO_DEVICE_RESET interface
On Mon, Aug 19, 2013 at 12:41 PM, Alex Williamson
alex.william...@redhat.com 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
alex.william...@redhat.com wrote:
+static
On Mon, 2013-08-19 at 14:02 -0600, Bjorn Helgaas wrote:
On Mon, Aug 19, 2013 at 12:41 PM, Alex Williamson
alex.william...@redhat.com 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,
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: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 bother
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 of an ad
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 to
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 of a
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
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 upon
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 reset on D3hot-D0
transition, device specific reset, or be a singleton device on a bus
for a secondary bus
[+cc Al, linux-fsdevel for fdget/fdput usage]
On Wed, Aug 14, 2013 at 2:10 PM, Alex Williamson
alex.william...@redhat.com 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
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
alex.william...@redhat.com wrote:
The current VFIO_DEVICE_RESET interface only maps to PCI use cases
where we can isolate the reset to the
13 matches
Mail list logo
