Patchwork [2/6] Use machine options to emulate -no-kvm-irqchip

login
register
mail settings
Submitter Marcelo Tosatti
Date Oct. 3, 2012, 10:52 a.m.
Message ID <20121003105509.391284251@amt.cnet>
Download mbox | patch
Permalink /patch/188747/
State New
Headers show

Comments

Marcelo Tosatti - Oct. 3, 2012, 10:52 a.m.
Commit 3ad763fcba5bd0ec5a79d4a9b6baeef119dd4a3d from qemu-kvm.git.

From: Jan Kiszka <jan.kiszka@siemens.com>
    
Upstream is moving towards this mechanism, so start using it in qemu-kvm
already to configure the specific defaults: kvm enabled on, just like
in-kernel irqchips.

Signed-off-by: Marcelo Tosatti <mtosatti@redhat.com>
Anthony Liguori - Oct. 3, 2012, 2:40 p.m.
Marcelo Tosatti <mtosatti@redhat.com> writes:

> Commit 3ad763fcba5bd0ec5a79d4a9b6baeef119dd4a3d from qemu-kvm.git.
>
> From: Jan Kiszka <jan.kiszka@siemens.com>
>     
> Upstream is moving towards this mechanism, so start using it in qemu-kvm
> already to configure the specific defaults: kvm enabled on, just like
> in-kernel irqchips.
>
> Signed-off-by: Marcelo Tosatti <mtosatti@redhat.com>


Reviewed-by: Anthony Liguori <aliguori@us.ibm.com>

Although it's a little odd to have From: Jan without a SoB...

Regards,

Anthony Liguori


>
> Index: qemu-compat-kvm/vl.c
> ===================================================================
> --- qemu-compat-kvm.orig/vl.c
> +++ qemu-compat-kvm/vl.c
> @@ -3061,6 +3061,12 @@ int main(int argc, char **argv, char **e
>                      machine = machine_parse(optarg);
>                  }
>                  break;
> +            case QEMU_OPTION_no_kvm_irqchip: {
> +                olist = qemu_find_opts("machine");
> +                qemu_opts_parse(olist, "kernel_irqchip=off", 0);
> +                break;
> +            }
> +
>              case QEMU_OPTION_usb:
>                  usb_enabled = 1;
>                  break;
> Index: qemu-compat-kvm/qemu-options.hx
> ===================================================================
> --- qemu-compat-kvm.orig/qemu-options.hx
> +++ qemu-compat-kvm/qemu-options.hx
> @@ -2838,6 +2838,10 @@ STEXI
>  Enable FIPS 140-2 compliance mode.
>  ETEXI
>  
> +DEF("no-kvm-irqchip", 0, QEMU_OPTION_no_kvm_irqchip,
> +    "-no-kvm-irqchip disable KVM kernel mode PIC/IOAPIC/LAPIC\n",
> +    QEMU_ARCH_I386)
> +
>  HXCOMM This is the last statement. Insert new options before this line!
>  STEXI
>  @end table
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe kvm" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
Marcelo Tosatti - Oct. 3, 2012, 3:03 p.m.
On Wed, Oct 03, 2012 at 09:40:17AM -0500, Anthony Liguori wrote:
> Marcelo Tosatti <mtosatti@redhat.com> writes:
> 
> > Commit 3ad763fcba5bd0ec5a79d4a9b6baeef119dd4a3d from qemu-kvm.git.
> >
> > From: Jan Kiszka <jan.kiszka@siemens.com>
> >     
> > Upstream is moving towards this mechanism, so start using it in qemu-kvm
> > already to configure the specific defaults: kvm enabled on, just like
> > in-kernel irqchips.
> >
> > Signed-off-by: Marcelo Tosatti <mtosatti@redhat.com>
> 
> 
> Reviewed-by: Anthony Liguori <aliguori@us.ibm.com>
> 
> Although it's a little odd to have From: Jan without a SoB...

Agree, Jan can you ACK?
Jan Kiszka - Oct. 3, 2012, 3:46 p.m.
On 2012-10-03 17:03, Marcelo Tosatti wrote:
> On Wed, Oct 03, 2012 at 09:40:17AM -0500, Anthony Liguori wrote:
>> Marcelo Tosatti <mtosatti@redhat.com> writes:
>>
>>> Commit 3ad763fcba5bd0ec5a79d4a9b6baeef119dd4a3d from qemu-kvm.git.
>>>
>>> From: Jan Kiszka <jan.kiszka@siemens.com>
>>>     
>>> Upstream is moving towards this mechanism, so start using it in qemu-kvm
>>> already to configure the specific defaults: kvm enabled on, just like
>>> in-kernel irqchips.
>>>
>>> Signed-off-by: Marcelo Tosatti <mtosatti@redhat.com>
>>
>>
>> Reviewed-by: Anthony Liguori <aliguori@us.ibm.com>
>>
>> Although it's a little odd to have From: Jan without a SoB...
> 
> Agree, Jan can you ACK?

