changes from v2, all proposed by Greg:
* Handle 'NULL' value as default mode fallback in spapr_kvm_type()
* Do not allow for 'AUTO' to be a valid mode in spapr_kvm_type()
* Initialize 'spapr->kvm_type' in spapr_instance_init() like Paolo
  proposed. This will spare us from changing spapr_get_kvm_type()
  altogether.
v2 link: https://lists.gnu.org/archive/html/qemu-devel/2020-12/msg02623.html


This patch addresses an issue that happens with the pseries machine after
testing Paolo's patch [1]:

$ sudo ./ppc64-softmmu/qemu-system-ppc64 -nographic -nodefaults -machine pseries --enable-kvm
qemu-system-ppc64: Unknown kvm-type specified '' 

The reason lies on how qemu_opt_get() and object_property_get_str() works
when there is no 'kvm-type' specified. We were conting on receiving NULL
for kvm-type, but the latter will use a blank string "". Instead on relying
on NULL, let's expose the already existing 'auto' kvm-type mode to the users
and use that as default.

[1] https://lists.gnu.org/archive/html/qemu-devel/2020-12/msg00471.html

Daniel Henrique Barboza (1):
  spapr.c: set a 'kvm-type' default value instead of relying on NULL

 hw/ppc/spapr.c | 21 +++++++++++++++++----
 1 file changed, 17 insertions(+), 4 deletions(-)

-- 
2.26.2

On 10/12/20 15:55, Daniel Henrique Barboza wrote:
> changes from v2, all proposed by Greg:
> * Handle 'NULL' value as default mode fallback in spapr_kvm_type()
> * Do not allow for 'AUTO' to be a valid mode in spapr_kvm_type()
> * Initialize 'spapr->kvm_type' in spapr_instance_init() like Paolo
>    proposed. This will spare us from changing spapr_get_kvm_type()
>    altogether.
> v2 link: https://lists.gnu.org/archive/html/qemu-devel/2020-12/msg02623.html
> 
> 
> This patch addresses an issue that happens with the pseries machine after
> testing Paolo's patch [1]:
> 
> $ sudo ./ppc64-softmmu/qemu-system-ppc64 -nographic -nodefaults -machine pseries --enable-kvm
> qemu-system-ppc64: Unknown kvm-type specified ''
> 
> The reason lies on how qemu_opt_get() and object_property_get_str() works
> when there is no 'kvm-type' specified. We were conting on receiving NULL
> for kvm-type, but the latter will use a blank string "". Instead on relying
> on NULL, let's expose the already existing 'auto' kvm-type mode to the users
> and use that as default.
> 
> [1] https://lists.gnu.org/archive/html/qemu-devel/2020-12/msg00471.html
> 
> Daniel Henrique Barboza (1):
>    spapr.c: set a 'kvm-type' default value instead of relying on NULL
> 
>   hw/ppc/spapr.c | 21 +++++++++++++++++----
>   1 file changed, 17 insertions(+), 4 deletions(-)
> 

Will queue, thanks!

Paolo

On Thu, Dec 10, 2020 at 05:51:41PM +0100, Paolo Bonzini wrote:
> On 10/12/20 15:55, Daniel Henrique Barboza wrote:
> > changes from v2, all proposed by Greg:
> > * Handle 'NULL' value as default mode fallback in spapr_kvm_type()
> > * Do not allow for 'AUTO' to be a valid mode in spapr_kvm_type()
> > * Initialize 'spapr->kvm_type' in spapr_instance_init() like Paolo
> >    proposed. This will spare us from changing spapr_get_kvm_type()
> >    altogether.
> > v2 link: https://lists.gnu.org/archive/html/qemu-devel/2020-12/msg02623.html
> > 
> > 
> > This patch addresses an issue that happens with the pseries machine after
> > testing Paolo's patch [1]:
> > 
> > $ sudo ./ppc64-softmmu/qemu-system-ppc64 -nographic -nodefaults -machine pseries --enable-kvm
> > qemu-system-ppc64: Unknown kvm-type specified ''
> > 
> > The reason lies on how qemu_opt_get() and object_property_get_str() works
> > when there is no 'kvm-type' specified. We were conting on receiving NULL
> > for kvm-type, but the latter will use a blank string "". Instead on relying
> > on NULL, let's expose the already existing 'auto' kvm-type mode to the users
> > and use that as default.
> > 
> > [1] https://lists.gnu.org/archive/html/qemu-devel/2020-12/msg00471.html
> > 
> > Daniel Henrique Barboza (1):
> >    spapr.c: set a 'kvm-type' default value instead of relying on NULL
> > 
> >   hw/ppc/spapr.c | 21 +++++++++++++++++----
> >   1 file changed, 17 insertions(+), 4 deletions(-)
> > 
> 
> Will queue, thanks!

I've also put it into my ppc-for-6.0 tree, which I plan to send a PR
for shortly.  I guess it should be an easy conflict to resolve, so I
don't think that will be a problem.

-- 
David Gibson			| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au	| minimalist, thank you.  NOT _the_ _other_
				| _way_ _around_!
http://www.ozlabs.org/~dgibson

On 11/12/20 01:21, David Gibson wrote:
> On Thu, Dec 10, 2020 at 05:51:41PM +0100, Paolo Bonzini wrote:
>> On 10/12/20 15:55, Daniel Henrique Barboza wrote:
>>> changes from v2, all proposed by Greg:
>>> * Handle 'NULL' value as default mode fallback in spapr_kvm_type()
>>> * Do not allow for 'AUTO' to be a valid mode in spapr_kvm_type()
>>> * Initialize 'spapr->kvm_type' in spapr_instance_init() like Paolo
>>>     proposed. This will spare us from changing spapr_get_kvm_type()
>>>     altogether.
>>> v2 link: https://lists.gnu.org/archive/html/qemu-devel/2020-12/msg02623.html
>>>
>>>
>>> This patch addresses an issue that happens with the pseries machine after
>>> testing Paolo's patch [1]:
>>>
>>> $ sudo ./ppc64-softmmu/qemu-system-ppc64 -nographic -nodefaults -machine pseries --enable-kvm
>>> qemu-system-ppc64: Unknown kvm-type specified ''
>>>
>>> The reason lies on how qemu_opt_get() and object_property_get_str() works
>>> when there is no 'kvm-type' specified. We were conting on receiving NULL
>>> for kvm-type, but the latter will use a blank string "". Instead on relying
>>> on NULL, let's expose the already existing 'auto' kvm-type mode to the users
>>> and use that as default.
>>>
>>> [1] https://lists.gnu.org/archive/html/qemu-devel/2020-12/msg00471.html
>>>
>>> Daniel Henrique Barboza (1):
>>>     spapr.c: set a 'kvm-type' default value instead of relying on NULL
>>>
>>>    hw/ppc/spapr.c | 21 +++++++++++++++++----
>>>    1 file changed, 17 insertions(+), 4 deletions(-)
>>>
>>
>> Will queue, thanks!
> 
> I've also put it into my ppc-for-6.0 tree, which I plan to send a PR
> for shortly.  I guess it should be an easy conflict to resolve, so I
> don't think that will be a problem.

Yup, my own queue is still a week away, so go ahead.  Thanks!

Paolo