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-...
http://pkgs.fedoraproject.org/cgit/qemu.git/tree/0101-char-Add-a-QemuChrH...
> 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