Re: [Qemu-stable] QEMU 1.2 stable queue requests

[Doug Goldstein]

On Tue, Jan 15, 2013 at 4:29 AM, Michael Tokarev <address@hidden> wrote:
> 15.01.2013 00:10, Doug Goldstein wrote:
>>
>> The following are commits I'm requesting for inclusion into the 1.2
>> stable branch. These would for a release (if any) after 1.2.2. These
>> have all been tested in Gentoo and are used there in response to user
>> issues. Most of these are in Fedora as well.
>>
>>
>>
>> http://git.qemu.org/?p=qemu.git;a=commit;h=fc53b7d4b7fe409acae7d8d55a868eb5c696d71c
>
>
> Author: Peter Maydell <address@hidden>
> Date:   Fri Oct 26 16:29:38 2012 +0100
>
>     arm_boot: Change initrd load address to "halfway through RAM"
>
>     To avoid continually having to bump the initrd load address
>     to account for larger kernel images, put the initrd halfway
>     through RAM. This allows large kernels on new boards with lots
>     of RAM to work OK, without breaking existing usecases for
>     boards with only 32MB of RAM.
>
>     Note that this change fixes in passing a bug where we were
>     passing an overly large max_size to load_image_targphys()
>     for the initrd, which meant that we wouldn't correctly refuse
>     to load an enormous initrd that didn't actually fit into RAM.

Previously had a user report problems when booting an ARM system image
that was fairly large. They bisected the fix down to this commit and
it backported cleanly.

>
>
>>
>> http://git.qemu.org/?p=qemu.git;a=commit;h=d8f8a860f2403533fc73f541122c65a34b21e42f
>
>
> Author: Alon Levy <address@hidden>
> Date:   Sun Sep 2 02:04:16 2012 +0300
>
>     dtrace backend: add function to reserved words

Prevent the systemtap dtrace backend from using the "function"
variable which causes systemtap to fall over. It appends a _ to the
name. Seemed like a harmless fix for tracing.

>
>>
>> http://git.qemu.org/?p=qemu.git;a=commit;h=511aefb0c60e3063ead76d4ba6aabf619eed18ef
>
>
> Author: Alon Levy <address@hidden>
> Date:   Thu Nov 1 14:56:00 2012 +0200
>
>     hw/qxl: qxl_send_events: nop if stopped
>
>     Added a trace point for easy logging.
>
>     RHBZ: https://bugzilla.redhat.com/show_bug.cgi?id=870972

So this is based on the fact with older spice servers that this qemu
allowed to be built against would crash under certain circumstances.
While this is fixed in newer SPICE servers, the build process still
allows it to be built against this. This commit adds information to
make the debugging of this issue easier.

>
>>
>> http://git.qemu.org/?p=qemu.git;a=commit;h=fe512d65e0b752dfa7af6cfb374a0820d35040d0
>
>
> Author: Eduardo Otubo <address@hidden>
> Date:   Thu Nov 29 13:56:41 2012 -0200
>
>     seccomp: adding new syscalls (bugzilla 855162)
>
>     According to the bug 855162[0] - there's the need of adding new syscalls
>     to the whitelist when using Qemu with Libvirt.
>
>     [0] - https://bugzilla.redhat.com/show_bug.cgi?id=855162

When trying to use libsecomp with qemu-kvm launched via libvirt on a
Fedora machine this issue was encountered and solved by the Red Hat
guys. I yanked the fix from their troubleshooting and it solved the
same issue.


>
>>
>> http://git.qemu.org/?p=qemu.git;a=commit;h=ad0b5321f1f797274603ebbe20108b0750baee94
>
>
> Author: Luiz Capitulino <address@hidden>
> Date:   Fri Oct 5 16:47:57 2012 -0300
>
>     Call MADV_HUGEPAGE for guest RAM allocations
>
>     This makes it possible for QEMU to use transparent huge pages (THP)
>     when transparent_hugepage/enabled=madvise. Otherwise THP is only
>     used when it's enabled system wide.
>

This is a bit of an enhancement. A few distros backport a similar
patch into their package so I was approaching this from the mindset
that if downstream is applying a patch its better for upstream to
carry it if its not distro specific.


>
> I'm not sure all this qualifies for -stable.  Can you comment on
> these a bit please, why do you think it is important to push it
> to stable?
>
> For example, the last commit (I tried to push similar change to
> qemu several times, but go no reply, so a patch by Luiz has been
> accepted instead) looks more like an enhancement than a bugfix.
>
> Some of that is applicable to 1.1-stable too, provided they're
> applicable for -stable at all.
>
> Thanks,
>
> /mjt
>

Hopefully the above rationale is reasonable. If not I'm content with
carrying the fixes downstream.

-- 
Doug Goldstein