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 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 :
> [snip]
> > > Also, if you can come up with an interface that d
On Mon, Sep 26, 2011 at 12:04:47PM +0200, Alexander Graf wrote:
> Am 26.09.2011 um 09:51 schrieb David Gibson :
[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 much, much too complex.
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
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 :
[snip]
> > Also, if you can come up with an interface that does not have variable
> > length descriptors but is still able to
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 whateve
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 */
>
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(, ,)
>
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 probab
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
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
>> co
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 V
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 - re
>
> 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(,
On Mon, Sep 26, 2011 at 2:51 AM, David Gibson
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.
>>
>>
On Mon, 2011-09-26 at 12:04 +0200, Alexander Graf wrote:
> Am 26.09.2011 um 09:51 schrieb David Gibson :
>
> > 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
> >> t
Am 26.09.2011 um 09:51 schrieb David Gibson :
> 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 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. Ove
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
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 devf
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;
>>
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
>
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 PCI_BAR_
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 t
24 matches
Mail list logo