I wasn't able to join the call yesterday: Is there a removal schedule
associated with those switches? Also, why pushing things upstream, even
when only for one release, that have been loudly deprecated for a while
in qemu-kvm? Some switches are lacking deprecated warnings on the
console, and -no-kvm is missing completely. I tend to focus on patch 1 &
5, dropping the rest - based on relevance for production use.

Jan
Jan Kiszka - Oct. 3, 2012, 3:49 p.m.
On 2012-10-03 17:46, Jan Kiszka wrote:
> On 2012-10-03 17:03, Marcelo Tosatti wrote:
>> On Wed, Oct 03, 2012 at 09:40:17AM -0500, Anthony Liguori wrote:
>>> Marcelo Tosatti <mtosatti@redhat.com> writes:
>>>
>>>> Commit 3ad763fcba5bd0ec5a79d4a9b6baeef119dd4a3d from qemu-kvm.git.
>>>>
>>>> From: Jan Kiszka <jan.kiszka@siemens.com>
>>>>     
>>>> Upstream is moving towards this mechanism, so start using it in qemu-kvm
>>>> already to configure the specific defaults: kvm enabled on, just like
>>>> in-kernel irqchips.
>>>>
>>>> Signed-off-by: Marcelo Tosatti <mtosatti@redhat.com>
>>>
>>>
>>> Reviewed-by: Anthony Liguori <aliguori@us.ibm.com>
>>>
>>> Although it's a little odd to have From: Jan without a SoB...
>>
>> Agree, Jan can you ACK?
> 
> I wasn't able to join the call yesterday: Is there a removal schedule
> associated with those switches? Also, why pushing things upstream, even
> when only for one release, that have been loudly deprecated for a while
> in qemu-kvm? Some switches are lacking deprecated warnings on the
> console, and -no-kvm is missing completely. I tend to focus on patch 1 &
> 5, dropping the rest - based on relevance for production use.

I guess patch 4 is fine as well, so consider 4 & 5 ack'ed.

Jan
Anthony Liguori - Oct. 3, 2012, 5:16 p.m.
Jan Kiszka <jan.kiszka@web.de> writes:

> On 2012-10-03 17:03, Marcelo Tosatti wrote:
>> On Wed, Oct 03, 2012 at 09:40:17AM -0500, Anthony Liguori wrote:
>>> Marcelo Tosatti <mtosatti@redhat.com> writes:
>>>
>>>> Commit 3ad763fcba5bd0ec5a79d4a9b6baeef119dd4a3d from qemu-kvm.git.
>>>>
>>>> From: Jan Kiszka <jan.kiszka@siemens.com>
>>>>     
>>>> Upstream is moving towards this mechanism, so start using it in qemu-kvm
>>>> already to configure the specific defaults: kvm enabled on, just like
>>>> in-kernel irqchips.
>>>>
>>>> Signed-off-by: Marcelo Tosatti <mtosatti@redhat.com>
>>>
>>>
>>> Reviewed-by: Anthony Liguori <aliguori@us.ibm.com>
>>>
>>> Although it's a little odd to have From: Jan without a SoB...
>> 
>> Agree, Jan can you ACK?
>
> I wasn't able to join the call yesterday: Is there a removal schedule
> associated with those switches? Also, why pushing things upstream, even
> when only for one release, that have been loudly deprecated for a while
> in qemu-kvm? Some switches are lacking deprecated warnings on the
> console, and -no-kvm is missing completely. I tend to focus on patch 1 &
> 5, dropping the rest - based on relevance for production use.

The distros need to keep these flags to do the switch.  I see no point
in deprecating them since they're trivially easy to maintain.

So we'd just support them forever.

Regards,

Anthony Liguori

