On Wed, Sep 28, 2011 at 10:58:26AM +0200, Alexander Graf wrote:
On 28.09.2011, at 04:40, Alex Williamson wrote:
On Tue, 2011-09-27 at 16:28 -0500, Scott Wood wrote:
[snip]
I'm honestly pretty indifferent on ioctl vs. linear read. I got the
impression that people dislike ioctls for whatever
On Mon, Sep 26, 2011 at 12:34:52PM -0600, Alex Williamson wrote:
On Mon, 2011-09-26 at 12:04 +0200, Alexander Graf wrote:
Am 26.09.2011 um 09:51 schrieb David Gibson da...@gibson.dropbear.id.au:
[snip]
Also, if you can come up with an interface that does not have variable
length descriptors
On Mon, Sep 26, 2011 at 06:59:33PM -0500, Scott Wood wrote:
On 09/26/2011 01:34 PM, Alex Williamson wrote:
The other obvious possibility is a pure ioctl interface. To match what
this proposal is trying to describe, plus the runtime interfaces, we'd
need something like:
/* :0 - PCI
On Mon, Sep 26, 2011 at 12:04:47PM +0200, Alexander Graf wrote:
Am 26.09.2011 um 09:51 schrieb David Gibson da...@gibson.dropbear.id.au:
[snip]
Um, not to put too fine a point on it, this is madness.
Yes, it's very flexible and can thereby cover a very wide range of
cases. But it's
On Fri, 2011-09-30 at 18:46 +1000, David Gibson wrote:
On Mon, Sep 26, 2011 at 12:34:52PM -0600, Alex Williamson wrote:
On Mon, 2011-09-26 at 12:04 +0200, Alexander Graf wrote:
Am 26.09.2011 um 09:51 schrieb David Gibson da...@gibson.dropbear.id.au:
[snip]
Also, if you can come up with
On Fri, 2011-09-30 at 10:37 -0600, Alex Williamson wrote:
On Fri, 2011-09-30 at 18:46 +1000, David Gibson wrote:
On Mon, Sep 26, 2011 at 12:34:52PM -0600, Alex Williamson wrote:
On Mon, 2011-09-26 at 12:04 +0200, Alexander Graf wrote:
Am 26.09.2011 um 09:51 schrieb David Gibson
On 28.09.2011, at 04:40, Alex Williamson wrote:
On Tue, 2011-09-27 at 16:28 -0500, Scott Wood wrote:
On 09/26/2011 07:45 PM, Alex Williamson wrote:
On Mon, 2011-09-26 at 18:59 -0500, Scott Wood wrote:
On 09/26/2011 01:34 PM, Alex Williamson wrote:
/* Reset the device */
#define
On 09/26/2011 07:45 PM, Alex Williamson wrote:
On Mon, 2011-09-26 at 18:59 -0500, Scott Wood wrote:
On 09/26/2011 01:34 PM, Alex Williamson wrote:
/* Reset the device */
#define VFIO_DEVICE_RESET _IO(, ,)
What generic way do we have to do this? We should probably have a
On Tue, 2011-09-27 at 16:28 -0500, Scott Wood wrote:
On 09/26/2011 07:45 PM, Alex Williamson wrote:
On Mon, 2011-09-26 at 18:59 -0500, Scott Wood wrote:
On 09/26/2011 01:34 PM, Alex Williamson wrote:
/* Reset the device */
#define VFIO_DEVICE_RESET _IO(, ,)
What
On Fri, Sep 09, 2011 at 08:11:54AM -0500, Stuart Yoder wrote:
Based on the discussions over the last couple of weeks
I have updated the device fd file layout proposal and
tried to specify it a bit more formally.
===
1. Overview
Am 26.09.2011 um 09:51 schrieb David Gibson da...@gibson.dropbear.id.au:
On Fri, Sep 09, 2011 at 08:11:54AM -0500, Stuart Yoder wrote:
Based on the discussions over the last couple of weeks
I have updated the device fd file layout proposal and
tried to specify it a bit more formally.
On Mon, 2011-09-26 at 12:04 +0200, Alexander Graf wrote:
Am 26.09.2011 um 09:51 schrieb David Gibson da...@gibson.dropbear.id.au:
On Fri, Sep 09, 2011 at 08:11:54AM -0500, Stuart Yoder wrote:
Based on the discussions over the last couple of weeks
I have updated the device fd file layout
On Mon, Sep 26, 2011 at 2:51 AM, David Gibson
da...@gibson.dropbear.id.au wrote:
On Fri, Sep 09, 2011 at 08:11:54AM -0500, Stuart Yoder wrote:
Based on the discussions over the last couple of weeks
I have updated the device fd file layout proposal and
tried to specify it a bit more formally.
The other obvious possibility is a pure ioctl interface. To match what
this proposal is trying to describe, plus the runtime interfaces, we'd
need something like:
/* :0 - PCI devices, :1 - Devices path device, 63:2 - reserved */
#define VFIO_DEVICE_GET_FLAGS _IOR(, , u64)
On Mon, 2011-09-26 at 15:03 -0500, Stuart Yoder wrote:
The other obvious possibility is a pure ioctl interface. To match what
this proposal is trying to describe, plus the runtime interfaces, we'd
need something like:
/* :0 - PCI devices, :1 - Devices path device, 63:2 - reserved */
On 09/26/2011 01:34 PM, Alex Williamson wrote:
The other obvious possibility is a pure ioctl interface. To match what
this proposal is trying to describe, plus the runtime interfaces, we'd
need something like:
/* :0 - PCI devices, :1 - Devices path device, 63:2 - reserved */
#define
On 09/26/2011 02:57 PM, Stuart Yoder wrote:
On Mon, Sep 26, 2011 at 2:51 AM, David Gibson
Um, not to put too fine a point on it, this is madness.
Yes, it's very flexible and can thereby cover a very wide range of
cases. But it's much, much too complex. Userspace has to parse a
complex,
On Mon, 2011-09-26 at 18:59 -0500, Scott Wood wrote:
On 09/26/2011 01:34 PM, Alex Williamson wrote:
The other obvious possibility is a pure ioctl interface. To match what
this proposal is trying to describe, plus the runtime interfaces, we'd
need something like:
/* :0 - PCI devices,
On Fri, 2011-09-09 at 08:11 -0500, Stuart Yoder wrote:
Based on the discussions over the last couple of weeks
I have updated the device fd file layout proposal and
tried to specify it a bit more formally.
===
1. Overview
On 09/19/2011 10:16 AM, Alex Williamson wrote:
On Fri, 2011-09-09 at 08:11 -0500, Stuart Yoder wrote:
2. Header
The header is located at offset 0x0 in the device fd
and has the following format:
struct devfd_header {
__u32 magic;
__u32 version;
__u32 flags;
On Mon, 2011-09-19 at 14:37 -0500, Scott Wood wrote:
On 09/19/2011 10:16 AM, Alex Williamson wrote:
On Fri, 2011-09-09 at 08:11 -0500, Stuart Yoder wrote:
2. Header
The header is located at offset 0x0 in the device fd
and has the following format:
struct devfd_header {
On 09/19/2011 04:07 PM, Alex Williamson wrote:
On Mon, 2011-09-19 at 14:37 -0500, Scott Wood wrote:
A DTPATH as a record, an INTERRUPT as a sub-record, etc.
Same as any other unrecognized (sub)record type, you ignore it -- but
the kernel should not be generating this.
I'm trying to express
Based on the discussions over the last couple of weeks
I have updated the device fd file layout proposal and
tried to specify it a bit more formally.
===
1. Overview
This specification describes the layout of device files
used in
Meant to identify the changes in v2 of this proposal:
v2:
-removed PCI_INFO record type
-removed PCI_BAR_INFO record type
-PCI_CONFIG_SPACE is now a sub-record/property of a REGION
-removed physical address from region and made it
a subrecord/property of a REGION
-added
24 matches
Mail list logo
