Re: [Qemu-devel] Headsup: windows virtio networking does not work on current git

[Anthony Liguori]

Rusty Russell <address@hidden> writes:

> Anthony Liguori <address@hidden> writes:
>> Michael Tokarev <address@hidden> writes:
>>
>>> 03.02.2013 17:23, Yan Vugenfirer wrote:
>>>
>>>>> If it helps, mq changes the config size from 8 to 16 bytes.  If the
>>>>> driver was making an assumption about an 8-byte config size, that's
>>>>> likely what the problem is.
>>>>>
>>>> That's exactly the problem.
> ...
>> N.B. this is a pretty nasty bug in the guest driver.  Any new virtio-net
>> feature is going to trigger it (not just multiqueue).  So while pc-1.3
>> will work forever with this guest image, it's pretty much guaranteed to
>> break at some point in the future.
>
> Wow, yes.  I never expected such a bug.  I probably don't even want to
> know how this happened, right?
>
> If I could find a way, I'd like to create some code as an appendix to
> the virtio spec which would torture test each driver and/or device by
> configuring it in strange ways.  But that's pure speculation at this
> point.

It wouldn't be so hard to add a torture parameter to the virtio
implementation in QEMU that would do silly things that were still within
the bounds of the specification.  Larger config sizes, advertisement of
unknown feature bits, etc.

>>> It's easy to turn off mq by default and turn it on when
>>> needed...
>>>
>>> The problem now is that it isn't obvious why your existing
>>> setup breaks when you upgrade.  While when you especially
>>> play with mq, you may look at options available around it...
>>
>> If we ever to get virtio2, a really handy feature to have would be a
>> driver identification string.  Even if was only informative (and not
>> authoritative, we've had a lot of issues like this and being able to
>> make work arounds conditional on the driver identification string would
>> be nice.
>
> In practice, we'd want to formalize it into a string and a version, and
> hope the version gets bumped appropriately.  Because it'll actually be
> used for bug detection.

Sure.

> But AFAICT that would be useless in this case.  We really want to know about
> the guest before we even start it.

We can't just prepare to fight yesterday's wars :-)

We'd want to know the string before we expose host features.  That's
easy.  We've had a lot of trouble with certain feature bits breaking
drivers so masking certain features for known broken drivers would be
really useful.

How we expose config space in virtio2 is a separate discussion.  If we
take a list approach like you've talked about before, it would be much
harder for drivers to assume anything about the BAR size for config
since the size would always be different.

Regards,

Anthony Liguori

>
> Cheers,
> Rusty.