[Qemu-devel] [0.14] Queue of 0.14 patches/pull?

[Qemu-devel] [0.14] Queue of 0.14 patches/pull?

[Paolo Bonzini]

Before creating rc1 we need to make sure that all patches for 0.14 have 
been reviewed and applied.

Please reply to this message with a subject starting with "[PING 0.14]" 
and a link to patchwork, gmane, or whatnot; or "[PULL 0.14]" for tree 
pulls.  Also, I believe all patches meant for stable should also start 
having "[PATCH 0.14]", too.

Myself I have only

http://permalink.gmane.org/gmane.comp.emulators.qemu/88490

to ping. :)  It is in branch qemu-char-echo of
git://github.com/bonzini/qemu.git as well.

Thanks!

Paolo

[Qemu-devel] [PULL 0.14] spice + usb

[Gerd Hoffmann]

   Hi,

There are two outstanding pull requests:

(1) usb patch queue
     git://anongit.freedesktop.org/spice/qemu usb.5

     Brings event queuing for usb hid devices.
     Brings migration support for usb hub and usb hid devices.
     The latter is a quite important, it makes sure the recently
     added remote wakeup support keeps working after migration.

(2) spice patch queue (just reposted with one bugfix added).
     git://anongit.freedesktop.org/spice/qemu spice.v30.pull

     Brings a bunch of bug fixes for spice+qxl collected the last
     few weeks and the spicevmc chardev by Alon.

thanks,
   Gerd

Re: [Qemu-devel] [0.14] Queue of 0.14 patches/pull?

[Markus Armbruster]

Paolo Bonzini <pbonzini@redhat.com> writes:

> Before creating rc1 we need to make sure that all patches for 0.14 have 
> been reviewed and applied.
>
> Please reply to this message with a subject starting with "[PING 0.14]" 
> and a link to patchwork, gmane, or whatnot; or "[PULL 0.14]" for tree 
> pulls.  Also, I believe all patches meant for stable should also start 
> having "[PATCH 0.14]", too.

All my outstanding patches are routed through Kevin's tree, which means
I can leave this to him.

Re: [Qemu-devel] [0.14] Queue of 0.14 patches/pull?

[Kevin Wolf]

Am 27.01.2011 13:34, schrieb Markus Armbruster:
> Paolo Bonzini <pbonzini@redhat.com> writes:
> 
>> Before creating rc1 we need to make sure that all patches for 0.14 have 
>> been reviewed and applied.
>>
>> Please reply to this message with a subject starting with "[PING 0.14]" 
>> and a link to patchwork, gmane, or whatnot; or "[PULL 0.14]" for tree 
>> pulls.  Also, I believe all patches meant for stable should also start 
>> having "[PATCH 0.14]", too.
> 
> All my outstanding patches are routed through Kevin's tree, which means
> I can leave this to him.

I'll send a last pull request tomorrow or on Monday.

Kevin

Re: [Qemu-devel] [0.14] Queue of 0.14 patches/pull?

[Markus Armbruster]

Markus Armbruster <armbru@redhat.com> writes:

> Paolo Bonzini <pbonzini@redhat.com> writes:
>
>> Before creating rc1 we need to make sure that all patches for 0.14 have 
>> been reviewed and applied.
>>
>> Please reply to this message with a subject starting with "[PING 0.14]" 
>> and a link to patchwork, gmane, or whatnot; or "[PULL 0.14]" for tree 
>> pulls.  Also, I believe all patches meant for stable should also start 
>> having "[PATCH 0.14]", too.
>
> All my outstanding patches are routed through Kevin's tree, which means
> I can leave this to him.

I'm working on a fix for the -drive if=scsi,index=N regression, to be
routed through Kevin's tree as well.  Should really go into 0.14.

Re: [Qemu-devel] [0.14] Queue of 0.14 patches/pull?

[Anthony Liguori]

On 01/27/2011 02:29 AM, Paolo Bonzini wrote:
> Before creating rc1 we need to make sure that all patches for 0.14 have
> been reviewed and applied.
>
> Please reply to this message with a subject starting with "[PING 0.14]"
> and a link to patchwork, gmane, or whatnot; or "[PULL 0.14]" for tree
> pulls.  Also, I believe all patches meant for stable should also start
> having "[PATCH 0.14]", too.
>
> Myself I have only
>
> http://permalink.gmane.org/gmane.comp.emulators.qemu/88490
>
> to ping. :)  It is in branch qemu-char-echo of
> git://github.com/bonzini/qemu.git as well.
>
> Thanks!
>    

This is a good idea, thanks for doing this!

Regards,

Anthony Liguori

> Paolo
>
>    

[Qemu-devel] [PING 0.14] fix crash when a read handler calls qemu_set_fd_handler2()

[Rick Vernam]

> > Please reply to this message with a subject starting with "[PING 0.14]"
> > and a link to patchwork, gmane, or whatnot; or "[PULL 0.14]" for tree
> > pulls.  Also, I believe all patches meant for stable should also start
> > having "[PATCH 0.14]", too.

I am not the author of this patch, but it fixed a crash that was bugging me 
consistently.

http://patchwork.ozlabs.org/patch/62420/

[Qemu-devel] [PING 0.14] seabios virtio bug

[Rick Vernam]

> > Please reply to this message with a subject starting with "[PING 0.14]"
> > and a link to patchwork, gmane, or whatnot; or "[PULL 0.14]" for tree
> > pulls.  Also, I believe all patches meant for stable should also start
> > having "[PATCH 0.14]", too.

I'm not sure how to tell which version of seabios is shipped with qemu.
What I am sure about is that the version that shipped with qemu 0.13 had a bug 
as described here
http://lists.nongnu.org/archive/html/qemu-devel/2010-09/msg01145.html

The patch to seabios that fixed the bug was released with seabios-0.6.1, though 
I'm not sure if it was back-ported.
http://www.seabios.org/pipermail/seabios/2010-September/000909.html

[Qemu-devel] Re: [PING 0.14] seabios virtio bug

[Paolo Bonzini]

On 01/27/2011 05:51 PM, Rick Vernam wrote:
> The patch to seabios that fixed the bug was released with seabios-0.6.1, though
> I'm not sure if it was back-ported.
> http://www.seabios.org/pipermail/seabios/2010-September/000909.html

Right now QEMU's seabios submodule points at 0.6.1.

Should it be updated to include Gleb and Kevin's bootorder work?

Paolo

Re: [Qemu-devel] [PING 0.14] fix crash when a read handler calls qemu_set_fd_handler2()

[Anthony Liguori]

On 01/27/2011 10:44 AM, Rick Vernam wrote:
>>> Please reply to this message with a subject starting with "[PING 0.14]"
>>> and a link to patchwork, gmane, or whatnot; or "[PULL 0.14]" for tree
>>> pulls.  Also, I believe all patches meant for stable should also start
>>> having "[PATCH 0.14]", too.
>>>        
> I am not the author of this patch, but it fixed a crash that was bugging me
> consistently.
>
> http://patchwork.ozlabs.org/patch/62420/
>    

Stefan, I thought we're carryign a patch from you that fixes this 
problem?  Am I mistaken?

Regards,

Anthony Liguori

[Qemu-devel] Re: [PING 0.14] seabios virtio bug

[Gleb Natapov]

On Thu, Jan 27, 2011 at 06:12:31PM +0100, Paolo Bonzini wrote:
> On 01/27/2011 05:51 PM, Rick Vernam wrote:
> >The patch to seabios that fixed the bug was released with seabios-0.6.1, though
> >I'm not sure if it was back-ported.
> >http://www.seabios.org/pipermail/seabios/2010-September/000909.html
> 
> Right now QEMU's seabios submodule points at 0.6.1.
> 
> Should it be updated to include Gleb and Kevin's bootorder work?
> 
There is not stable release with bootorder yet.

