[fedora-virt] qemu 1.3 in fedora git, but not rawhide yet

[Hans de Goede]

Hi,

On 12/14/2012 02:17 PM, Cole Robinson wrote:
> On 12/13/2012 08:56 AM, Hans de Goede wrote:
>> Hi,
>>
>> On 12/08/2012 09:47 AM, Cole Robinson wrote:
>>> Hi all,
>>>
>>> I've pushed qemu 1.3 to the fedora git repo, but haven't pushed a build to
>>> rawhide yet
>>
>> Cool to see 1.3 coming to rawhide. And I see that you've already forward
>> ported the chardev flowcontrol patches needed for reliable spice agent /
>> usbredir operation it will need the usual chardev flowcontrol patches,
>> thanks!
>>
>
> While you mention it, anyone on virt-devel care to chime in with long term
> plans here? Has there been any movement on Anthony's 'proper' solution?
>
> At the least, it would help out quite a bit if the first two patches of the
> series were merged:
>
> http://pkgs.fedoraproject.org/cgit/qemu.git/tree/0100-char-Split-out-tcp-socket-close-code-in-a-separate-f.patch
> http://pkgs.fedoraproject.org/cgit/qemu.git/tree/0101-char-Add-a-QemuChrHandlers-struct-to-initialise-char.patch
>
>> Note that I usually have a branch with them forward ported long before
>> the Fedora packages get rebased, so you can save yourself this tedious
>> job by taking them from a branch here:
>> http://cgit.freedesktop.org/~jwrdegoede/qemu/log/?h=qemu-1.3-usbredir-wip
>>
>> You will want the patches starting at:
>> "char: Split out tcp socket close code in a separate function"
>> and ending at:
>> "hw/virtio-serial-bus: replay guest open on destination"
>>
>
> Thanks Hans, I'll use that going forward.
>
>> Note that I once more add to plan some usb-core + usb-redir patches
>> to the Fedora packages for some USB goodness. Currently pending
>> there is:
>>
>> -Some more performance tweaks for ehci giving another 20% performance
>> boost reading from usb mass storage devices
>> -Throughput improvements for uhci (1000 urbs / sec instead if 500 in
>> cases where the guest uses only 1 urb).
>> -Buffered bulk input support. This decouples qemu and the real usb-dev
>>   adding  fifo in between for bulk in endpoints on certain devices (like
>>   we already do for isoc endpoints). This makes USB <-> serial adapters
>>   work reliable even when we hit some latency spikes / issues in qemu
>>   (which we regularly do). Without this received serial data may get lost
>>   due to the small fifo these devices have internally overrunning.
>>
>> Note the intends of this is a heads-up about me planning to bring these
>> upstream improvements to the Fedora qemu-1.3 packages is to allow people
>> to object. If I receive no objections I will move forward with this when
>> I find some time for it :)
>>
>
> It's one thing to backport feature/enhancement bits as part of an accepted
> fedora 'feature', but IMO it should not be a regular occurrence. Packaging
> churn, update churn, and risk for not a lot of gain.
>

Ok, fair enough.

> Also in this particular instance, qemu 1.3 is only going to exist in
> rawhide/virt-preview, so the audience is pretty small. Nowdays there's only 2
> months between qemu GA and qemu+1 RC0, so the window of usefulness is small
> anyways.

So we're going to go for 1.4 for F-19, cool!

> That last bit about usb serial sounds like it results in a bug fix, but if
> it's sufficiently non trivial that qemu-stable wouldn't take it, no one is
> actively complaining about the bug, and it's not required for a fedora
> feature, then skip the backport.
>

It is a nice to have really, but somewhat disruptive ...

> Feel free to change my mind about any of that :)
>
> Backporting isolated bug fixes is always fine (though if you do, please also
> send a pull request to qemu-stable).

Ok.

Regards,

Hans