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] virtio and endian-ness


Il 20/08/2013 10:39, Michael S. Tsirkin ha scritto:
> On Tue, Aug 20, 2013 at 02:04:10PM +0930, Rusty Russell wrote:
>> Cornelia Huck <cornelia.huck@de.ibm.com> writes:
>>> On Mon, 19 Aug 2013 12:27:53 +0300
>>> "Michael S. Tsirkin" <mst@redhat.com> wrote:
>>>
>>>> On Mon, Aug 19, 2013 at 11:09:44AM +0200, Cornelia Huck wrote:
>>>>> On Mon, 19 Aug 2013 12:08:35 +0300
>>>>> "Michael S. Tsirkin" <mst@redhat.com> wrote:
>>>>>
>>>>>> On Mon, Aug 19, 2013 at 05:17:30PM +0930, Rusty Russell wrote:
>>>>>>> "Michael S. Tsirkin" <mst@redhat.com> writes:
>>>>>>>> On Mon, Aug 19, 2013 at 12:21:03PM +0930, Rusty Russell wrote:
>>>>>>>>> "Michael S. Tsirkin" <mst@redhat.com> writes:
>>>>>>>>>> During the last TC meeting, we discussed making virtio little endian.
>>>>>>>>>> It was suggested that a feature bit can be used for this,
>>>>>>>>>> but I now think I see two problems:
>>>>>>>>>>
>>>>>>>>>> 1. Features are optional,
>>>>>>>>>> in that there's no way for device to communicate to
>>>>>>>>>> guest that guest must ack a feature bit, and e.g. fail
>>>>>>>>>> if guest does not ack.
>>>>>>>>>>
>>>>>>>>>> On the other hand, it seems likely
>>>>>>>>>> that a hardware virtio device might want to *only* implement
>>>>>>>>>> little endian format and not both big and little endian.
>>>>>>>>>>
>>>>>>>>>> In other words this would be something Paolo once called
>>>>>>>>>> a "negative feature".
>>>>>>>>>>
>>>>>>>>>> 2. With virtio-pci we are running out of transport bits,
>>>>>>>>>> and need a new config space layout to add extra feature bits.
>>>
>>> Just as point of data: For virtio-ccw we should be able to easily
>>> extend feature bits.
>>
>> Yes, I think virtio-ccw and virtio-mmio could simply add a new feature
>> bit to say "1.0 compliant".
> 
> Again, this would be a "negative feature", won't it?

Yes, unless the device model implements both pre-standard and
post-standard layouts.

Perhaps we can reserve the high 16 bits of the device ID for the
standard revision?  Thus pre-standard layout would have device IDs like
0x0000xxxx (as it is now).  Post-standard layout would be 0x0001xxxx.

Paolo


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