>
> Jan
Jan Kiszka - Oct. 3, 2012, 5:24 p.m.
On 2012-10-03 19:16, Anthony Liguori wrote:
> Jan Kiszka <jan.kiszka@web.de> writes:
> 
>> On 2012-10-03 17:03, Marcelo Tosatti wrote:
>>> On Wed, Oct 03, 2012 at 09:40:17AM -0500, Anthony Liguori wrote:
>>>> Marcelo Tosatti <mtosatti@redhat.com> writes:
>>>>
>>>>> Commit 3ad763fcba5bd0ec5a79d4a9b6baeef119dd4a3d from qemu-kvm.git.
>>>>>
>>>>> From: Jan Kiszka <jan.kiszka@siemens.com>
>>>>>     
>>>>> Upstream is moving towards this mechanism, so start using it in qemu-kvm
>>>>> already to configure the specific defaults: kvm enabled on, just like
>>>>> in-kernel irqchips.
>>>>>
>>>>> Signed-off-by: Marcelo Tosatti <mtosatti@redhat.com>
>>>>
>>>>
>>>> Reviewed-by: Anthony Liguori <aliguori@us.ibm.com>
>>>>
>>>> Although it's a little odd to have From: Jan without a SoB...
>>>
>>> Agree, Jan can you ACK?
>>
>> I wasn't able to join the call yesterday: Is there a removal schedule
>> associated with those switches? Also, why pushing things upstream, even
>> when only for one release, that have been loudly deprecated for a while
>> in qemu-kvm? Some switches are lacking deprecated warnings on the
>> console, and -no-kvm is missing completely. I tend to focus on patch 1 &
>> 5, dropping the rest - based on relevance for production use.
> 
> The distros need to keep these flags to do the switch.

Why? Should be documented in commit log.

>  I see no point
> in deprecating them since they're trivially easy to maintain.

Given the level of cr** we already have in the command line, they are
kind of noise, yes. But even then, these patches are not consistent as
pointed out above.

Also, they should not be documented to avoid being spread. That's what
we did with other deprecated switches in QEMU.

Jan
Anthony Liguori - Oct. 3, 2012, 6:14 p.m.
Jan Kiszka <jan.kiszka@web.de> writes:

> On 2012-10-03 19:16, Anthony Liguori wrote:
>> Jan Kiszka <jan.kiszka@web.de> writes:
>> 
>>> On 2012-10-03 17:03, Marcelo Tosatti wrote:
>>>> On Wed, Oct 03, 2012 at 09:40:17AM -0500, Anthony Liguori wrote:
>>>>> Marcelo Tosatti <mtosatti@redhat.com> writes:
>>>>>
>>>>>> Commit 3ad763fcba5bd0ec5a79d4a9b6baeef119dd4a3d from qemu-kvm.git.
>>>>>>
>>>>>> From: Jan Kiszka <jan.kiszka@siemens.com>
>>>>>>     
>>>>>> Upstream is moving towards this mechanism, so start using it in qemu-kvm
>>>>>> already to configure the specific defaults: kvm enabled on, just like
>>>>>> in-kernel irqchips.
>>>>>>
>>>>>> Signed-off-by: Marcelo Tosatti <mtosatti@redhat.com>
>>>>>
>>>>>
>>>>> Reviewed-by: Anthony Liguori <aliguori@us.ibm.com>
>>>>>
>>>>> Although it's a little odd to have From: Jan without a SoB...
>>>>
>>>> Agree, Jan can you ACK?
>>>
>>> I wasn't able to join the call yesterday: Is there a removal schedule
>>> associated with those switches? Also, why pushing things upstream, even
>>> when only for one release, that have been loudly deprecated for a while
>>> in qemu-kvm? Some switches are lacking deprecated warnings on the
>>> console, and -no-kvm is missing completely. I tend to focus on patch 1 &
>>> 5, dropping the rest - based on relevance for production use.
>> 
>> The distros need to keep these flags to do the switch.
>
> Why? Should be documented in commit log.
>
>>  I see no point
>> in deprecating them since they're trivially easy to maintain.
>
> Given the level of cr** we already have in the command line, they are
> kind of noise, yes. But even then, these patches are not consistent as
> pointed out above.
>
> Also, they should not be documented to avoid being spread. That's what
> we did with other deprecated switches in QEMU.

The patchset isn't checkpatch clean so I'll fix that, remove the docs,
and send a new version tomorrow along with the machine changes.

Regards,

Anthony Liguori