--
			Gleb.

[Qemu-devel] Re: [0.14] Queue of 0.14 patches/pull?

[Michael S. Tsirkin]

On Thu, Jan 27, 2011 at 09:29:36AM +0100, Paolo Bonzini wrote:
> Before creating rc1 we need to make sure that all patches for 0.14 have 
> been reviewed and applied.
> 
> Please reply to this message with a subject starting with "[PING 0.14]" 
> and a link to patchwork, gmane, or whatnot; or "[PULL 0.14]" for tree 
> pulls.  Also, I believe all patches meant for stable should also start 
> having "[PATCH 0.14]", too.
> 
> Myself I have only
> 
> http://permalink.gmane.org/gmane.comp.emulators.qemu/88490
> 
> to ping. :)  It is in branch qemu-char-echo of
> git://github.com/bonzini/qemu.git as well.
> 
> Thanks!
> 
> Paolo

Have some pci fixes, should be ready by monday.
Also working on a vhost patch that I think we
need for 0.14 but only for qemu-kvm.

Re: [Qemu-devel] [PING 0.14] fix crash when a read handler calls qemu_set_fd_handler2()

[Stefan Hajnoczi]

On Thu, Jan 27, 2011 at 5:14 PM, Anthony Liguori <anthony@codemonkey.ws> wrote:
> On 01/27/2011 10:44 AM, Rick Vernam wrote:
>>>>
>>>> Please reply to this message with a subject starting with "[PING 0.14]"
>>>> and a link to patchwork, gmane, or whatnot; or "[PULL 0.14]" for tree
>>>> pulls.  Also, I believe all patches meant for stable should also start
>>>> having "[PATCH 0.14]", too.
>>>>
>>
>> I am not the author of this patch, but it fixed a crash that was bugging
>> me
>> consistently.
>>
>> http://patchwork.ozlabs.org/patch/62420/
>>
>
> Stefan, I thought we're carryign a patch from you that fixes this problem?
>  Am I mistaken?

Yes, that crash was fixed in qemu.git by
0290b57bdfec83ca78b6d119ea9847bb17943328 "Delete IOHandlers after
potentially running them".

To be fair Corentin and Yoshiaki seemed in favor of applying this one
regardless:
http://patchwork.ozlabs.org/patch/80335/

Stefan

Re: [Qemu-devel] [PING 0.14] fix crash when a read handler calls qemu_set_fd_handler2()

[Anthony Liguori]

On 01/27/2011 01:50 PM, Stefan Hajnoczi wrote:
> On Thu, Jan 27, 2011 at 5:14 PM, Anthony Liguori<anthony@codemonkey.ws>  wrote:
>    
>> On 01/27/2011 10:44 AM, Rick Vernam wrote:
>>      
>>>>> Please reply to this message with a subject starting with "[PING 0.14]"
>>>>> and a link to patchwork, gmane, or whatnot; or "[PULL 0.14]" for tree
>>>>> pulls.  Also, I believe all patches meant for stable should also start
>>>>> having "[PATCH 0.14]", too.
>>>>>
>>>>>            
>>> I am not the author of this patch, but it fixed a crash that was bugging
>>> me
>>> consistently.
>>>
>>> http://patchwork.ozlabs.org/patch/62420/
>>>
>>>        
>> Stefan, I thought we're carryign a patch from you that fixes this problem?
>>   Am I mistaken?
>>      
> Yes, that crash was fixed in qemu.git by
> 0290b57bdfec83ca78b6d119ea9847bb17943328 "Delete IOHandlers after
> potentially running them".
>
> To be fair Corentin and Yoshiaki seemed in favor of applying this one
> regardless:
> http://patchwork.ozlabs.org/patch/80335/
>    

Yeah, the logic is bad there though.  The ioh gets freed as soon as that 
condition is over so the assignments to NULL are pointless.

But at any rate, let's just get rid of the whole dang thing and get a 
glib based main loop in as soon as we can.

Regards,

Anthony Liguori

> Stefan
>    

Re: [Qemu-devel] [0.14] Queue of 0.14 patches/pull?

[Amit Shah]

On (Thu) Jan 27 2011 [09:29:36], Paolo Bonzini wrote:
> Before creating rc1 we need to make sure that all patches for 0.14 have 
> been reviewed and applied.
> 
> Please reply to this message with a subject starting with "[PING 0.14]" 
> and a link to patchwork, gmane, or whatnot; or "[PULL 0.14]" for tree 
> pulls.  Also, I believe all patches meant for stable should also start 
> having "[PATCH 0.14]", too.

I have the following pull request for virtio-serial:

http://thread.gmane.org/gmane.comp.emulators.qemu/91054

git://git.kernel.org/pub/scm/virt/qemu/amit/virtio-serial.git for-anthony

>From the orig. mail:

Please pull for fixes to the virtio-serial code:
- Don't copy over guest buffer to host (prevents potential DoS
  scenarios, pointed out by Paul Brook)
- Add support for flow control
- A couple of trivial fixes to virtio-console code

		Amit

Re: [Qemu-devel] [0.14] Queue of 0.14 patches/pull?

[Gleb Natapov]

On Thu, Jan 27, 2011 at 10:30:46AM -0600, Anthony Liguori wrote:
> On 01/27/2011 02:29 AM, Paolo Bonzini wrote:
> >Before creating rc1 we need to make sure that all patches for 0.14 have
> >been reviewed and applied.
> >
> >Please reply to this message with a subject starting with "[PING 0.14]"
> >and a link to patchwork, gmane, or whatnot; or "[PULL 0.14]" for tree
> >pulls.  Also, I believe all patches meant for stable should also start
> >having "[PATCH 0.14]", too.
> >
> >Myself I have only
> >
> >http://permalink.gmane.org/gmane.comp.emulators.qemu/88490
> >
> >to ping. :)  It is in branch qemu-char-echo of
> >git://github.com/bonzini/qemu.git as well.
> >
> >Thanks!
> 
> This is a good idea, thanks for doing this!
> 
http://www.mail-archive.com/qemu-devel@nongnu.org/msg50368.html

--
			Gleb.

Re: [Qemu-devel] Re: [0.14] Queue of 0.14 patches/pull?

[Yoshiaki Tamura]

2011/1/28 Michael S. Tsirkin <mst@redhat.com>:
> On Thu, Jan 27, 2011 at 09:29:36AM +0100, Paolo Bonzini wrote:
>> Before creating rc1 we need to make sure that all patches for 0.14 have
>> been reviewed and applied.
>>
>> Please reply to this message with a subject starting with "[PING 0.14]"
>> and a link to patchwork, gmane, or whatnot; or "[PULL 0.14]" for tree
>> pulls.  Also, I believe all patches meant for stable should also start
>> having "[PATCH 0.14]", too.
>>
>> Myself I have only
>>
>> http://permalink.gmane.org/gmane.comp.emulators.qemu/88490
>>
>> to ping. :)  It is in branch qemu-char-echo of
>> git://github.com/bonzini/qemu.git as well.
>>
>> Thanks!
>>
>> Paolo
>
> Have some pci fixes, should be ready by monday.
> Also working on a vhost patch that I think we
> need for 0.14 but only for qemu-kvm.

