QEMU stable 7.2.1

QEMU stable 7.2.1

[Michael Tokarev]

So let it be, with a delay of about a week.

Since no one from the qemu team replied to my final-release steps, I'm
making it available on my site instead:

   http://www.corpit.ru/mjt/qemu/qemu-7.2.1.tar.xz
   http://www.corpit.ru/mjt/qemu/qemu-7.2.1.tar.xz.sig - signed with my GPG key
   http://www.corpit.ru/mjt/qemu/qemu-7.2.1.diff - whole difference from 7.2.0.

The tag (v7.2.1) is in the main qemu repository.

The shortlog:

Akihiko Odaki (4):
       vhost-user-gpio: Configure vhost_dev when connecting
       vhost-user-i2c: Back up vqs before cleaning up vhost_dev
       vhost-user-rng: Back up vqs before cleaning up vhost_dev
       hw/timer/hpet: Fix expiration time overflow

Alex Bennée (2):
       target/arm: fix handling of HLT semihosting in system mode
       tests/tcg: fix unused variable in linux-test

Anton Johansson (1):
       block: Handle curl 7.55.0, 7.85.0 version changes

Carlos López (2):
       vhost: avoid a potential use of an uninitialized variable in vhost_svq_poll()
       libvhost-user: check for NULL when allocating a virtqueue element

Chenyi Qiang (2):
       virtio-mem: Fix the bitmap index of the section offset
       virtio-mem: Fix the iterator variable in a vmem->rdl_list loop

David Hildenbrand (2):
       migration/ram: Fix error handling in ram_write_tracking_start()
       migration/ram: Fix populate_read_range()

Dr. David Alan Gilbert (2):
       virtio-rng-pci: fix migration compat for vectors
       virtio-rng-pci: fix transitional migration compat for vectors

Eugenio Pérez (1):
       vdpa: stop all svq on device deletion

Evgeny Iakovlev (1):
       target/arm: allow writes to SCR_EL3.HXEn bit when FEAT_HCX is enabled

Guenter Roeck (1):
       target/sh4: Mask restore of env->flags from tb->flags

Jason Wang (3):
       vhost: fix vq dirty bitmap syncing when vIOMMU is enabled
       intel-iommu: fail MAP notifier without caching mode
       intel-iommu: fail DEVIOTLB_UNMAP without dt mode

Julia Suvorova (1):
       hw/smbios: fix field corruption in type 4 table

Kevin Wolf (1):
       qcow2: Fix theoretical corruption in store_bitmap() error path

Klaus Jensen (2):
       hw/nvme: fix missing endian conversions for doorbell buffers
       hw/nvme: fix missing cq eventidx update

Laszlo Ersek (1):
       acpi: cpuhp: fix guest-visible maximum access size to the legacy reg block

Marc-André Lureau (1):
       build-sys: fix crlf-ending C code

Michael S. Tsirkin (6):
       Revert "x86: do not re-randomize RNG seed on snapshot load"
       Revert "x86: re-initialize RNG seed when selecting kernel"
       Revert "x86: reinitialize RNG seed on system reboot"
       Revert "x86: use typedef for SetupData struct"
       Revert "x86: return modified setup_data only if read as memory, not as file"
       Revert "hw/i386: pass RNG seed via setup_data entry"

Michael Tokarev (1):
       Update version for 7.2.1 release

Paolo Bonzini (4):
       meson: accept relative symlinks in "meson introspect --installed" data
       configure: fix GLIB_VERSION for cross-compilation
       target/i386: fix ADOX followed by ADCX
       block/iscsi: fix double-free on BUSY or similar statuses

Richard Henderson (8):
       target/riscv: Set pc_succ_insn for !rvc illegal insn
       target/arm: Fix sve_probe_page
       target/arm: Fix in_debug path in S1_ptw_translate
       target/arm: Fix physical address resolution for Stage2
       tests/tcg/i386: Introduce and use reg_t consistently
       target/i386: Fix BEXTR instruction
       target/i386: Fix C flag for BLSI, BLSMSK, BLSR
       target/i386: Fix BZHI instruction

Stefan Hajnoczi (1):
       block: fix detect-zeroes= with BDRV_REQ_REGISTERED_BUF

Yajun Wu (1):
       chardev/char-socket: set s->listener = NULL in char_socket_finalize

I want to make another release of 7.2 series.

Thank you all for all the help with this series!

/mjt

Re: QEMU stable 7.2.1

[Michael Roth via]