>
> Jan
Marcelo Tosatti - Oct. 3, 2012, 6:26 p.m.
On Wed, Oct 03, 2012 at 07:24:48PM +0200, Jan Kiszka wrote:
> On 2012-10-03 19:16, Anthony Liguori wrote:
> > Jan Kiszka <jan.kiszka@web.de> writes:
> > 
> >> On 2012-10-03 17:03, Marcelo Tosatti wrote:
> >>> On Wed, Oct 03, 2012 at 09:40:17AM -0500, Anthony Liguori wrote:
> >>>> Marcelo Tosatti <mtosatti@redhat.com> writes:
> >>>>
> >>>>> Commit 3ad763fcba5bd0ec5a79d4a9b6baeef119dd4a3d from qemu-kvm.git.
> >>>>>
> >>>>> From: Jan Kiszka <jan.kiszka@siemens.com>
> >>>>>     
> >>>>> Upstream is moving towards this mechanism, so start using it in qemu-kvm
> >>>>> already to configure the specific defaults: kvm enabled on, just like
> >>>>> in-kernel irqchips.
> >>>>>
> >>>>> Signed-off-by: Marcelo Tosatti <mtosatti@redhat.com>
> >>>>
> >>>>
> >>>> Reviewed-by: Anthony Liguori <aliguori@us.ibm.com>
> >>>>
> >>>> Although it's a little odd to have From: Jan without a SoB...
> >>>
> >>> Agree, Jan can you ACK?
> >>
> >> I wasn't able to join the call yesterday: Is there a removal schedule
> >> associated with those switches? Also, why pushing things upstream, even
> >> when only for one release, that have been loudly deprecated for a while
> >> in qemu-kvm? Some switches are lacking deprecated warnings on the
> >> console, and -no-kvm is missing completely. I tend to focus on patch 1 &
> >> 5, dropping the rest - based on relevance for production use.
> > 
> > The distros need to keep these flags to do the switch.
> 
> Why? Should be documented in commit log.
> 
> >  I see no point
> > in deprecating them since they're trivially easy to maintain.
> 
> Given the level of cr** we already have in the command line, they are
> kind of noise, yes. But even then, these patches are not consistent as
> pointed out above.
> 
> Also, they should not be documented to avoid being spread. That's what
> we did with other deprecated switches in QEMU.
> 
> Jan

Jan,

You're comments to the patch are:

- No documentation.
- Expiration date.
- Changelog explaining what?? (didnt get that). Perhaps better changelog
  in general?

Please help me understand.
Aurelien Jarno - Oct. 3, 2012, 6:54 p.m.
On Wed, Oct 03, 2012 at 07:52:57AM -0300, Marcelo Tosatti wrote:
> Commit 3ad763fcba5bd0ec5a79d4a9b6baeef119dd4a3d from qemu-kvm.git.
> 
> From: Jan Kiszka <jan.kiszka@siemens.com>
>     
> Upstream is moving towards this mechanism, so start using it in qemu-kvm
> already to configure the specific defaults: kvm enabled on, just like
> in-kernel irqchips.
> 
> Signed-off-by: Marcelo Tosatti <mtosatti@redhat.com>
> 
> Index: qemu-compat-kvm/vl.c
> ===================================================================
> --- qemu-compat-kvm.orig/vl.c
> +++ qemu-compat-kvm/vl.c
> @@ -3061,6 +3061,12 @@ int main(int argc, char **argv, char **e
>                      machine = machine_parse(optarg);
>                  }
>                  break;
> +            case QEMU_OPTION_no_kvm_irqchip: {
> +                olist = qemu_find_opts("machine");
> +                qemu_opts_parse(olist, "kernel_irqchip=off", 0);
> +                break;
> +            }
> +
>              case QEMU_OPTION_usb:
>                  usb_enabled = 1;
>                  break;
> Index: qemu-compat-kvm/qemu-options.hx
> ===================================================================
> --- qemu-compat-kvm.orig/qemu-options.hx
> +++ qemu-compat-kvm/qemu-options.hx
> @@ -2838,6 +2838,10 @@ STEXI
>  Enable FIPS 140-2 compliance mode.
>  ETEXI
>  
> +DEF("no-kvm-irqchip", 0, QEMU_OPTION_no_kvm_irqchip,
> +    "-no-kvm-irqchip disable KVM kernel mode PIC/IOAPIC/LAPIC\n",
> +    QEMU_ARCH_I386)
> +
>  HXCOMM This is the last statement. Insert new options before this line!
>  STEXI
>  @end table
> 

