Re: [Qemu-devel] [PATCHv4 0/5] Clean up compatibility mode handling

[Greg Kurz <groug@kaod.org>]

[-- Attachment #1: Type: text/plain, Size: 2931 bytes --]

On Fri, 2 Jun 2017 12:00:07 +1000
David Gibson <david@gibson.dropbear.id.au> wrote:

> On Thu, Jun 01, 2017 at 03:09:15PM +0200, Greg Kurz wrote:
> > On Thu, 1 Jun 2017 13:59:14 +0200
> > Cédric Le Goater <clg@kaod.org> wrote:
> >   
> > > On 06/01/2017 08:52 AM, David Gibson wrote:  
> > > > On Wed, May 31, 2017 at 10:58:57AM +0200, Greg Kurz wrote:    
> > > >> On Wed, 31 May 2017 12:57:48 +1000
> > > >> David Gibson <david@gibson.dropbear.id.au> wrote:    
> > > >>> [...]    
> > > >>>> All old non-pseries machine types already complain when started with
> > > >>>> a POWER7 or newer CPU. Providing the extra error message looks weird:
> > > >>>>
> > > >>>> qemu-system-ppc64 -machine ppce500 \
> > > >>>>                   -cpu POWER7,compat=power6
> > > >>>> qemu-system-ppc64: CPU 'compat' property is deprecated and has no effect;
> > > >>>>  use max-cpu-compat machine property instead
> > > >>>> MMU model 983043 not supported by this machine.
> > > >>>>
> > > >>>> but I guess it's better than crashing. :)      
> > > >>>
> > > >>> Well, sure POWER7 doesn't make sense for an e500 machine for other
> > > >>> reasons.  But POWER7 or POWER8 _would_ make sense for powernv, where
> > > >>> compat= doesn't.
> > > >>>    
> > > >>
> > > >> The powernv machine type doesn't even support CPU features at all:
> > > >>
> > > >>     chip_typename = g_strdup_printf(TYPE_PNV_CHIP "-%s", machine->cpu_model);
> > > >>     if (!object_class_by_name(chip_typename)) {
> > > >>         error_report("invalid CPU model '%s' for %s machine",
> > > >>                      machine->cpu_model, MACHINE_GET_CLASS(machine)->name);
> > > >>         exit(1);
> > > >>     }    
> > > > 
> > > > Ah, well, that's another bug, but not one that's in scope for this
> > > > series.    
> > > 
> > > PowerNV is still work in progress. I would not worry about it too much.
> > >   
> > 
> > Of course and this isn't the purpose of the discussion actually. We were
> > talking about CPU features being relevant or not depending on the machine
> > type.
> > 
> > But I'm not even sure that CPU features are useful at all for ppc, not to
> > say very confusing (otherwise this series wouldn't be needed for example).
> > 
> > Speaking of PowerNV, just as an example, I guess the fix would be to
> > forbid machine->cpu_model if it contains features. And probably the same
> > for all other machine types, except pseries for backward compatibility
> > reasons.  
> 
> I don't think that's correct in principle.  I can imagine CPU
> properties it might make sense to really set on the cpu, regardless of
> machine type.  A quick look says we don't have any such at the moment,
> but I don't think it's something we should prevent as a matter of policy.
> 

Fair enough. Then maybe all machine should parse CPU features and check which
one are valid before instantiating the CPUs ?

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]