I would like Kemari to be included for 0.14.  Thanks to many
valuable comments from various reviewers, it got better than
ever, I believe.  For those who may object, it wouldn't affect
any functions including live migration unless one turns it on.
Besides, it is a good application of live migration.  By having
merged, I would be able to focus on increasing functionality and
optimization.

Thanks,

Yoshi

Re: [Qemu-devel] Re: [0.14] Queue of 0.14 patches/pull?

[Michael Tokarev]

28.01.2011 11:06, Yoshiaki Tamura wrote:
[]
> I would like Kemari to be included for 0.14.  Thanks to many
> valuable comments from various reviewers, it got better than
> ever, I believe.  For those who may object, it wouldn't affect
> any functions including live migration unless one turns it on.
> Besides, it is a good application of live migration.  By having
> merged, I would be able to focus on increasing functionality and
> optimization.

It's somewhat unexpected to see merge request for any new
functionality into a "stable" branch.  Having nothing bad
against Kemari, I still think we shouldn't include any new
functionality into 0.14, which were planned to be released
before new year... ;)

I mean, if it were not merged so far, for reasons that can
be discussed separately etc, regardless of its good shape
and so on... let's don't do any last-minute merges.

Mergeing it to a development branch is entirely another
question.

/mjt

[Qemu-devel] Re: [0.14] Queue of 0.14 patches/pull?

[Paolo Bonzini]

On 01/28/2011 11:00 AM, Michael Tokarev wrote:
> 28.01.2011 11:06, Yoshiaki Tamura wrote:
> []
>> I would like Kemari to be included for 0.14.  Thanks to many
>> valuable comments from various reviewers, it got better than
>> ever, I believe.  For those who may object, it wouldn't affect
>> any functions including live migration unless one turns it on.
>> Besides, it is a good application of live migration.  By having
>> merged, I would be able to focus on increasing functionality and
>> optimization.
>
> It's somewhat unexpected to see merge request for any new
> functionality into a "stable" branch.  Having nothing bad
> against Kemari, I still think we shouldn't include any new
> functionality into 0.14, which were planned to be released
> before new year... ;)
>
> I mean, if it were not merged so far, for reasons that can
> be discussed separately etc, regardless of its good shape
> and so on... let's don't do any last-minute merges.

To be fair to Yoshiaki, the first 17 patches in his 19-patch series have 
no impact on the operation of QEMU, and even the last two are 
Kemari-only.  I know almost nothing about Kemari so I cannot comment on 
the technical side of those patches, only that it w^Hshouldn't be 
destabilizing.  I made some comments on a couple of patches, so I'm 
inclined to say no as well.

http://permalink.gmane.org/gmane.comp.emulators.qemu/91096 should be 
applied in any case, as it is a regression from 0.12.

Paolo

Re: [Qemu-devel] Re: [0.14] Queue of 0.14 patches/pull?

[Yoshiaki Tamura]

2011/1/28 Paolo Bonzini <pbonzini@redhat.com>:
> On 01/28/2011 11:00 AM, Michael Tokarev wrote:
>>
>> 28.01.2011 11:06, Yoshiaki Tamura wrote:
>> []
>>>
>>> I would like Kemari to be included for 0.14.  Thanks to many
>>> valuable comments from various reviewers, it got better than
>>> ever, I believe.  For those who may object, it wouldn't affect
>>> any functions including live migration unless one turns it on.
>>> Besides, it is a good application of live migration.  By having
>>> merged, I would be able to focus on increasing functionality and
>>> optimization.
>>
>> It's somewhat unexpected to see merge request for any new
>> functionality into a "stable" branch.  Having nothing bad
>> against Kemari, I still think we shouldn't include any new
>> functionality into 0.14, which were planned to be released
>> before new year... ;)
>>
>> I mean, if it were not merged so far, for reasons that can
>> be discussed separately etc, regardless of its good shape
>> and so on... let's don't do any last-minute merges.
>
> To be fair to Yoshiaki, the first 17 patches in his 19-patch series have no
> impact on the operation of QEMU, and even the last two are Kemari-only.  I
> know almost nothing about Kemari so I cannot comment on the technical side
> of those patches, only that it w^Hshouldn't be destabilizing.  I made some
> comments on a couple of patches, so I'm inclined to say no as well.

I don't have any intention to destabilize qemu, so I'm happy to
follow what people think appropriate.

> http://permalink.gmane.org/gmane.comp.emulators.qemu/91096 should be applied
> in any case, as it is a regression from 0.12.

Oops, I forgot to list it :)  Thanks for catching.

Yoshi

>
> Paolo
>
>

Re: [Qemu-devel] Re: [0.14] Queue of 0.14 patches/pull?

[Anthony Liguori]

On 01/28/2011 07:33 AM, Paolo Bonzini wrote:
> On 01/28/2011 11:00 AM, Michael Tokarev wrote:
>> 28.01.2011 11:06, Yoshiaki Tamura wrote:
>> []
>>> I would like Kemari to be included for 0.14.  Thanks to many
>>> valuable comments from various reviewers, it got better than
>>> ever, I believe.  For those who may object, it wouldn't affect
>>> any functions including live migration unless one turns it on.
>>> Besides, it is a good application of live migration.  By having
>>> merged, I would be able to focus on increasing functionality and
>>> optimization.
>>
>> It's somewhat unexpected to see merge request for any new
>> functionality into a "stable" branch.  Having nothing bad
>> against Kemari, I still think we shouldn't include any new
>> functionality into 0.14, which were planned to be released
>> before new year... ;)
>>
>> I mean, if it were not merged so far, for reasons that can
>> be discussed separately etc, regardless of its good shape
>> and so on... let's don't do any last-minute merges.
>
> To be fair to Yoshiaki, the first 17 patches in his 19-patch series 
> have no impact on the operation of QEMU, and even the last two are 
> Kemari-only.  I know almost nothing about Kemari so I cannot comment 
> on the technical side of those patches, only that it w^Hshouldn't be 
> destabilizing.  I made some comments on a couple of patches, so I'm 
> inclined to say no as well.

No, I'd prefer not to take Kemari before the 0.14 freeze.  It gives us a 
full release cycle for testing plus gives a nice headline feature for 0.15.

> http://permalink.gmane.org/gmane.comp.emulators.qemu/91096 should be 
> applied in any case, as it is a regression from 0.12.

Thanks.

Regards,

Anthony Liguori


> Paolo
>

Re: [Qemu-devel] Re: [0.14] Queue of 0.14 patches/pull?

[Yoshiaki Tamura]

2011/1/29 Anthony Liguori <anthony@codemonkey.ws>:
> On 01/28/2011 07:33 AM, Paolo Bonzini wrote:
>>
>> On 01/28/2011 11:00 AM, Michael Tokarev wrote:
>>>
>>> 28.01.2011 11:06, Yoshiaki Tamura wrote:
>>> []
>>>>
>>>> I would like Kemari to be included for 0.14.  Thanks to many
>>>> valuable comments from various reviewers, it got better than
>>>> ever, I believe.  For those who may object, it wouldn't affect
>>>> any functions including live migration unless one turns it on.
>>>> Besides, it is a good application of live migration.  By having
>>>> merged, I would be able to focus on increasing functionality and
>>>> optimization.
>>>
>>> It's somewhat unexpected to see merge request for any new
>>> functionality into a "stable" branch.  Having nothing bad
>>> against Kemari, I still think we shouldn't include any new
>>> functionality into 0.14, which were planned to be released
>>> before new year... ;)
>>>
>>> I mean, if it were not merged so far, for reasons that can
>>> be discussed separately etc, regardless of its good shape
>>> and so on... let's don't do any last-minute merges.
>>
>> To be fair to Yoshiaki, the first 17 patches in his 19-patch series have
>> no impact on the operation of QEMU, and even the last two are Kemari-only.
>>  I know almost nothing about Kemari so I cannot comment on the technical
>> side of those patches, only that it w^Hshouldn't be destabilizing.  I made
>> some comments on a couple of patches, so I'm inclined to say no as well.
>
> No, I'd prefer not to take Kemari before the 0.14 freeze.  It gives us a
> full release cycle for testing plus gives a nice headline feature for 0.15.