As far as I understand, this option was not in QEMU, because this syntax
is considered as deprecated. Can we also add an output a warning message
in that case?
Jan Kiszka - Oct. 4, 2012, 9:28 a.m.
On 2012-10-03 20:26, Marcelo Tosatti wrote:
> On Wed, Oct 03, 2012 at 07:24:48PM +0200, Jan Kiszka wrote:
>> On 2012-10-03 19:16, Anthony Liguori wrote:
>>> Jan Kiszka <jan.kiszka@web.de> writes:
>>>
>>>> On 2012-10-03 17:03, Marcelo Tosatti wrote:
>>>>> On Wed, Oct 03, 2012 at 09:40:17AM -0500, Anthony Liguori wrote:
>>>>>> Marcelo Tosatti <mtosatti@redhat.com> writes:
>>>>>>
>>>>>>> Commit 3ad763fcba5bd0ec5a79d4a9b6baeef119dd4a3d from qemu-kvm.git.
>>>>>>>
>>>>>>> From: Jan Kiszka <jan.kiszka@siemens.com>
>>>>>>>     
>>>>>>> Upstream is moving towards this mechanism, so start using it in qemu-kvm
>>>>>>> already to configure the specific defaults: kvm enabled on, just like
>>>>>>> in-kernel irqchips.
>>>>>>>
>>>>>>> Signed-off-by: Marcelo Tosatti <mtosatti@redhat.com>
>>>>>>
>>>>>>
>>>>>> Reviewed-by: Anthony Liguori <aliguori@us.ibm.com>
>>>>>>
>>>>>> Although it's a little odd to have From: Jan without a SoB...
>>>>>
>>>>> Agree, Jan can you ACK?
>>>>
>>>> I wasn't able to join the call yesterday: Is there a removal schedule
>>>> associated with those switches? Also, why pushing things upstream, even
>>>> when only for one release, that have been loudly deprecated for a while
>>>> in qemu-kvm? Some switches are lacking deprecated warnings on the
>>>> console, and -no-kvm is missing completely. I tend to focus on patch 1 &
>>>> 5, dropping the rest - based on relevance for production use.
>>>
>>> The distros need to keep these flags to do the switch.
>>
>> Why? Should be documented in commit log.
>>
>>>  I see no point
>>> in deprecating them since they're trivially easy to maintain.
>>
>> Given the level of cr** we already have in the command line, they are
>> kind of noise, yes. But even then, these patches are not consistent as
>> pointed out above.
>>
>> Also, they should not be documented to avoid being spread. That's what
>> we did with other deprecated switches in QEMU.
>>
>> Jan
> 
> Jan,
> 
> You're comments to the patch are:
> 
> - No documentation.

See e.g. how -M is handled in qemu-options.hx.

> - Expiration date.

Anthony said "forever", but I think we should remove all those that
issue deprecation warnings after 1-2 years.

> - Changelog explaining what?? (didnt get that). Perhaps better changelog
>   in general?

I'm still failing to understand who could depend on -no-kvm-irqchip or
-no-kvm-pit. And I don't understand why -no-kvm was not included. Soe
the reasons for include -X should be provided. Also check your patch
subjects again, at least one was wrong.

Jan
Anthony Liguori - Oct. 4, 2012, 2:21 p.m.
Jan Kiszka <jan.kiszka@web.de> writes:

> On 2012-10-03 20:26, Marcelo Tosatti wrote:
>> On Wed, Oct 03, 2012 at 07:24:48PM +0200, Jan Kiszka wrote:
>>> On 2012-10-03 19:16, Anthony Liguori wrote:
>>>> Jan Kiszka <jan.kiszka@web.de> writes:
>>>>
>>>>> On 2012-10-03 17:03, Marcelo Tosatti wrote:
>>>>>> On Wed, Oct 03, 2012 at 09:40:17AM -0500, Anthony Liguori wrote:
>>>>>>> Marcelo Tosatti <mtosatti@redhat.com> writes:
>>>>>>>
>>>>>>>> Commit 3ad763fcba5bd0ec5a79d4a9b6baeef119dd4a3d from qemu-kvm.git.
>>>>>>>>
>>>>>>>> From: Jan Kiszka <jan.kiszka@siemens.com>
>>>>>>>>     
>>>>>>>> Upstream is moving towards this mechanism, so start using it in qemu-kvm
>>>>>>>> already to configure the specific defaults: kvm enabled on, just like
>>>>>>>> in-kernel irqchips.
>>>>>>>>
>>>>>>>> Signed-off-by: Marcelo Tosatti <mtosatti@redhat.com>
>>>>>>>
>>>>>>>
>>>>>>> Reviewed-by: Anthony Liguori <aliguori@us.ibm.com>
>>>>>>>
>>>>>>> Although it's a little odd to have From: Jan without a SoB...
>>>>>>
>>>>>> Agree, Jan can you ACK?
>>>>>
>>>>> I wasn't able to join the call yesterday: Is there a removal schedule
>>>>> associated with those switches? Also, why pushing things upstream, even
>>>>> when only for one release, that have been loudly deprecated for a while
>>>>> in qemu-kvm? Some switches are lacking deprecated warnings on the
>>>>> console, and -no-kvm is missing completely. I tend to focus on patch 1 &
>>>>> 5, dropping the rest - based on relevance for production use.
>>>>
>>>> The distros need to keep these flags to do the switch.
>>>
>>> Why? Should be documented in commit log.
>>>
>>>>  I see no point
>>>> in deprecating them since they're trivially easy to maintain.
>>>
>>> Given the level of cr** we already have in the command line, they are
>>> kind of noise, yes. But even then, these patches are not consistent as
>>> pointed out above.
>>>
>>> Also, they should not be documented to avoid being spread. That's what
>>> we did with other deprecated switches in QEMU.
>>>
>>> Jan
>> 
>> Jan,
>> 
>> You're comments to the patch are:
>> 
>> - No documentation.
>
> See e.g. how -M is handled in qemu-options.hx.
>
>> - Expiration date.
>
> Anthony said "forever", but I think we should remove all those that
> issue deprecation warnings after 1-2 years.
>
>> - Changelog explaining what?? (didnt get that). Perhaps better changelog
>>   in general?
>
> I'm still failing to understand who could depend on -no-kvm-irqchip or
> -no-kvm-pit. And I don't understand why -no-kvm was not included. Soe
> the reasons for include -X should be provided. Also check your patch
> subjects again, at least one was wrong.

