OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

virtio-comment message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [virtio-comment] Feedback for chapter 4


Thomas Huth <thuth@linux.vnet.ibm.com> writes:
> On Mon, 20 Jan 2014 14:22:58 +1030
> Rusty Russell <rusty@au1.ibm.com> wrote:
>
>> Thomas Huth <thuth@linux.vnet.ibm.com> writes:
>> > Here's my feedback for Virtio draft 01, chapter 4:
>> 
>> Thanks again for the feedback!
>> 
>> >
>> > Page 20 /  PCI Device Layout:
>> >
>> > - "To configure the device, use I/O and/or memory regions and/or PCI configuration
>> >   space of the PCI device."
>> >   => That sounds a little bit sparse/confusing. Maybe rather something like:
>> >   "To configure the device, it is possible to use the PCI configuration space
>> >   and/or to access the configuration data via an I/O and/or MMIO base-address
>> >   register."
>> 
>> I ended up with this:
>>         The device is configured via I/O and/or memory regions (though see
>>         VIRTIO_PCI_CAP_PCI_CFG for access via the PCI configutation space).
>
> s/configutation/configuration/

Thanks, I've modified that in my proposal.

> [...] 
>> > Page 27 / MMIO Device Discovery:
>> >
>> > - The device tree snippet is obviously an example. That's ok, but I think the
>> >   spec should explicitely say so (and maybe add some generic words about the
>> >   required properties before the example, too).
>> 
>> OK, I clarified this:
>> 
>> Unlike PCI, MMIO provides no generic device discovery.  For each
>> device, the guest OS will need to know the location of the registers
>> and interrupt(s) used.  The suggested binding for Open Firmware is
>> shown in this example:
>
> Technically, this is not an Open Firmware example, because in that case
> you likely would have to write Forth code instead :-)
> The syntax that is used here is from the ePAPR specification, so I'd
> rather talk about an "ePAPR-style device tree" or a "flattened device tree"
> example here instead.

Thanks, I didn't know that this syntax was a later addition.

I ended up closer to the original:

+and interrupt(s) used.  The suggested binding for systems using
+flattened device trees is shown in this example:

Cheers,
Rusty.



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]