Re: [PATCH 3/3] x86: Switch to q35 as the default machine type

[Kashyap Chamarthy <kchamart@redhat.com>]

On Thu, Feb 17, 2022 at 08:57:19AM +0100, Thomas Huth wrote:
> On 16/02/2022 18.40, Dr. David Alan Gilbert wrote:

[...]

> > So just adding something like the following under 'System emulator
> > machines':
> > 
> > x86 default machine type
> > ------------------------
> > 
> > x86 currently defaults to the very old ```pc``` machine type
> 
> I'd scrath the "very old" above since you repeat it below...
> 
> > which is based on the very old ```i440f``` chipset.  This default
> > will be removed and the user will be required to specify a machine
> > type explicitly using -M; users are encouraged to switch to the
> > not quite as old ```q35``` machine types.
> 
> ... but otherwise this sounds good to me.

Yeah, _not_ picking a default sounds good to me.  As there might come a
better machine type for x86 too, just like how "virt" machine type was
expressly designed for AArch64 guests.
 
> > (This option is going to take a lot more work switching all the
> > test cases over; in my world here I'd only changed the tests that broke
> > on q35, now everything is going to need to specify a type).
> 
> We've got a bunch of targets now already that do not have a default machine
> type yet (aarch64/arm, avr, rx, tricore), and some where the default machine
> type does not make too much sense for testing anyway (e.g. m68k) ... so it
> would maybe be good to have a global qtest_get_default_machine() function in
> the qtest framework anyway instead of re-encoding this in each and every
> test case.
> 
> Anyway, if we agree that the default machine type of x86 should go through
> the deprecation process, we've got plenty of time to fix this up in the
> tests, no need to rush this now before 7.0.
> 
> Other heretic question: Should we maybe get rid of the default machine type
> for *all* targets? ... so that we do not continue to run into this issue
> again and again and again...

Not at all heretic :-) I think the same reasoning above works here too.
FWIW, I agree to make the behaviour consistent across all targets.

[...] 

-- 
/kashyap