-no-kvm should be included too.

I just ran across a user that was injecting '-no-kvm-irqchip' in their
libvirt XML via a custom attribute.  It turned out it was to work around
broken MSI support in their funky guest they were running.  It was the
wrong solution to the problem but they were doing it regardless.

The point is, there are users in the wild using these options.  There's
no reason to remove them if they are trivial to maintain (and they are
in their current form).

Regards,

Anthony Liguori

>
> Jan
Jan Kiszka - Oct. 4, 2012, 2:30 p.m.
On 2012-10-04 16:21, Anthony Liguori wrote:
> -no-kvm should be included too.

Reminds me that we still need to agree on the final default accel strategy.

> 
> I just ran across a user that was injecting '-no-kvm-irqchip' in their
> libvirt XML via a custom attribute.  It turned out it was to work around
> broken MSI support in their funky guest they were running.  It was the
> wrong solution to the problem but they were doing it regardless.
> 
> The point is, there are users in the wild using these options.  There's
> no reason to remove them if they are trivial to maintain (and they are
> in their current form).

So let's define a consistent policy for them all:
 - warn on the command line on use
 - avoid adding them to the help or other user documentation
 - keep them until we rework the whole command line

Jan
Andreas Färber - Oct. 4, 2012, 3:36 p.m.
Am 04.10.2012 16:30, schrieb Jan Kiszka:
> On 2012-10-04 16:21, Anthony Liguori wrote:
>> -no-kvm should be included too.
> 
> Reminds me that we still need to agree on the final default accel strategy.
> 
>>
>> I just ran across a user that was injecting '-no-kvm-irqchip' in their
>> libvirt XML via a custom attribute.  It turned out it was to work around
>> broken MSI support in their funky guest they were running.  It was the
>> wrong solution to the problem but they were doing it regardless.
>>
>> The point is, there are users in the wild using these options.  There's
>> no reason to remove them if they are trivial to maintain (and they are
>> in their current form).
> 
> So let's define a consistent policy for them all:
>  - warn on the command line on use

>  - avoid adding them to the help or other user documentation

That's dangerous - at some point someone will notice and propose a patch
documenting them and the reviewers may have forgotten by then why it was
not documented in the first place. Better clearly document them in help
output as "DEPRECATED, to be removed in future versions" or so.

Andreas

>  - keep them until we rework the whole command line
> 
> Jan
>
Jan Kiszka - Oct. 4, 2012, 4:04 p.m.
On 2012-10-04 17:36, Andreas Färber wrote:
> Am 04.10.2012 16:30, schrieb Jan Kiszka:
>> On 2012-10-04 16:21, Anthony Liguori wrote:
>>> -no-kvm should be included too.
>>
>> Reminds me that we still need to agree on the final default accel strategy.
>>
>>>
>>> I just ran across a user that was injecting '-no-kvm-irqchip' in their
>>> libvirt XML via a custom attribute.  It turned out it was to work around
>>> broken MSI support in their funky guest they were running.  It was the
>>> wrong solution to the problem but they were doing it regardless.
>>>
>>> The point is, there are users in the wild using these options.  There's
>>> no reason to remove them if they are trivial to maintain (and they are
>>> in their current form).
>>
>> So let's define a consistent policy for them all:
>>  - warn on the command line on use
> 
>>  - avoid adding them to the help or other user documentation
> 
> That's dangerous - at some point someone will notice and propose a patch
> documenting them and the reviewers may have forgotten by then why it was
> not documented in the first place. Better clearly document them in help
> output as "DEPRECATED, to be removed in future versions" or so.

