Re: [Qemu-devel] [PATCH v3] hw/i386: Deprecate the machines pc-0.10 to pc-1.2

[Thomas Huth]

On 14.07.2017 01:04, Michael S. Tsirkin wrote:
> On Thu, Jul 13, 2017 at 12:20:10PM -0300, Eduardo Habkost wrote:
>> On Thu, Jul 13, 2017 at 04:00:00AM +0300, Michael S. Tsirkin wrote:
>>> On Wed, Jul 12, 2017 at 10:22:33AM +0200, Thomas Huth wrote:
>>>> We don't want to carry along old machine types forever. If we are able to
>>>> remove the pc machines up to 0.13 one day for example, this would allow
>>>> us to eventually kill the code for rombar=0 (i.e. where QEMU copies ROM
>>>> BARs directly to low memory). Everything up to pc-1.2 is also known to
>>>> have issues with migration.  So let's start with a deprecation message
>>>> for the old machine types so that the (hopefully) few users of these old
>>>> systems start switching over to newer machine types instead.
>>>>
>>>> Signed-off-by: Thomas Huth <address@hidden>
>>>> ---
>>>>  Note: Even if we mark all these old machines as deprecated, this ofcourse
>>>>  doesn't mean that we also have to remove them all at once later when we
>>>>  decide to finally really remove some. We could then also start by removing
>>>>  0.10 and 0.11 only, for example (since there should really be no users 
>>>> left
>>>>  for these), or only up to 0.13 (to be able to kill rombar=0).
>>>
>>> So I generally think the main issue is that machine types are conflating
>>> two things. One is saying "I want to be able to migrate from/to QEMU X".
>>> Another is saying "I want to look to guests as if I am QEMU X
>>> but I restart gurst on the new QEMU".
>>>
>>> First is generally a superset of the second, but only a subset of
>>> users needs the first. And while there's a very good chance we
>>> are actually pretty close to supporting the second even for very
>>> old machine types, I doubt we are actually able to migrate to/from
>>> these old QEMU versions since it is so hard to test.
>>>
>>> So IMHO, a more significant step with a long term impact would be to
>>> support splitting these things up.
>>
>> I agree they are different things, but do we really have
>> volunteers willing to maintain a machine-type just because of the
>> latter?  Setting the same deprecation policy for the two features
>> sounds simpler to me.
> 
> Removing the former might kind of work just this once on the assumption
> that we did not have real users back then, but fundamentally users have
> no safe way to upgrade machine types right now. It's stored in the
> machine XML at install time and that's it, and reinstalling guests
> is very painful.
> 
> So starting with version X when we did have real users, we really have
> to maintain the latter literally forever, volunteers or not.

Do we? If someone has a VM that depends on a veeery old machine type
(and it can not be started with a newer machine type - which is quite
unlikely since they are normally very similar), I guess they could also
simply use older versions of QEMU for that VM instead.

 Thomas