On Wed, Apr 05, 2023 at 02:54:47PM +0300, Michael Tokarev wrote:
> So let it be, with a delay of about a week.
> 
> Since no one from the qemu team replied to my final-release steps, I'm
> making it available on my site instead:
> 
>   http://www.corpit.ru/mjt/qemu/qemu-7.2.1.tar.xz
>   http://www.corpit.ru/mjt/qemu/qemu-7.2.1.tar.xz.sig - signed with my GPG key
>   http://www.corpit.ru/mjt/qemu/qemu-7.2.1.diff - whole difference from 7.2.0.
> 
> The tag (v7.2.1) is in the main qemu repository.

Hi Michael,

Thanks for handling this release!

Somehow I missed your final steps email, but for future releases I would
recommend going ahead and tagging your release (also signed with your GPG
key) in your local tree once you've got everything ready, and then sending
me an email to directly so I can push that to gitlab and then handle
creating the tarball and publish it with my GPG key. That's basically what
we do for the normal QEMU releases as well.

Then once you get your accounts set up by gitlab/qemu.org admins you can
handle the tag-pushing/tarball-uploading on your end. Would be good to
have someone else involved with that process so we have some redundancy
just in case.

For 7.2.1:

I could also upload your tarball, but we'd also want a signed .bz2 tarball
to accomodate any environments that still try to consume the .bz2 versions
(even though we don't actively advertise them on the website). We'd also
need to update the GPG key published on the website at
https://www.qemu.org/download/

So for this one it might make sense to keep the tarball published where you
have it, and I'll just mirror your 7.2.1 tag to QEMU gitlab under a new
stable-7.2 branch like we've done in the past. Then for subsequent
releases I'll publish as mentioned above until you have upload/push access.

If that sounds reasonable to you (and everyone else) I'll go ahead and
push the stable-7.2/7.2.1 branches to by gitlab EOD tomorrow my time.

Thanks!

-Mike

> 
> The shortlog:
> 
> Akihiko Odaki (4):
>       vhost-user-gpio: Configure vhost_dev when connecting
>       vhost-user-i2c: Back up vqs before cleaning up vhost_dev
>       vhost-user-rng: Back up vqs before cleaning up vhost_dev
>       hw/timer/hpet: Fix expiration time overflow
> 
> Alex Bennée (2):
>       target/arm: fix handling of HLT semihosting in system mode
>       tests/tcg: fix unused variable in linux-test
> 
> Anton Johansson (1):
>       block: Handle curl 7.55.0, 7.85.0 version changes
> 
> Carlos López (2):
>       vhost: avoid a potential use of an uninitialized variable in vhost_svq_poll()
>       libvhost-user: check for NULL when allocating a virtqueue element
> 
> Chenyi Qiang (2):
>       virtio-mem: Fix the bitmap index of the section offset
>       virtio-mem: Fix the iterator variable in a vmem->rdl_list loop
> 
> David Hildenbrand (2):
>       migration/ram: Fix error handling in ram_write_tracking_start()
>       migration/ram: Fix populate_read_range()
> 
> Dr. David Alan Gilbert (2):
>       virtio-rng-pci: fix migration compat for vectors
>       virtio-rng-pci: fix transitional migration compat for vectors
> 
> Eugenio Pérez (1):
>       vdpa: stop all svq on device deletion
> 
> Evgeny Iakovlev (1):
>       target/arm: allow writes to SCR_EL3.HXEn bit when FEAT_HCX is enabled
> 
> Guenter Roeck (1):
>       target/sh4: Mask restore of env->flags from tb->flags
> 
> Jason Wang (3):
>       vhost: fix vq dirty bitmap syncing when vIOMMU is enabled
>       intel-iommu: fail MAP notifier without caching mode
>       intel-iommu: fail DEVIOTLB_UNMAP without dt mode
> 
> Julia Suvorova (1):
>       hw/smbios: fix field corruption in type 4 table
> 
> Kevin Wolf (1):
>       qcow2: Fix theoretical corruption in store_bitmap() error path
> 
> Klaus Jensen (2):
>       hw/nvme: fix missing endian conversions for doorbell buffers
>       hw/nvme: fix missing cq eventidx update
> 
> Laszlo Ersek (1):
>       acpi: cpuhp: fix guest-visible maximum access size to the legacy reg block
> 
> Marc-André Lureau (1):
>       build-sys: fix crlf-ending C code
> 
> Michael S. Tsirkin (6):
>       Revert "x86: do not re-randomize RNG seed on snapshot load"
>       Revert "x86: re-initialize RNG seed when selecting kernel"
>       Revert "x86: reinitialize RNG seed on system reboot"
>       Revert "x86: use typedef for SetupData struct"
>       Revert "x86: return modified setup_data only if read as memory, not as file"
>       Revert "hw/i386: pass RNG seed via setup_data entry"
> 
> Michael Tokarev (1):
>       Update version for 7.2.1 release
> 
> Paolo Bonzini (4):
>       meson: accept relative symlinks in "meson introspect --installed" data
>       configure: fix GLIB_VERSION for cross-compilation
>       target/i386: fix ADOX followed by ADCX
>       block/iscsi: fix double-free on BUSY or similar statuses
> 
> Richard Henderson (8):
>       target/riscv: Set pc_succ_insn for !rvc illegal insn
>       target/arm: Fix sve_probe_page
>       target/arm: Fix in_debug path in S1_ptw_translate
>       target/arm: Fix physical address resolution for Stage2
>       tests/tcg/i386: Introduce and use reg_t consistently
>       target/i386: Fix BEXTR instruction
>       target/i386: Fix C flag for BLSI, BLSMSK, BLSR
>       target/i386: Fix BZHI instruction
> 
> Stefan Hajnoczi (1):
>       block: fix detect-zeroes= with BDRV_REQ_REGISTERED_BUF
> 
> Yajun Wu (1):
>       chardev/char-socket: set s->listener = NULL in char_socket_finalize
> 
> I want to make another release of 7.2 series.
> 
> Thank you all for all the help with this series!
> 
> /mjt
> 

Re: QEMU stable 7.2.1

[Michael Tokarev]

05.04.2023 16:58, Michael Roth wrote:
> On Wed, Apr 05, 2023 at 02:54:47PM +0300, Michael Tokarev wrote:
>> So let it be, with a delay of about a week.
>>
>> Since no one from the qemu team replied to my final-release steps, I'm
>> making it available on my site instead:
>>
>>    http://www.corpit.ru/mjt/qemu/qemu-7.2.1.tar.xz
>>    http://www.corpit.ru/mjt/qemu/qemu-7.2.1.tar.xz.sig - signed with my GPG key
>>    http://www.corpit.ru/mjt/qemu/qemu-7.2.1.diff - whole difference from 7.2.0.
>>
>> The tag (v7.2.1) is in the main qemu repository.
> 
> Hi Michael,
> 
> Thanks for handling this release!
> 
> Somehow I missed your final steps email, but for future releases I would
> recommend going ahead and tagging your release (also signed with your GPG
> key) in your local tree once you've got everything ready, and then sending
> me an email to directly so I can push that to gitlab and then handle
> creating the tarball and publish it with my GPG key. That's basically what
> we do for the normal QEMU releases as well.
> 
> Then once you get your accounts set up by gitlab/qemu.org admins you can
> handle the tag-pushing/tarball-uploading on your end. Would be good to
> have someone else involved with that process so we have some redundancy
> just in case.

Thank you for the reply!

I'm not sure I follow you here. I already pushed v7.2.1 tag and stable-7.2
branch to gitlab/qemu. The branch has been there for quite some time.

Should I avoid tagging/pushing for the future or is it okay to do that?

For the tarballs, it's definitely better to follow the established practice,
I published the generated tarball on my site just as a last-resort, so that
it ends up *somewhere*. It should be prepared the same way as other releases
has been made, including the .bz2 version.

If that's okay with you, feel free to re-create the tarball from v7.2.1
tag, and compress the tarball with whatever compressors usually used by
the qemu team.  It's the way to go.

Thanks,

/mjt

Re: QEMU stable 7.2.1

[Michael Roth]

On Wed, Apr 05, 2023 at 05:16:33PM +0300, Michael Tokarev wrote:
> 05.04.2023 16:58, Michael Roth wrote:
> > On Wed, Apr 05, 2023 at 02:54:47PM +0300, Michael Tokarev wrote:
> > > So let it be, with a delay of about a week.
> > > 
> > > Since no one from the qemu team replied to my final-release steps, I'm
> > > making it available on my site instead:
> > > 
> > >    http://www.corpit.ru/mjt/qemu/qemu-7.2.1.tar.xz
> > >    http://www.corpit.ru/mjt/qemu/qemu-7.2.1.tar.xz.sig - signed with my GPG key
> > >    http://www.corpit.ru/mjt/qemu/qemu-7.2.1.diff - whole difference from 7.2.0.
> > > 
> > > The tag (v7.2.1) is in the main qemu repository.
> > 
> > Hi Michael,
> > 
> > Thanks for handling this release!
> > 
> > Somehow I missed your final steps email, but for future releases I would
> > recommend going ahead and tagging your release (also signed with your GPG
> > key) in your local tree once you've got everything ready, and then sending
> > me an email to directly so I can push that to gitlab and then handle
> > creating the tarball and publish it with my GPG key. That's basically what
> > we do for the normal QEMU releases as well.
> > 
> > Then once you get your accounts set up by gitlab/qemu.org admins you can
> > handle the tag-pushing/tarball-uploading on your end. Would be good to
> > have someone else involved with that process so we have some redundancy
> > just in case.
> 
> Thank you for the reply!
> 
> I'm not sure I follow you here. I already pushed v7.2.1 tag and stable-7.2
> branch to gitlab/qemu. The branch has been there for quite some time.

Oh! Nice, didn't realize you were set up there already. Just noticed the
7.2.1 tag when pulling down 8.0.0-rc3.

That also helped me notice that your reply here got quarantined by my email
server, along with a number of your previous emails relating to stable, so
that explains how those slipped by (the ones that hit the mailing list
still show up if I'm looking in the right place).

I'll keep a better eye out for this in the future and try to reach an
understanding with this advanced AI technology that treats straight-forward
direct replies to my emails as spam for inexplicable reasons.

> 
> Should I avoid tagging/pushing for the future or is it okay to do that?

Nope, that's fine. Just ignore my comments regarding git, everything seems
to be good on that end.

One thing I forgot to mention previously is updating the wiki with the
release schedule once you have an idea of when you plan to push your tags.
E.g.:

  https://wiki.qemu.org/Planning/7.2

I usually set the date once I have the initial staging ready and get
ready to send out the "patch round-up" with expected freeze/release
dates. Might be good to email me directly or Cc: me on related
announcements around that time so I can make sure I'm around.

> 
> For the tarballs, it's definitely better to follow the established practice,
> I published the generated tarball on my site just as a last-resort, so that
> it ends up *somewhere*. It should be prepared the same way as other releases
> has been made, including the .bz2 version.
> 
> If that's okay with you, feel free to re-create the tarball from v7.2.1
> tag, and compress the tarball with whatever compressors usually used by
> the qemu team.  It's the way to go.

Ok, sure, I'll go ahead and re-publish 7.2.1 tarball a bit later today.

We can stick with this approach until you're all set up for uploading.

-Mike

> 
> Thanks,
> 
> /mjt
> 

Re: QEMU stable 7.2.1

[Peter Maydell]

On Wed, 5 Apr 2023 at 19:58, Michael Roth <michael.roth@amd.com> wrote:
> One thing I forgot to mention previously is updating the wiki with the
> release schedule once you have an idea of when you plan to push your tags.

On a slight tangent, do you have the process you use for
releases (main as well as stable-branch ones) written down
somewhere? It might be handy if we ever need to pass that
duty on to somebody else (or if you're bored with it and
want to rotate it between multiple people...)

thanks
-- PMM

Re: QEMU stable 7.2.1

[Michael Roth]

On Wed, Apr 05, 2023 at 01:57:20PM -0500, Michael Roth wrote:
> On Wed, Apr 05, 2023 at 05:16:33PM +0300, Michael Tokarev wrote:
> > 05.04.2023 16:58, Michael Roth wrote:
> > > On Wed, Apr 05, 2023 at 02:54:47PM +0300, Michael Tokarev wrote:
> > > > So let it be, with a delay of about a week.
> > > > 
> > > > Since no one from the qemu team replied to my final-release steps, I'm
> > > > making it available on my site instead:
> > > > 
> > > >    http://www.corpit.ru/mjt/qemu/qemu-7.2.1.tar.xz
> > > >    http://www.corpit.ru/mjt/qemu/qemu-7.2.1.tar.xz.sig - signed with my GPG key
> > > >    http://www.corpit.ru/mjt/qemu/qemu-7.2.1.diff - whole difference from 7.2.0.
> > > > 
> > > > The tag (v7.2.1) is in the main qemu repository.
> > > 
> > 
> > For the tarballs, it's definitely better to follow the established practice,
> > I published the generated tarball on my site just as a last-resort, so that
> > it ends up *somewhere*. It should be prepared the same way as other releases
> > has been made, including the .bz2 version.
> > 
> > If that's okay with you, feel free to re-create the tarball from v7.2.1
> > tag, and compress the tarball with whatever compressors usually used by
> > the qemu team.  It's the way to go.
> 
> Ok, sure, I'll go ahead and re-publish 7.2.1 tarball a bit later today.

Re-packaged tarball based on your 7.2.1 tag is now uploaded:

  https://www.qemu.org/download/

-Mike

> 
> We can stick with this approach until you're all set up for uploading.
> 
> -Mike
> 
> > 
> > Thanks,
> > 
> > /mjt
> > 

Re: QEMU stable 7.2.1

[Michael Tokarev]

06.04.2023 00:06, Michael Roth пишет:
..
> Re-packaged tarball based on your 7.2.1 tag is now uploaded:
> 
>    https://www.qemu.org/download/

Thank you Michael!  Finally it's there :)

There's one minor caveat still, though: it is missing in the
"Full list of releases" for whatever reason.  Dunno how that
happened, maybe that page hasn't been (re)generated yet.

/mjt

Re: QEMU stable 7.2.1

[Thomas Huth]

On 06/04/2023 08.33, Michael Tokarev wrote:
> 06.04.2023 00:06, Michael Roth пишет:
> ..
>> Re-packaged tarball based on your 7.2.1 tag is now uploaded:
>>
>>    https://www.qemu.org/download/
> 
> Thank you Michael!  Finally it's there :)
> 
> There's one minor caveat still, though: it is missing in the
> "Full list of releases" for whatever reason.  Dunno how that
> happened, maybe that page hasn't been (re)generated yet.

FWIW, I can see it on https://download.qemu.org/ now.

But there's another thing I noticed:

On the homepage and on https://www.qemu.org/download/ the date of 7.2.1 is 
still the date of 7.2.0 (Mar 30th 2022) ... do we want to update this, or do 
we want to indicate the original release date of 7.2 there?

  Thomas

Re: QEMU stable 7.2.1

[Michael Tokarev]

06.04.2023 09:48, Thomas Huth пишет:
..>> There's one minor caveat still, though: it is missing in the
>> "Full list of releases" for whatever reason.  Dunno how that
>> happened, maybe that page hasn't been (re)generated yet.
> 
> FWIW, I can see it on https://download.qemu.org/ now.

I still can't, no matter how many times I hit browser "Reload"
button, or try another browser or even another computer.

It's available as a direct link but not in the listing page.

/mjt

Re: QEMU stable 7.2.1

[Michael Roth]

On Thu, Apr 06, 2023 at 08:48:34AM +0200, Thomas Huth wrote:
> On 06/04/2023 08.33, Michael Tokarev wrote:
> > 06.04.2023 00:06, Michael Roth пишет:
> > ..
> > > Re-packaged tarball based on your 7.2.1 tag is now uploaded:
> > > 
> > >    https://www.qemu.org/download/
> > 
> > Thank you Michael!  Finally it's there :)
> > 
> > There's one minor caveat still, though: it is missing in the
> > "Full list of releases" for whatever reason.  Dunno how that
> > happened, maybe that page hasn't been (re)generated yet.
> 
> FWIW, I can see it on https://download.qemu.org/ now.
> 
> But there's another thing I noticed:
> 
> On the homepage and on https://www.qemu.org/download/ the date of 7.2.1 is
> still the date of 7.2.0 (Mar 30th 2022) ... do we want to update this, or do
> we want to indicate the original release date of 7.2 there?

Thanks for the catch. The date should reflect the date the current
mainline/stable release was tagged, so I've updated it accordingly.

-Mike

> 
>  Thomas
> 
> 

Re: QEMU stable 7.2.1

[Michael Roth]

On Thu, Apr 06, 2023 at 09:54:55AM +0300, Michael Tokarev wrote:
> 06.04.2023 09:48, Thomas Huth пишет:
> ..>> There's one minor caveat still, though: it is missing in the
> > > "Full list of releases" for whatever reason.  Dunno how that
> > > happened, maybe that page hasn't been (re)generated yet.
> > 
> > FWIW, I can see it on https://download.qemu.org/ now.
> 
> I still can't, no matter how many times I hit browser "Reload"
> button, or try another browser or even another computer.
> 
> It's available as a direct link but not in the listing page.

Yah... I'm noticing the same issue with 8.0.0-rc3 not showing up under
"Full list of releases" either. 8.0.0-rc2 shows up fine however, and I'm
not aware of any changes between -rc2 and -rc3 that would affect how
these pages are generated.

The associated gitlab build jobs for the latest qemu-web.git update look
okay to me too:

  https://gitlab.com/qemu-project/qemu-web/-/pipelines/830133154/builds

I'm not even sure this page is actually generated by those jobs though,
it just seems like a direct link to whatever download.qemu.org statically
points to. So maybe there something else server-side that might be going
wrong?

I suppose it could just be some aggressive caching somewhere
server-side. I've never actually checked the "Full list of releases"
right after uploading, so it's possible it takes ~days to refresh and
we just happen to be noticing that now.

-Mike


> 
> /mjt
>