-M is marked as deprecated in the file that you would have to mess up.

Jan
Andreas Färber - Oct. 4, 2012, 4:13 p.m.
Am 04.10.2012 18:04, schrieb Jan Kiszka:
> On 2012-10-04 17:36, Andreas Färber wrote:
>> Am 04.10.2012 16:30, schrieb Jan Kiszka:
>>> On 2012-10-04 16:21, Anthony Liguori wrote:
>>>  - avoid adding them to the help or other user documentation
>>
>> That's dangerous - at some point someone will notice and propose a patch
>> documenting them and the reviewers may have forgotten by then why it was
>> not documented in the first place. Better clearly document them in help
>> output as "DEPRECATED, to be removed in future versions" or so.
> 
> -M is marked as deprecated in the file that you would have to mess up.

If it's not within +/- 3 lines and goes through qemu-trivial then that
point is moot. Don't see how deprecation of -no-kvm-irqchip et al. is
related to -M being deprecated either way.

Andreas
Jan Kiszka - Oct. 4, 2012, 4:40 p.m.
On 2012-10-04 18:13, Andreas Färber wrote:
> Am 04.10.2012 18:04, schrieb Jan Kiszka:
>> On 2012-10-04 17:36, Andreas Färber wrote:
>>> Am 04.10.2012 16:30, schrieb Jan Kiszka:
>>>> On 2012-10-04 16:21, Anthony Liguori wrote:
>>>>  - avoid adding them to the help or other user documentation
>>>
>>> That's dangerous - at some point someone will notice and propose a patch
>>> documenting them and the reviewers may have forgotten by then why it was
>>> not documented in the first place. Better clearly document them in help
>>> output as "DEPRECATED, to be removed in future versions" or so.
>>
>> -M is marked as deprecated in the file that you would have to mess up.
> 
> If it's not within +/- 3 lines and goes through qemu-trivial then that
> point is moot. Don't see how deprecation of -no-kvm-irqchip et al. is
> related to -M being deprecated either way.

I'm only citing an example that these switches should follow:

[qemu-options.hx]
HXCOMM Deprecated by -machine
DEF("M", HAS_ARG, QEMU_OPTION_M, "", QEMU_ARCH_ALL)

Jan
Marcelo Tosatti - Oct. 4, 2012, 5:14 p.m.
On Thu, Oct 04, 2012 at 04:30:26PM +0200, Jan Kiszka wrote:
> On 2012-10-04 16:21, Anthony Liguori wrote:
> > -no-kvm should be included too.
> 
> Reminds me that we still need to agree on the final default accel strategy.

Default accel=kvm for x86_64 targets, no fallback.

Markus's argument is pretty convincing to me:

"Friendly perhaps, generating an infinite series of questions "why is my
guest slow as molasses?" certainly.

And for each instance of the question, there's an unknown number of
users who give QEMU a quick try, screw up KVM unknowingly, observe the
glacial speed, and conclude it's crap."

> > I just ran across a user that was injecting '-no-kvm-irqchip' in their
> > libvirt XML via a custom attribute.  It turned out it was to work around
> > broken MSI support in their funky guest they were running.  It was the
> > wrong solution to the problem but they were doing it regardless.
> > 
> > The point is, there are users in the wild using these options.  There's
> > no reason to remove them if they are trivial to maintain (and they are
> > in their current form).
> 
> So let's define a consistent policy for them all:
>  - warn on the command line on use
>  - avoid adding them to the help or other user documentation
>  - keep them until we rework the whole command line
> 
> Jan
> 
> -- 
> Siemens AG, Corporate Technology, CT RTC ITP SDP-DE
> Corporate Competence Center Embedded Linux
Marcelo Tosatti - Oct. 4, 2012, 5:16 p.m.
On Thu, Oct 04, 2012 at 05:36:38PM +0200, Andreas Färber wrote:
> Am 04.10.2012 16:30, schrieb Jan Kiszka:
> > On 2012-10-04 16:21, Anthony Liguori wrote:
> >> -no-kvm should be included too.
> > 
> > Reminds me that we still need to agree on the final default accel strategy.
> > 
> >>
> >> I just ran across a user that was injecting '-no-kvm-irqchip' in their
> >> libvirt XML via a custom attribute.  It turned out it was to work around
> >> broken MSI support in their funky guest they were running.  It was the
> >> wrong solution to the problem but they were doing it regardless.
> >>
> >> The point is, there are users in the wild using these options.  There's
> >> no reason to remove them if they are trivial to maintain (and they are
> >> in their current form).
> > 
> > So let's define a consistent policy for them all:
> >  - warn on the command line on use
> 
> >  - avoid adding them to the help or other user documentation
> 
> That's dangerous - at some point someone will notice and propose a patch
> documenting them and the reviewers may have forgotten by then why it was
> not documented in the first place. Better clearly document them in help
> output as "DEPRECATED, to be removed in future versions" or so.

