[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH v3 06/17] hw/sd/sdcard: Do not store vendor data on block dri
From: |
Peter Xu |
Subject: |
Re: [PATCH v3 06/17] hw/sd/sdcard: Do not store vendor data on block drive (CMD56) |
Date: |
Wed, 10 Jul 2024 16:11:53 -0400 |
On Wed, Jul 10, 2024 at 04:48:23PM -0300, Fabiano Rosas wrote:
> Peter Xu <peterx@redhat.com> writes:
>
> > On Wed, Jul 10, 2024 at 01:21:51PM -0300, Fabiano Rosas wrote:
> >> It's not about trust, we simply don't support migrations other than
> >> n->n+1 and (maybe) n->n-1. So QEMU from 2016 is certainly not included.
> >
> > Where does it come from? I thought we suppport that..
>
> I'm taking that from:
>
> docs/devel/migration/main.rst:
> "In general QEMU tries to maintain forward migration compatibility
> (i.e. migrating from QEMU n->n+1) and there are users who benefit from
> backward compatibility as well."
>
> But of course it doesn't say whether that comes with a transitive rule
> allowing n->n+2 migrations.
I'd say that "i.e." implies n->n+1 is not the only forward migration we
would support.
I _think_ we should support all forward migration as long as the machine
type matches.
>
> >
> > The same question would be: are we requesting an OpenStack cluster to
> > always upgrade QEMU with +1 versions, otherwise migration will fail?
>
> Will an OpenStack cluster be using upstream QEMU? If not, then that's a
It's an example to show what I meant! :) Nothing else. Definitely not
saying that everyone should use an upstream released QEMU (but in reality,
it's not a problem, I think, and I do feel like people use them, perhaps
more with the stable releases).
> question for the distro. In a very practical sense, we're not requesting
> anything. We barely test n->n+1/n->n-1, even if we had a strong support
> statement I wouldn't be confident saying migration from QEMU 2.7 -> QEMU
> 9.1 should succeed.
No matter what we test in CI, I don't think we should break that for >1
versions.. I hope 2.7->9.1 keeps working, otherwise I think it's legal to
file a bug by anyone.
For example, I randomly fetched a bug report:
https://gitlab.com/qemu-project/qemu/-/issues/1937
QEMU version: 6.2 and 7.2.5
And I believe that's the common case even for upstream. If we don't do
that right for upstream, it can be impossible tasks for downstream and for
all of us to maintain.
--
Peter Xu
- Re: [PATCH v3 06/17] hw/sd/sdcard: Do not store vendor data on block drive (CMD56), Fabiano Rosas, 2024/07/09
- Re: [PATCH v3 06/17] hw/sd/sdcard: Do not store vendor data on block drive (CMD56), Peter Xu, 2024/07/09
- Re: [PATCH v3 06/17] hw/sd/sdcard: Do not store vendor data on block drive (CMD56), Fabiano Rosas, 2024/07/10
- Re: [PATCH v3 06/17] hw/sd/sdcard: Do not store vendor data on block drive (CMD56), Peter Xu, 2024/07/10
- Re: [PATCH v3 06/17] hw/sd/sdcard: Do not store vendor data on block drive (CMD56), Fabiano Rosas, 2024/07/10
- Re: [PATCH v3 06/17] hw/sd/sdcard: Do not store vendor data on block drive (CMD56), Peter Xu, 2024/07/10
- Re: [PATCH v3 06/17] hw/sd/sdcard: Do not store vendor data on block drive (CMD56), Fabiano Rosas, 2024/07/10
- Re: [PATCH v3 06/17] hw/sd/sdcard: Do not store vendor data on block drive (CMD56),
Peter Xu <=
- Re: [PATCH v3 06/17] hw/sd/sdcard: Do not store vendor data on block drive (CMD56), Fabiano Rosas, 2024/07/10
- Re: [PATCH v3 06/17] hw/sd/sdcard: Do not store vendor data on block drive (CMD56), Peter Xu, 2024/07/10
- Re: [PATCH v3 06/17] hw/sd/sdcard: Do not store vendor data on block drive (CMD56), Fabiano Rosas, 2024/07/11
- Re: [PATCH v3 06/17] hw/sd/sdcard: Do not store vendor data on block drive (CMD56), Peter Xu, 2024/07/11
- Re: [PATCH v3 06/17] hw/sd/sdcard: Do not store vendor data on block drive (CMD56), Fabiano Rosas, 2024/07/11
- Re: [PATCH v3 06/17] hw/sd/sdcard: Do not store vendor data on block drive (CMD56), Peter Xu, 2024/07/11
- Re: [PATCH v3 06/17] hw/sd/sdcard: Do not store vendor data on block drive (CMD56), Fabiano Rosas, 2024/07/11