| Message ID | 20121003105509.391284251@amt.cnet |
|---|---|
| State | New |
| Headers | show |
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
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?
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
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
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
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 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
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.
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?
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
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
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
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 >
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
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
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
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
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 > >
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
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