From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:59670) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VgDkp-00053f-NF for qemu-devel@nongnu.org; Tue, 12 Nov 2013 08:11:43 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VgDke-0002bd-N3 for qemu-devel@nongnu.org; Tue, 12 Nov 2013 08:11:39 -0500 Date: Tue, 12 Nov 2013 14:11:16 +0100 From: Igor Mammedov Message-ID: <20131112141116.02244000@thinkpad> In-Reply-To: <5282217F.3050401@ozlabs.ru> References: <1384155875-26999-1-git-send-email-aik@ozlabs.ru> <1384155875-26999-5-git-send-email-aik@ozlabs.ru> <5280D061.50802@suse.de> <20131111152546.4be13e10@thinkpad> <52816D26.3070708@ozlabs.ru> <20131112105837.63c831e6@thinkpad> <5282217F.3050401@ozlabs.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PATCH v3 4/6] qemu-option: support +foo/-foo command line agruments List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Alexey Kardashevskiy Cc: Alexander Graf , Jan Kiszka , qemu-devel@nongnu.org, Luiz Capitulino , qemu-ppc@nongnu.org, Anthony Liguori , Andreas =?ISO-8859-1?B?RuRyYmVy?= On Tue, 12 Nov 2013 23:39:27 +1100 Alexey Kardashevskiy wrote: > On 12.11.2013 20:58, Igor Mammedov wrote: > > On Tue, 12 Nov 2013 10:49:58 +1100 > > Alexey Kardashevskiy wrote: > >=20 > >> On 11/12/2013 01:25 AM, Igor Mammedov wrote: > >>> On Mon, 11 Nov 2013 13:41:05 +0100 > >>> Andreas F=E4rber wrote: > >>> > >>>> Am 11.11.2013 08:44, schrieb Alexey Kardashevskiy: > >>>>> This converts +foo/-foo to "foo=3Don"/"foo=3Doff" respectively when > >>>>> QEMU parser is used for the command line options. > >>>>> > >>>>> "-cpu" parsers in x86 and other architectures should be unaffected > >>>>> by this change. > >>>>> > >>>>> Signed-off-by: Alexey Kardashevskiy > >>>>> --- > >>>>> util/qemu-option.c | 6 ++++++ > >>>>> 1 file changed, 6 insertions(+) > >>>>> > >>>>> diff --git a/util/qemu-option.c b/util/qemu-option.c > >>>>> index efcb5dc..6c8667c 100644 > >>>>> --- a/util/qemu-option.c > >>>>> +++ b/util/qemu-option.c > >>>>> @@ -890,6 +890,12 @@ static int opts_do_parse(QemuOpts *opts, const= char *params, > >>>>> if (strncmp(option, "no", 2) =3D=3D 0) { > >>>>> memmove(option, option+2, strlen(option+2)+1); > >>>>> pstrcpy(value, sizeof(value), "off"); > >>>>> + } else if (strncmp(option, "-", 1) =3D=3D 0) { > >>>>> + memmove(option, option+1, strlen(option+1)+1); > >>>>> + pstrcpy(value, sizeof(value), "off"); > >>>>> + } else if (strncmp(option, "+", 1) =3D=3D 0) { > >>>>> + memmove(option, option+1, strlen(option+1)+1); > >>>>> + pstrcpy(value, sizeof(value), "on"); > >>>>> } else { > >>>>> pstrcpy(value, sizeof(value), "on"); > >>>>> } > >>>> > >>>> This looks like an interesting idea! However this is much too big a > >>>> change to just CC ppc folks on... > >>>> > >>>> Jan, I wonder if this might break slirp's hostfwd option? > >>>> > >>>> Not sure what other options potentially starting with '-' might be > >>>> affected. Test cases would be a helpful way of demonstrating that th= is > >>>> change does not have undesired side effects. > >>> on x86 there is several value fixups for compatibility reason and a m= anual > >>> value parsing in cpu_x86_parse_featurestr(), so above won't just work= there. > >> > >> > >> What particular x86 CPU option cannot be handled the way as PPC's "VSX= " is > >> handled two patches below? As I see, even static properties will work = there > >> fine. > > There is legacy code that is kept for CLI compatibility reasons. > > Please, look at following features in cpu_x86_parse_featurestr(): > > xlevel, tsc-freq hv-spinlocks >=20 > Ok, I do not know for sure if static properties support setters/getters > (they do not if I remember correct) but what does prevent these x86 > properties from being _dynamic_? nothing, except of: * it's better to keep CPU device model clean from legacy hacks so that leg= acy silent fixups of invalid values won't be available via other interfaces except of CLI. That will force users to use correct property names/values and not break old users that use legacy CLI options. >=20 > > the rest feature flags on x86 should be handled just fine by your patch, > > once x86properties series is applied.=20 > >=20 > > that's why we are talking about parser hook that could be overridden > > by target if necessary. >=20 > This part confuses me the most. I thought I added the hook and I did not > change other than PPC archs so my patches should have gone quite easily > to upstream but instead I was told (I think I was but I could > misunderstand) that other folks may be unhappy that my stuff does not > support +foo/-foo (which could be added later). >=20 > Could you please point me to the x86properties patch(es) which everybody > is waiting for? Thanks! latest is available at https://github.com/imammedo/qemu/tree/x86-cpu-properties.v10.1 which basically is a rebase with fixed conflicts of v9 http://comments.gmane.org/gmane.comp.emulators.qemu/222284 > > PS: > > extending QemuOpts to parsing +/-opts format, seems like good workaround > > above problem. But I was under impression that general movement was to = convert > > custom formats to canonical format "prop=3Dvalue". >=20 > Heh. I do not understand movements in the qemu project most of the time > :) I thought I could have added "compat" to PowerPC CPU as others did > but I was so wrong :) >=20 >=20 >=20 > --=20 > With best regards >=20 > Alexey Kardashevskiy -- icq: 52150396 --=20 Regards, Igor