qemu-stable
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH v2] pc: Don't make die-id mandatory unless neces


From: Philippe Mathieu-Daudé
Subject: Re: [Qemu-devel] [PATCH v2] pc: Don't make die-id mandatory unless necessary
Date: Wed, 3 Feb 2021 17:07:24 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.6.0

Cc'ing avocado-devel for test ideas.

On 8/28/19 6:57 PM, Igor Mammedov wrote:
> On Wed, 28 Aug 2019 11:35:24 -0300
> Eduardo Habkost <ehabkost@redhat.com> wrote:
> 
>> On Wed, Aug 28, 2019 at 08:52:28AM +0200, Markus Armbruster wrote:
...
>>> In addition, I'd like us to either work on making the rule stick in the
>>> future (see my reply to Igor for an idea), or ditch the rule.  But
>>> that's outside the scope of this regression fix.  
>>
>> I'd prefer to ditch the rule, or at least change it to be a
>> suggestion instead of a requirement.
> Perhaps someone reads docs and uses API as designed (libvirt is not the only 
> user)
> 
> I'd prefer to allow implicit die-id in 4.1 and 'stable' as that
> ship has already sailed and make it mandatory since 4.2 as it is
> supposed to be (+opening bug on libvirt - hoping that API would
> be fixed properly this time).
> 
> 
> Another related to die-id series bug:
> We should hide die-id from query-hotpluggable-cpus output
> for 4.0 and older machine types as well, so it won't break
> migration for users that implement interface as documented
> as it won't be possible to start
>  old-qemu-4.0 -device cpufoo,die-id=0,...
> since that "-device cpufoo,die-id=0,..." were used on new-qemu source.
> 
> PS:
> Adding affected targets maintainers to the loop to see if
> we can drop restriction.
> 
> Even though it works fine for die-id and I don't see immediate problems
> with relaxing rule, I reluctant to do it, since instead of simple
>  "add all properties you were told to"
> implicit rules would evolve into mess similar to smp_parse() over time.
> 
> Also if we would need to change implicit values logic down the road
> it would be a pain like with any default parameters in QEMU, which is
> a good reason against relaxing rule.
> 
> 




reply via email to

[Prev in Thread] Current Thread [Next in Thread]