qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH v2 4/7] scripts/qemu.py: set predefined machine


From: Cleber Rosa
Subject: Re: [Qemu-devel] [PATCH v2 4/7] scripts/qemu.py: set predefined machine type based on arch
Date: Wed, 10 Oct 2018 12:02:30 -0400
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.0


On 10/10/18 11:31 AM, Daniel P. Berrangé wrote:
> On Wed, Oct 10, 2018 at 11:28:40AM -0300, Eduardo Habkost wrote:
>> On Wed, Oct 10, 2018 at 10:15:15AM -0400, Cleber Rosa wrote:
>>>
>>>
>>> On 10/10/18 9:59 AM, Cleber Rosa wrote:
>>>>
>>>>
>>>> On 10/10/18 9:46 AM, Eduardo Habkost wrote:
>>>>> On Wed, Oct 10, 2018 at 08:35:38AM -0400, Cleber Rosa wrote:
>>>>>>
>>>>>>
>>>>>> On 10/10/18 7:00 AM, Philippe Mathieu-Daudé wrote:
>>>>>>> On 10/10/2018 01:26, Cleber Rosa wrote:
>>>>>>>> Some targets require a machine type to be set, as there's no default
>>>>>>>> (aarch64 is one example).  To give a consistent interface to users of
>>>>>>>> this API, this changes set_machine() so that a predefined default can
>>>>>>>> be used, if one is not given.  The approach used is exactly the same
>>>>>>>> with the console device type.
>>>>>>>>
>>>>>>>> Also, even when there's a default machine type, for some purposes,
>>>>>>>> testing included, it's better if outside code is explicit about the
>>>>>>>> machine type, instead of relying on whatever is set internally.
>>>>>>>>
>>>>>>>> Signed-off-by: Cleber Rosa <address@hidden>
>>>>>>>> ---
>>>>>>>>  scripts/qemu.py | 22 +++++++++++++++++++++-
>>>>>>>>  1 file changed, 21 insertions(+), 1 deletion(-)
>>>>>>>>
>>>>>>>> diff --git a/scripts/qemu.py b/scripts/qemu.py
>>>>>>>> index d9e24a0c1a..fca9b76990 100644
>>>>>>>> --- a/scripts/qemu.py
>>>>>>>> +++ b/scripts/qemu.py
>>>>>>>> @@ -36,6 +36,15 @@ CONSOLE_DEV_TYPES = {
>>>>>>>>      r'^s390-ccw-virtio.*': 'sclpconsole',
>>>>>>>>      }
>>>>>>>>  
>>>>>>>> +#: Maps archictures to the preferred machine type
>>>>>>>> +MACHINE_TYPES = {
>>>>>>>> +    r'^aarch64$': 'virt',
>>>>>>>> +    r'^ppc$': 'g3beige',
>>>>>>>> +    r'^ppc64$': 'pseries',
>>>>>>>> +    r'^s390x$': 's390-ccw-virtio',
>>>>>>>> +    r'^x86_64$': 'q35',
>>>>>>>
>>>>>>> Why choose Q35 rather than PC (the default)?
>>>>>>>
>>>>>>> I was wondering about how to generate variants/machines.json but this is
>>>>>>> definitively something we want to do via a QMP query.
>>>>>>>
>>>>>>> Eduardo what do you think?
>>>>>>>
>>>>>>
>>>>>> It was motivated by Eduardo's initiative to make q35 the default "across
>>>>>> the board".  He can confirm and give more details.
>>>>>
>>>>> Making Q35 the default on applications using QEMU and libvirt is
>>>>> something I'd like to happen.  But I think the simplest way to do
>>>>> that is to change the QEMU default.  This way you won't need this
>>>>> table on qemu.py: you can just use the default provided by QEMU.
>>>>>
>>>>
>>>> The idea is to bring consistency on how we're calling
>>>> "qemu-system-$(ARCH)", and at the same time apply the "explicit is
>>>> better than implicit" rule.
>>>>
>>>> The most important fact is that some targets do not (currently) have
>>>> "the default provided by QEMU", aarch64 is one of them.
>>>>
>>>> - Cleber.
>>>>
>>>
>>> So I ended up not relaying the question properly: should we default
>>> (even if explicitly adding "-machine") to "pc"?
>>
>> I think using the default machine-type (when QEMU has a default)
>> would be less surprising for users of the qemu.py API.
>>
>> Implicitly adding -machine when there's no default is also
>> surprising, but then it's a nice surprise: instead of crashing
>> you get a running VM.
>>
>> Now, there are two other questions related to this:
>>
>> If using 'pc' as default, should we always add -machine, or just
>> omit the machine-type name?  I think we should omit it unless the
>> caller asked for a specific machine-type name (because it would
>> be less surprising for users of the API).
>>
>> About our default testing configuration for acceptance tests:
>> should acceptance tests run against PC by default?  Should it
>> test Q35?  Should we test both PC and Q35?  I'm not sure what's
>> the answer, but I think these decisions shouldn't affect the
>> qemu.py API at all.
> 
> As a general goal we should be aiming to test everything we provide
> to users if, we expect them to actually use it and not have it
> break later :-)
> 
> Given that 'pc' has been the default for entire existance of QEMU,
> 99% of guests are using 'pc' and thus we definitely want to be
> testing it.
> 
> Equally we'd like to encourage use of 'q35' so we should also be
> testing that, even though it has very little usage right now.
> 
> Thus, we really need to be running any tests against both machine
> types.  If we do that, then the question of default doesn't really
> matter as one of them is always not the default and needs testing
> regardless.
> 
> Regards,
> Daniel
> 

Hi Daniel,

I think we're in sync.  Please look at my previous reply (and accept my
apologies if this is not a better "netiquette" than replying the same
thing again).

Regards!
- Cleber.



reply via email to

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