| Message ID | 20201210145517.1532269-1-danielhb413@gmail.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | spapr.c: set a 'kvm-type' default value instead of relying on NULL | expand |
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.
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