Re: [PATCH v2 1/1] spapr.c: set a 'kvm-type' default value instead of relying on NULL

2020-12-10 Thread Daniel Henrique Barboza
On 12/10/20 11:14 AM, Greg Kurz wrote: On Thu, 10 Dec 2020 15:01:20 +0100 Greg Kurz wrote: On Thu, 10 Dec 2020 10:07:21 -0300 Daniel Henrique Barboza wrote: spapr_kvm_type() is considering 'vm_type=NULL' as a valid input, where the function returns 0. This is relying on the current QEMU

Re: [PATCH v2 1/1] spapr.c: set a 'kvm-type' default value instead of relying on NULL

2020-12-10 Thread Greg Kurz
On Thu, 10 Dec 2020 15:01:20 +0100 Greg Kurz wrote: > On Thu, 10 Dec 2020 10:07:21 -0300 > Daniel Henrique Barboza wrote: > > > spapr_kvm_type() is considering 'vm_type=NULL' as a valid input, where > > the function returns 0. This is relying on the current QEMU machine > > options handling

Re: [PATCH v2 1/1] spapr.c: set a 'kvm-type' default value instead of relying on NULL

2020-12-10 Thread Greg Kurz
On Thu, 10 Dec 2020 10:07:21 -0300 Daniel Henrique Barboza wrote: > spapr_kvm_type() is considering 'vm_type=NULL' as a valid input, where > the function returns 0. This is relying on the current QEMU machine > options handling logic, where the absence of the 'kvm-type' option > will be

[PATCH v2 1/1] spapr.c: set a 'kvm-type' default value instead of relying on NULL

2020-12-10 Thread Daniel Henrique Barboza
spapr_kvm_type() is considering 'vm_type=NULL' as a valid input, where the function returns 0. This is relying on the current QEMU machine options handling logic, where the absence of the 'kvm-type' option will be reflected as 'vm_type=NULL' in this function. This is not robust, and will break if