Sounds reasonable to me. I thought it might be forgotten unless I
didn't raise my voice :) I'll keep up the pace to get it in once
the development cycle is ready.

Thanks,

Yoshi

>> http://permalink.gmane.org/gmane.comp.emulators.qemu/91096 should be
>> applied in any case, as it is a regression from 0.12.
>
> Thanks.
>
> Regards,
>
> Anthony Liguori
>
>
>> Paolo
>>
>
>
>

[Qemu-devel] Re: [0.14] Queue of 0.14 patches/pull?

[Paolo Bonzini]

On 01/28/2011 03:21 PM, Yoshiaki Tamura wrote:
> >  http://permalink.gmane.org/gmane.comp.emulators.qemu/91096  should be applied
> >  in any case, as it is a regression from 0.12.
>
> Oops, I forgot to list it:)   Thanks for catching.

This one is still missing in 0.14.

Paolo

[Qemu-devel] [PING 0.14] Missing patches (mostly fixes)

[Stefan Weil]

Hello,

these are some patches which I found on my stack of open patches.

All of them should go into 0.14, and at least some of them could also be 
applied to 0.13.

[PATCH] hw/fmopl: Fix buffer access out-of-bounds errors 
(http://patchwork.ozlabs.org/patch/79054/)
[PATCH] linux-user: Fix possible realloc memory leak 
(http://patchwork.ozlabs.org/patch/79217/)

[PATCH 1/3] tests: Fix two memory leaks 
(http://patchwork.ozlabs.org/patch/79945/)
[PATCH 2/3] check-qdict: Fix possible crash 
(http://patchwork.ozlabs.org/patch/79946/)
[PATCH 3/3] w64: Fix problem with missing sigset_t 
(http://patchwork.ozlabs.org/patch/79947/)

[PATCH 1/3] pci: Fix memory leak (http://patchwork.ozlabs.org/patch/79996/)
[PATCH 2/3] ppc405: Fix memory leak 
(http://patchwork.ozlabs.org/patch/79997/)
[PATCH 3/3] s390: Fix memory leak (http://patchwork.ozlabs.org/patch/79998/)

[PATCH] Fix trivial "endianness bugs" 
(http://patchwork.ozlabs.org/patch/80223/)

[PATCH] HACKING: Update status of format checking 
(http://lists.nongnu.org/archive/html/qemu-devel/2011-01/msg02476.html)
[PATCH] mingw32: Fix definitions for PRId64, PRIx64, PRIu64, PRIo64 
(http://patchwork.ozlabs.org/patch/74276/)

Regards,
Stefan Weil

[Qemu-devel] Re: [PING 0.14] Missing patches (mostly fixes)

[Michael S. Tsirkin]

On Wed, Feb 02, 2011 at 08:28:15PM +0100, Stefan Weil wrote:
> [PATCH 1/3] pci: Fix memory leak (http://patchwork.ozlabs.org/patch/79996/)

Looks good. Pls cc me on patches next time to make sure I do not miss a
patch.

Re: [Qemu-devel] Re: [0.14] Queue of 0.14 patches/pull?

[Yoshiaki Tamura]

2011/2/2 Paolo Bonzini <pbonzini@redhat.com>:
> On 01/28/2011 03:21 PM, Yoshiaki Tamura wrote:
>>
>> >  http://permalink.gmane.org/gmane.comp.emulators.qemu/91096  should be
>> > applied
>> >  in any case, as it is a regression from 0.12.
>>
>> Oops, I forgot to list it:)   Thanks for catching.
>
> This one is still missing in 0.14.

Posted with [PATCH 0.14] tag, so that it won't get missed.

http://www.mail-archive.com/qemu-devel@nongnu.org/msg53954.html

Thanks,

Yoshi

>
> Paolo
>
>

[Qemu-devel] Re: [PING 0.14] Missing patches (mostly fixes)

[Riku Voipio]

On Wed, Feb 02, 2011 at 08:28:15PM +0100, Stefan Weil wrote:
> [PATCH] linux-user: Fix possible realloc memory leak  
> (http://patchwork.ozlabs.org/patch/79217/)

Looks ok for me.

Riku

Re: [Qemu-devel] [PING 0.14] Missing patches (mostly fixes)

[Markus Armbruster]

Also:

From: Gleb Natapov <gleb@redhat.com>
Subject: [Qemu-devel] [PATCH] do not pass NULL to strdup.
Date: Wed, 2 Feb 2011 17:34:34 +0200
Message-ID: <20110202153434.GP14984@redhat.com>

Re: [Qemu-devel] [PING 0.14] Missing patches (mostly fixes)

[Anthony Liguori]

On 02/02/2011 01:28 PM, Stefan Weil wrote:
> Hello,
>
> these are some patches which I found on my stack of open patches.
>
> All of them should go into 0.14, and at least some of them could also 
> be applied to 0.13.

This need the following Acks:

>
> [PATCH] hw/fmopl: Fix buffer access out-of-bounds errors 
> (http://patchwork.ozlabs.org/patch/79054/)

malc

> [PATCH] linux-user: Fix possible realloc memory leak 
> (http://patchwork.ozlabs.org/patch/79217/)

Riku

> [PATCH 1/3] tests: Fix two memory leaks 
> (http://patchwork.ozlabs.org/patch/79945/)
> [PATCH 2/3] check-qdict: Fix possible crash 
> (http://patchwork.ozlabs.org/patch/79946/)

Luiz

> [PATCH 3/3] w64: Fix problem with missing sigset_t 
> (http://patchwork.ozlabs.org/patch/79947/)

We don't support w64...

> [PATCH 1/3] pci: Fix memory leak 
> (http://patchwork.ozlabs.org/patch/79996/)

mst (looks like he did)

> [PATCH 2/3] ppc405: Fix memory leak 
> (http://patchwork.ozlabs.org/patch/79997/)
> [PATCH 3/3] s390: Fix memory leak 
> (http://patchwork.ozlabs.org/patch/79998/)

Alex for both of these.

Regards,

Anthony Liguori

> [PATCH] Fix trivial "endianness bugs" 
> (http://patchwork.ozlabs.org/patch/80223/)
>
> [PATCH] HACKING: Update status of format checking 
> (http://lists.nongnu.org/archive/html/qemu-devel/2011-01/msg02476.html)
> [PATCH] mingw32: Fix definitions for PRId64, PRIx64, PRIu64, PRIo64 
> (http://patchwork.ozlabs.org/patch/74276/)
>
> Regards,
> Stefan Weil
>
>

Re: [Qemu-devel] [PING 0.14] Missing patches (mostly fixes)

[Paolo Bonzini]

On 02/04/2011 01:30 PM, Anthony Liguori wrote:
>
>
>> [PATCH 3/3] w64: Fix problem with missing sigset_t
>> (http://patchwork.ozlabs.org/patch/79947/)
>
> We don't support w64...

AFAIK mingw-w64 supports both 32-bit and 64-bit compilation, so the 
patch subject is misleading.

Paolo

Re: [Qemu-devel] [PING 0.14] Missing patches (mostly fixes)

[Alexander Graf]

On 04.02.2011, at 13:30, Anthony Liguori <anthony@codemonkey.ws> wrote:

> On 02/02/2011 01:28 PM, Stefan Weil wrote:
>> Hello,
>> 
>> these are some patches which I found on my stack of open patches.
>> 
>> All of them should go into 0.14, and at least some of them could also be applied to 0.13.
> 
> This need the following Acks:
> 
>> 
>> [PATCH] hw/fmopl: Fix buffer access out-of-bounds errors (http://patchwork.ozlabs.org/patch/79054/)
> 
> malc
> 
>> [PATCH] linux-user: Fix possible realloc memory leak (http://patchwork.ozlabs.org/patch/79217/)
> 
> Riku
> 
>> [PATCH 1/3] tests: Fix two memory leaks (http://patchwork.ozlabs.org/patch/79945/)
>> [PATCH 2/3] check-qdict: Fix possible crash (http://patchwork.ozlabs.org/patch/79946/)
> 
> Luiz
> 
>> [PATCH 3/3] w64: Fix problem with missing sigset_t (http://patchwork.ozlabs.org/patch/79947/)
> 
> We don't support w64...
> 
>> [PATCH 1/3] pci: Fix memory leak (http://patchwork.ozlabs.org/patch/79996/)
> 
> mst (looks like he did)
> 
>> [PATCH 2/3] ppc405: Fix memory leak (http://patchwork.ozlabs.org/patch/79997/)
>> [PATCH 3/3] s390: Fix memory leak (http://patchwork.ozlabs.org/patch/79998/)
> 
> Alex for both of these.

Acked-by: Alexander Graf <agraf@suse.de>

for both :)


Alex


> 
> Regards,
> 
> Anthony Liguori
> 
>> [PATCH] Fix trivial "endianness bugs" (http://patchwork.ozlabs.org/patch/80223/)
>> 
>> [PATCH] HACKING: Update status of format checking (http://lists.nongnu.org/archive/html/qemu-devel/2011-01/msg02476.html)
>> [PATCH] mingw32: Fix definitions for PRId64, PRIx64, PRIu64, PRIo64 (http://patchwork.ozlabs.org/patch/74276/)
>> 
>> Regards,
>> Stefan Weil
>> 
>> 
> 

Re: [Qemu-devel] [PING 0.14] Missing patches (mostly fixes)

[Markus Armbruster]

Anthony Liguori <anthony@codemonkey.ws> writes:

> On 02/02/2011 01:28 PM, Stefan Weil wrote:
[...]
>> [PATCH 1/3] tests: Fix two memory leaks
>> (http://patchwork.ozlabs.org/patch/79945/)

>> [PATCH 2/3] check-qdict: Fix possible crash
>> (http://patchwork.ozlabs.org/patch/79946/)
>
> Luiz

I wouldn't bother with the second one for 0.14.  Yes, we're reading
lines from a file with %s, but it's a fixed file with known contents, no
long lines, and we're reading it in a test program only developers ever
use.

As to the first one, Luiz has never touched that file.  Neither have I,
and it's not obvious to me why it should go into 0.14.

[...]

Re: [Qemu-devel] [PING 0.14] Missing patches (mostly fixes)

[Anthony Liguori]

On 02/04/2011 09:27 AM, Markus Armbruster wrote:
> Anthony Liguori<anthony@codemonkey.ws>  writes:
>
>    
>> On 02/02/2011 01:28 PM, Stefan Weil wrote:
>>      
> [...]
>    
>>> [PATCH 1/3] tests: Fix two memory leaks
>>> (http://patchwork.ozlabs.org/patch/79945/)
>>>        
>    
>>> [PATCH 2/3] check-qdict: Fix possible crash
>>> (http://patchwork.ozlabs.org/patch/79946/)
>>>        
>> Luiz
>>      
> I wouldn't bother with the second one for 0.14.  Yes, we're reading
> lines from a file with %s, but it's a fixed file with known contents, no
> long lines, and we're reading it in a test program only developers ever
> use.
>
> As to the first one, Luiz has never touched that file.  Neither have I,
> and it's not obvious to me why it should go into 0.14.
>    

Yeah, I just meant the qdict one.

Regards,

Anthony Liguori

> [...]
>
>    

Re: [Qemu-devel] [PING 0.14] Missing patches (mostly fixes)

[malc]

On Fri, 4 Feb 2011, Anthony Liguori wrote:

> On 02/02/2011 01:28 PM, Stefan Weil wrote:
> > Hello,
> > 
> > these are some patches which I found on my stack of open patches.
> > 
> > All of them should go into 0.14, and at least some of them could also be
> > applied to 0.13.
> 
> This need the following Acks:
> 
> > 
> > [PATCH] hw/fmopl: Fix buffer access out-of-bounds errors
> > (http://patchwork.ozlabs.org/patch/79054/)
> 
> malc

The patch looks correct.

[..snip..]

-- 
mailto:av1474@comtv.ru

Re: [Qemu-devel] [PING 0.14] Missing patches (mostly fixes)

[Luiz Capitulino]

On Fri, 04 Feb 2011 16:27:46 +0100
Markus Armbruster <armbru@redhat.com> wrote:

> Anthony Liguori <anthony@codemonkey.ws> writes:
> 
> > On 02/02/2011 01:28 PM, Stefan Weil wrote:
> [...]
> >> [PATCH 1/3] tests: Fix two memory leaks
> >> (http://patchwork.ozlabs.org/patch/79945/)
> 
> >> [PATCH 2/3] check-qdict: Fix possible crash
> >> (http://patchwork.ozlabs.org/patch/79946/)
> >
> > Luiz
> 
> I wouldn't bother with the second one for 0.14.  Yes, we're reading
> lines from a file with %s, but it's a fixed file with known contents, no
> long lines, and we're reading it in a test program only developers ever
> use.

Agreed.

> 
> As to the first one, Luiz has never touched that file.  Neither have I,
> and it's not obvious to me why it should go into 0.14.
> 
> [...]
> 

Re: [Qemu-devel] [PING 0.14] Missing patches (mostly fixes)

[Stefan Weil]

Am 04.02.2011 16:27, schrieb Markus Armbruster:
> Anthony Liguori <anthony@codemonkey.ws> writes:
>
>> On 02/02/2011 01:28 PM, Stefan Weil wrote:
> [...]
>>> [PATCH 1/3] tests: Fix two memory leaks
>>> (http://patchwork.ozlabs.org/patch/79945/)
>
>>> [PATCH 2/3] check-qdict: Fix possible crash
>>> (http://patchwork.ozlabs.org/patch/79946/)
>>
>> Luiz
>
> I wouldn't bother with the second one for 0.14. Yes, we're reading
> lines from a file with %s, but it's a fixed file with known contents, no
> long lines, and we're reading it in a test program only developers ever
> use.
>
> As to the first one, Luiz has never touched that file. Neither have I,
> and it's not obvious to me why it should go into 0.14.
>
> [...]

Even if the current code does not result in a real bug at the moment,
it should get fixed:

* Using tools like cppcheck (or others) to find bugs is good,
   because it finds bugs which are important.
   Sorting out "unimportant" bugs from the results wastes time
   which could be invested better, and this waste of time lasts
   forever until the "unimportant" bug will be fixed. The sooner
   you fix it, the better it is.

* Code gets copied, and maybe the copy of code with some weakness
   can expose a real problem.

Therefore I think that both patches should be applied
at least to qemu master (as they are really simple patches,
applying them to 0.14 would be cheap and good as well).

Regards,
Stefan Weil

Re: [Qemu-devel] [PING 0.14] Missing patches (mostly fixes)

[Anthony Liguori]

On 02/04/2011 11:18 AM, Stefan Weil wrote:
> Am 04.02.2011 16:27, schrieb Markus Armbruster:
>> Anthony Liguori <anthony@codemonkey.ws> writes:
>>
>>> On 02/02/2011 01:28 PM, Stefan Weil wrote:
>> [...]
>>>> [PATCH 1/3] tests: Fix two memory leaks
>>>> (http://patchwork.ozlabs.org/patch/79945/)
>>
>>>> [PATCH 2/3] check-qdict: Fix possible crash
>>>> (http://patchwork.ozlabs.org/patch/79946/)
>>>
>>> Luiz
>>
>> I wouldn't bother with the second one for 0.14. Yes, we're reading
>> lines from a file with %s, but it's a fixed file with known contents, no
>> long lines, and we're reading it in a test program only developers ever
>> use.
>>
>> As to the first one, Luiz has never touched that file. Neither have I,
>> and it's not obvious to me why it should go into 0.14.
>>
>> [...]
>
> Even if the current code does not result in a real bug at the moment,
> it should get fixed:
>
> * Using tools like cppcheck (or others) to find bugs is good,
>   because it finds bugs which are important.
>   Sorting out "unimportant" bugs from the results wastes time
>   which could be invested better, and this waste of time lasts
>   forever until the "unimportant" bug will be fixed. The sooner
>   you fix it, the better it is.

No, this is not a good use of time.  I've said multiple times in the 
past, I'm not interested in implementing work arounds for false 
positives in static analysis tools.

We have enough real problems to fix, we don't need to waste cycles on 
psuedo problems.

Regards,

Anthony Liguori

>
> * Code gets copied, and maybe the copy of code with some weakness
>   can expose a real problem.
>
> Therefore I think that both patches should be applied
> at least to qemu master (as they are really simple patches,
> applying them to 0.14 would be cheap and good as well).
>
> Regards,
> Stefan Weil
>
>

Re: [Qemu-devel] [PING 0.14] Missing patches (mostly fixes)

[Stefan Weil]

Am 04.02.2011 18:21, schrieb Anthony Liguori:
> On 02/04/2011 11:18 AM, Stefan Weil wrote:
>> Am 04.02.2011 16:27, schrieb Markus Armbruster:
>>> Anthony Liguori <anthony@codemonkey.ws> writes:
>>>
>>>> On 02/02/2011 01:28 PM, Stefan Weil wrote:
>>> [...]
>>>>> [PATCH 1/3] tests: Fix two memory leaks
>>>>> (http://patchwork.ozlabs.org/patch/79945/)
>>>
>>>>> [PATCH 2/3] check-qdict: Fix possible crash
>>>>> (http://patchwork.ozlabs.org/patch/79946/)
>>>>
>>>> Luiz
>>>
>>> I wouldn't bother with the second one for 0.14. Yes, we're reading
>>> lines from a file with %s, but it's a fixed file with known 
>>> contents, no
>>> long lines, and we're reading it in a test program only developers ever
>>> use.
>>>
>>> As to the first one, Luiz has never touched that file. Neither have I,
>>> and it's not obvious to me why it should go into 0.14.
>>>
>>> [...]
>>
>> Even if the current code does not result in a real bug at the moment,
>> it should get fixed:
>>
>> * Using tools like cppcheck (or others) to find bugs is good,
>>   because it finds bugs which are important.
>>   Sorting out "unimportant" bugs from the results wastes time
>>   which could be invested better, and this waste of time lasts
>>   forever until the "unimportant" bug will be fixed. The sooner
>>   you fix it, the better it is.
>
> No, this is not a good use of time.  I've said multiple times in the 
> past, I'm not interested in implementing work arounds for false 
> positives in static analysis tools.
>
> We have enough real problems to fix, we don't need to waste cycles on 
> psuedo problems.
>
> Regards,
>
> Anthony Liguori

Hi Anthony,

please accept that even if you said something multiple times,
other people might have a different point of view.
QEMU is team work, isn't it?

Both positives are correct, there was no false positive:

Reading strings from external files into limited memory
without limiting their length is bad. Even if it works with
some input data, this kind of programming will be copied
by novice programmers and used with data which is critical.

In the second case, it might be a philosophical question
whether resources like memory or files should be released
explicitly. I tend to say yes, other people say no because the
OS will release them automatically when the program terminates.
But there is no doubt that the tool which says there is a leak
is right.

Regards,
Stefan Weil

Re: [Qemu-devel] [PING 0.14] Missing patches (mostly fixes)

[Anthony Liguori]

On 02/04/2011 11:36 AM, Stefan Weil wrote:
> Hi Anthony,
>
> please accept that even if you said something multiple times,
> other people might have a different point of view.

Yup, just making my point of view clear.

> QEMU is team work, isn't it?
>
> Both positives are correct, there was no false positive:
>
> Reading strings from external files into limited memory
> without limiting their length is bad. Even if it works with
> some input data, this kind of programming will be copied
> by novice programmers and used with data which is critical.

This is why I dislike patches like this, because the discussion about 
whether it really is important or not ends up being a huge distraction.

Regards,

Anthony Liguori

Re: [Qemu-devel] [PING 0.14] Missing patches (mostly fixes)

[Michael S. Tsirkin]

On Fri, Feb 04, 2011 at 06:30:24AM -0600, Anthony Liguori wrote:
> >[PATCH 1/3] pci: Fix memory leak
> >(http://patchwork.ozlabs.org/patch/79996/)
> 
> mst (looks like he did)

Yes, ack.

Re: [Qemu-devel] [PING 0.14] Missing patches (mostly fixes)

[riku voipio]

On 02/04/2011 02:30 PM, Anthony Liguori wrote:
> This need the following Acks:

>> [PATCH] linux-user: Fix possible realloc memory leak
>> (http://patchwork.ozlabs.org/patch/79217/)

> Riku

I thought I gave an OK for this already.

Acked-By: Riku Voipio <riku.voipio@iki.fi>

Re: [Qemu-devel] [PING 0.14] Missing patches (mostly fixes)

[Luiz Capitulino]

On Fri, 04 Feb 2011 18:36:39 +0100
Stefan Weil <weil@mail.berlios.de> wrote:

> Am 04.02.2011 18:21, schrieb Anthony Liguori:
> > On 02/04/2011 11:18 AM, Stefan Weil wrote:
> >> Am 04.02.2011 16:27, schrieb Markus Armbruster:
> >>> Anthony Liguori <anthony@codemonkey.ws> writes:
> >>>
> >>>> On 02/02/2011 01:28 PM, Stefan Weil wrote:
> >>> [...]
> >>>>> [PATCH 1/3] tests: Fix two memory leaks
> >>>>> (http://patchwork.ozlabs.org/patch/79945/)
> >>>
> >>>>> [PATCH 2/3] check-qdict: Fix possible crash
> >>>>> (http://patchwork.ozlabs.org/patch/79946/)
> >>>>
> >>>> Luiz
> >>>
> >>> I wouldn't bother with the second one for 0.14. Yes, we're reading
> >>> lines from a file with %s, but it's a fixed file with known 
> >>> contents, no
> >>> long lines, and we're reading it in a test program only developers ever
> >>> use.
> >>>
> >>> As to the first one, Luiz has never touched that file. Neither have I,
> >>> and it's not obvious to me why it should go into 0.14.
> >>>
> >>> [...]
> >>
> >> Even if the current code does not result in a real bug at the moment,
> >> it should get fixed:
> >>
> >> * Using tools like cppcheck (or others) to find bugs is good,
> >>   because it finds bugs which are important.
> >>   Sorting out "unimportant" bugs from the results wastes time
> >>   which could be invested better, and this waste of time lasts
> >>   forever until the "unimportant" bug will be fixed. The sooner
> >>   you fix it, the better it is.
> >
> > No, this is not a good use of time.  I've said multiple times in the 
> > past, I'm not interested in implementing work arounds for false 
> > positives in static analysis tools.
> >
> > We have enough real problems to fix, we don't need to waste cycles on 
> > psuedo problems.
> >
> > Regards,
> >
> > Anthony Liguori
> 
> Hi Anthony,
> 
> please accept that even if you said something multiple times,
> other people might have a different point of view.
> QEMU is team work, isn't it?
> 
> Both positives are correct, there was no false positive:
> 
> Reading strings from external files into limited memory
> without limiting their length is bad.

This wasn't denied, what Markus said is that this is test code and
thus it isn't high priority for the (now released) 0.14 release.

> Even if it works with
> some input data, this kind of programming will be copied
> by novice programmers and used with data which is critical.

OMG, are they copying code from qemu?!

> 
> In the second case, it might be a philosophical question
> whether resources like memory or files should be released
> explicitly. I tend to say yes, other people say no because the
> OS will release them automatically when the program terminates.
> But there is no doubt that the tool which says there is a leak
> is right.
> 
> Regards,
> Stefan Weil
> 
> 

Re: [Qemu-devel] [PING 0.14] Missing patches (mostly fixes)

[Stefan Weil]

Am 07.02.2011 19:54, schrieb Luiz Capitulino:
> This wasn't denied, what Markus said is that this is test code and
> thus it isn't high priority for the (now released) 0.14 release.

That's ok. Fixing the code in master is fine.

Thanks,
Stefan

Re: [Qemu-devel] [PING 0.14] Missing patches (mostly fixes)

[Stefan Weil]

Am 04.02.2011 16:27, schrieb Markus Armbruster:
> Anthony Liguori<anthony@codemonkey.ws>  writes:
>
>    
>> On 02/02/2011 01:28 PM, Stefan Weil wrote:
>>      
> [...]
>    
>>> [PATCH 1/3] tests: Fix two memory leaks
>>> (http://patchwork.ozlabs.org/patch/79945/)
>>>        
>    
>>> [PATCH 2/3] check-qdict: Fix possible crash
>>> (http://patchwork.ozlabs.org/patch/79946/)
>>>        
>> Luiz
>>      
> I wouldn't bother with the second one for 0.14.  Yes, we're reading
> lines from a file with %s, but it's a fixed file with known contents, no
> long lines, and we're reading it in a test program only developers ever
> use.
>
> As to the first one, Luiz has never touched that file.  Neither have I,
> and it's not obvious to me why it should go into 0.14.
>
> [...]
>    


Ack for qemu master then?

Re: [Qemu-devel] [PING 0.14] Missing patches (mostly fixes)

[Markus Armbruster]

Stefan Weil <weil@mail.berlios.de> writes:

> Am 04.02.2011 16:27, schrieb Markus Armbruster:
>> Anthony Liguori<anthony@codemonkey.ws>  writes:
>>
>>    
>>> On 02/02/2011 01:28 PM, Stefan Weil wrote:
>>>      
>> [...]
>>    
>>>> [PATCH 1/3] tests: Fix two memory leaks
>>>> (http://patchwork.ozlabs.org/patch/79945/)
>>>>        
>>    
>>>> [PATCH 2/3] check-qdict: Fix possible crash
>>>> (http://patchwork.ozlabs.org/patch/79946/)
>>>>        
>>> Luiz
>>>      
>> I wouldn't bother with the second one for 0.14.  Yes, we're reading
>> lines from a file with %s, but it's a fixed file with known contents, no
>> long lines, and we're reading it in a test program only developers ever
>> use.
>>
>> As to the first one, Luiz has never touched that file.  Neither have I,
>> and it's not obvious to me why it should go into 0.14.
>>
>> [...]
>>    
>
>
> Ack for qemu master then?

I wouldn't bother myself, but I won't object, either.

Re: [Qemu-devel] [PING 0.14] Missing patches (mostly fixes)

[Stefan Weil]

Am 04.02.2011 13:30, schrieb Anthony Liguori:
> On 02/02/2011 01:28 PM, Stefan Weil wrote:
>> Hello,
>>
>> these are some patches which I found on my stack of open patches.
>>
>> All of them should go into 0.14, and at least some of them could also 
>> be applied to 0.13.
>
> This need the following Acks:
>> [PATCH] hw/fmopl: Fix buffer access out-of-bounds errors 
>> (http://patchwork.ozlabs.org/patch/79054/)
> malc

Malc wrote that the patch looks correct, but it is still uncommitted.

> Regards,
>
> Anthony Liguori
>
>> [PATCH] Fix trivial "endianness bugs" 
>> (http://patchwork.ozlabs.org/patch/80223/)
>>
>> [PATCH] HACKING: Update status of format checking 
>> (http://lists.nongnu.org/archive/html/qemu-devel/2011-01/msg02476.html)
>> [PATCH] mingw32: Fix definitions for PRId64, PRIx64, PRIu64, PRIo64 
>> (http://patchwork.ozlabs.org/patch/74276/)

These three patches are still missing in QEMU master.
I don't think that any of the patches is still needed in 0.14.

So in total four of these patches are still waiting for a committer (or 
a comment why they won't be committed).

Thanks to the committers of the other patches.

Regards,
Stefan Weil

Re: [Qemu-devel] Re: [PING 0.14] Missing patches (mostly fixes)

[Riku Voipio]

> >Actually that patch is not ok. The issues you fix on m68k appear
> >on arm/eabi after applying your patch. bswap part appears ok, but
> >the padding is needed atleast on arm.
 
> How do you test this patch ? Do you use native gdb on ARM ? Because, for m68k, cross-compiled gdb does not work (it cannot have sizeof(prstatus_t) for m68k).

I tried both native and cross-gdb, version 7.2. Both fail with your patch applied
and work fine without it.

Before your patch, objdump (CodeSourcery cs2009q3 cross) output looks like:

-snip-
Sections:
Idx Name          Size      VMA       LMA       File off  Algn
  0 note0         000001bc  00000000  00000000  000000d4  2**0
                  CONTENTS, READONLY
  1 .reg/23968    00000048  00000000  00000000  00000130  2**2
                  CONTENTS
  2 .reg          00000048  00000000  00000000  00000130  2**2
                  CONTENTS
  3 .auxv         00000070  00000000  00000000  00000220  2**2
                  CONTENTS
  4 load1         00000000  00008000  00000000  00001000  2**12
                  ALLOC, READONLY, CODE
-snip-

after:

-snip-
Sections:
Idx Name          Size      VMA       LMA       File off  Algn
  0 note0         000001bc  00000000  00000000  000000d4  2**0
                  CONTENTS, READONLY
  1 .auxv         00000070  00000000  00000000  00000220  2**2
                  CONTENTS
  2 load1         00000000  00008000  00000000  00001000  2**12
                  ALLOC, READONLY, CODE
                  CONTENTS, ALLOC, LOAD
-snip-

Re: [Qemu-devel] Re: [PING 0.14] Missing patches (mostly fixes)

[Laurent Vivier]

>On 9 February 2011 09:20, Laurent Vivier <Laurent@vivier.eu> wrote:
>> It is strange as we have in gdb, if I remember correctly, an explicit check 
>of the size of prstatus:
>>
>> gdb/bfd/elf.c:
>>
>>    if defined (HAVE_PRSTATUS_T)
>>
>>    static bfd_boolean
>>    elfcore_grok_prstatus (bfd *abfd, Elf_Internal_Note *note)
>> ...
>>      if (note->descsz == sizeof (prstatus_t))
>> ...
>>
>> How do you test this patch ? Do you use native gdb on ARM ? Because, for 
>m68k, cross-compiled gdb does not work (it cannot have sizeof(prstatus_t) for 
>m68k).
>
>I dunno about m68k, but if ARM gdb behaves differently natively
>versus the cross-tools version (ie hosted on x86 to target ARM)
>then that sounds like a bug we in Linaro would like to know
>about :-)

What I saw for m68k is it cannot access to the saved registers of the core dump  (i.e. you cannot use cross-compiled gdb to debug a core dump ...)

What you can try is to generate a core dump with a "kill -SIGILL" on a qemu-arm process (don't forget to do "ulimit -c unlimited" before) and then load the core with your cross-compiled gdb.

Regards,
Laurent
-- 
--------------------- Laurent@vivier.eu  ---------------------
"Tout ce qui est impossible reste à accomplir"    Jules Verne
"Things are only impossible until they're not" Jean-Luc Picard

Re: [Qemu-devel] Re: [PING 0.14] Missing patches (mostly fixes)

[Peter Maydell]

On 9 February 2011 09:20, Laurent Vivier <Laurent@vivier.eu> wrote:
> It is strange as we have in gdb, if I remember correctly, an explicit check of the size of prstatus:
>
> gdb/bfd/elf.c:
>
>    if defined (HAVE_PRSTATUS_T)
>
>    static bfd_boolean
>    elfcore_grok_prstatus (bfd *abfd, Elf_Internal_Note *note)
> ...
>      if (note->descsz == sizeof (prstatus_t))
> ...
>
> How do you test this patch ? Do you use native gdb on ARM ? Because, for m68k, cross-compiled gdb does not work (it cannot have sizeof(prstatus_t) for m68k).

I dunno about m68k, but if ARM gdb behaves differently natively
versus the cross-tools version (ie hosted on x86 to target ARM)
then that sounds like a bug we in Linaro would like to know
about :-)

-- PMM

Re: [Qemu-devel] Re: [PING 0.14] Missing patches (mostly fixes)

[Laurent Vivier]

>On Sat, Feb 05, 2011 at 10:49:51PM +0100, Laurent Vivier wrote:
>> >On 02/03/2011 12:16 PM, Laurent Vivier wrote:
>> >> And this one ?
>> >>
>> >> linux-user: correct core dump format
>> >>
>> >> http://patchwork.ozlabs.org/patch/78464/
>
>Actually that patch is not ok. The issues you fix on m68k appear
>on arm/eabi after applying your patch. bswap part appears ok, but
>the padding is needed atleast on arm.

It is strange as we have in gdb, if I remember correctly, an explicit check of the size of prstatus:

gdb/bfd/elf.c:

    if defined (HAVE_PRSTATUS_T)

    static bfd_boolean
    elfcore_grok_prstatus (bfd *abfd, Elf_Internal_Note *note)
...
      if (note->descsz == sizeof (prstatus_t))
...

How do you test this patch ? Do you use native gdb on ARM ? Because, for m68k, cross-compiled gdb does not work (it cannot have sizeof(prstatus_t) for m68k).

Regards,
Laurent


-- 
--------------------- Laurent@vivier.eu  ---------------------
"Tout ce qui est impossible reste à accomplir"    Jules Verne
"Things are only impossible until they're not" Jean-Luc Picard

Re: [Qemu-devel] Re: [PING 0.14] Missing patches (mostly fixes)

[Riku Voipio]

On Sat, Feb 05, 2011 at 10:49:51PM +0100, Laurent Vivier wrote:
> >On 02/03/2011 12:16 PM, Laurent Vivier wrote:
> >> And this one ?
> >>
> >> linux-user: correct core dump format
> >>
> >> http://patchwork.ozlabs.org/patch/78464/

Actually that patch is not ok. The issues you fix on m68k appear
on arm/eabi after applying your patch. bswap part appears ok, but
the padding is needed atleast on arm.

Riku

Re: [Qemu-devel] Re: [PING 0.14] Missing patches (mostly fixes)

[Anthony Liguori]

On 02/05/2011 01:40 PM, riku voipio wrote:
> On 02/03/2011 12:16 PM, Laurent Vivier wrote:
>>> On Wed, Feb 02, 2011 at 08:28:15PM +0100, Stefan Weil wrote:
>>>> [PATCH] linux-user: Fix possible realloc memory leak
>>>> (http://patchwork.ozlabs.org/patch/79217/)
>>> Looks ok for me.
>
>> And this one ?
>>
>> linux-user: correct core dump format
>>
>> http://patchwork.ozlabs.org/patch/78464/
>
> Do you need it for 0.14 ?
>
> I intend to include this and other in a pull request for master soon.

This looks reasonably important.  Can you just do a pull request for 
master for the patches that might be good for 0.14?

If you can do that in the next couple days, it'll make it into -rc2 no 
problem.

Regards,

Anthony Liguori

> Riku
>

Re: [Qemu-devel] Re: [PING 0.14] Missing patches (mostly fixes)

[Laurent Vivier]

Hi,

I've no need, just put it in your tree where you want...

Regards,
Laurent

riku voipio <riku.voipio@iki.fi> a écrit :

>On 02/03/2011 12:16 PM, Laurent Vivier wrote:
>>> On Wed, Feb 02, 2011 at 08:28:15PM +0100, Stefan Weil wrote:
>>>> [PATCH] linux-user: Fix possible realloc memory leak
>>>> (http://patchwork.ozlabs.org/patch/79217/)
>>> Looks ok for me.
>
>> And this one ?
>>
>> linux-user: correct core dump format
>>
>> http://patchwork.ozlabs.org/patch/78464/
>
>Do you need it for 0.14 ?
>
>I intend to include this and other in a pull request for master soon.
>
>Riku

Re: [Qemu-devel] Re: [PING 0.14] Missing patches (mostly fixes)

[riku voipio]

On 02/03/2011 12:16 PM, Laurent Vivier wrote:
>> On Wed, Feb 02, 2011 at 08:28:15PM +0100, Stefan Weil wrote:
>>> [PATCH] linux-user: Fix possible realloc memory leak
>>> (http://patchwork.ozlabs.org/patch/79217/)
>> Looks ok for me.

> And this one ?
>
> linux-user: correct core dump format
>
> http://patchwork.ozlabs.org/patch/78464/

Do you need it for 0.14 ?

I intend to include this and other in a pull request for master soon.

Riku

RE: [Qemu-devel] Re: [PING 0.14] Missing patches (mostly fixes)

[Laurent Vivier]

>On Wed, Feb 02, 2011 at 08:28:15PM +0100, Stefan Weil wrote:
>> [PATCH] linux-user: Fix possible realloc memory leak  
>> (http://patchwork.ozlabs.org/patch/79217/)
>
>Looks ok for me.

And this one ?

linux-user: correct core dump format

http://patchwork.ozlabs.org/patch/78464/

Laurent

-- 
--------------------- Laurent@vivier.eu  ---------------------
"Tout ce qui est impossible reste à accomplir"    Jules Verne
"Things are only impossible until they're not" Jean-Luc Picard