Adding the policy to docs/qemukvm-compat-commands-policy.txt should workaround
that problem.

And a friendly text on the announce e-mail.

> Andreas
> 
> >  - keep them until we rework the whole command line
> > 
> > Jan
> >
Anthony Liguori - Oct. 4, 2012, 5:46 p.m.
Marcelo Tosatti <mtosatti@redhat.com> writes:

> On Thu, Oct 04, 2012 at 04:30:26PM +0200, Jan Kiszka wrote:
>> On 2012-10-04 16:21, Anthony Liguori wrote:
>> > -no-kvm should be included too.
>> 
>> Reminds me that we still need to agree on the final default accel strategy.
>
> Default accel=kvm for x86_64 targets, no fallback.

Ack.

BTW, if you want to override this, you can just do:

[machine]
accel=kvm:tcg

In /etc/qemu/target-i386.conf

So the distros can do whatever they like in their packages.

We should instruct users how to do this in an error message too in case
they want to permanently disable kvm because they don't have appropriate
hardware suport.

Regards,

Anthony Liguori

> Markus's argument is pretty convincing to me:
>
> "Friendly perhaps, generating an infinite series of questions "why is my
> guest slow as molasses?" certainly.
>
> And for each instance of the question, there's an unknown number of
> users who give QEMU a quick try, screw up KVM unknowingly, observe the
> glacial speed, and conclude it's crap."
>
>> > I just ran across a user that was injecting '-no-kvm-irqchip' in their
>> > libvirt XML via a custom attribute.  It turned out it was to work around
>> > broken MSI support in their funky guest they were running.  It was the
>> > wrong solution to the problem but they were doing it regardless.
>> > 
>> > The point is, there are users in the wild using these options.  There's
>> > no reason to remove them if they are trivial to maintain (and they are
>> > in their current form).
>> 
>> So let's define a consistent policy for them all:
>>  - warn on the command line on use
>>  - avoid adding them to the help or other user documentation
>>  - keep them until we rework the whole command line
>> 
>> Jan
>> 
>> -- 
>> Siemens AG, Corporate Technology, CT RTC ITP SDP-DE
>> Corporate Competence Center Embedded Linux
> --
> To unsubscribe from this list: send the line "unsubscribe kvm" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Patch

Index: qemu-compat-kvm/vl.c
===================================================================
--- qemu-compat-kvm.orig/vl.c
+++ qemu-compat-kvm/vl.c
@@ -3061,6 +3061,12 @@  int main(int argc, char **argv, char **e
                     machine = machine_parse(optarg);
                 }
                 break;
+            case QEMU_OPTION_no_kvm_irqchip: {
+                olist = qemu_find_opts("machine");
+                qemu_opts_parse(olist, "kernel_irqchip=off", 0);
+                break;
+            }
+
             case QEMU_OPTION_usb:
                 usb_enabled = 1;
                 break;
Index: qemu-compat-kvm/qemu-options.hx
===================================================================
--- qemu-compat-kvm.orig/qemu-options.hx
+++ qemu-compat-kvm/qemu-options.hx
@@ -2838,6 +2838,10 @@  STEXI
 Enable FIPS 140-2 compliance mode.
 ETEXI
 
+DEF("no-kvm-irqchip", 0, QEMU_OPTION_no_kvm_irqchip,
+    "-no-kvm-irqchip disable KVM kernel mode PIC/IOAPIC/LAPIC\n",
+    QEMU_ARCH_I386)
+
 HXCOMM This is the last statement. Insert new options before this line!
 STEXI
 @end table