All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrew Jones <drjones@redhat.com>
To: Andrea Bolognani <abologna@redhat.com>
Cc: Peter Maydell <peter.maydell@linaro.org>,
	bijan.mottahedeh@oracle.com, Marc Zyngier <maz@kernel.org>,
	Richard Henderson <richard.henderson@linaro.org>,
	QEMU Developers <qemu-devel@nongnu.org>,
	qemu-arm <qemu-arm@nongnu.org>
Subject: Re: [PATCH v1 0/5] target/arm/kvm: Provide an option to adjust virtual time
Date: Tue, 10 Dec 2019 17:08:25 +0100	[thread overview]
Message-ID: <20191210160825.ioah26u36eu2i3z2@kamzik.brq.redhat.com> (raw)
In-Reply-To: <e0f86b200d0b3c08769cdbaa080569c3ec3db3ab.camel@redhat.com>

On Tue, Dec 10, 2019 at 04:47:49PM +0100, Andrea Bolognani wrote:
> On Tue, 2019-12-10 at 15:33 +0100, Andrew Jones wrote:
> > On Tue, Dec 10, 2019 at 03:21:02PM +0100, Andrea Bolognani wrote:
> > > I agree with everything except the naming: why would
> > > 
> > >   kvm-no-adjvtime=off  vtime is adjusted      (default)
> > >   kvm-no-adjvtime=on   vtime is not adjusted
> > > 
> > > be better than
> > > 
> > >   kvm-adjvtime=on   vtime is adjusted      (default)
> > >   kvm-adjvtime=off  vtime is not adjusted
> > > 
> > > ? Both offer the exact same amount of flexibility, but the latter has
> > > the advantage of not introducing any unwieldy double negatives.
> > 
> > A default of 'off' == 0 means not setting anything at all. There's
> > already precedent for 'kvm-no*' prefixed cpu features,
> > 
> > kvm-no-smi-migration
> > kvm-nopiodelay
> 
> Sorry, I'm not sure I understand. Do you mean that the array where
> you store CPU features is 0-inizialized, so it's more convenient to
> have off (0) as the default because it means you don't have to touch
> it beforehand? Or something different?
>

Right. The CPU feature flag (a boolean member of the CPU state) will
be zero by default because C. It's not a big deal, though, because the
property default can easily be set to true while it's added to a cpu
type.

I don't have a strong enough opinion about kvm-adjvtime vs.
kvm-no-adjvtime to insist one way or another. I agree double inversions
are easier to mess up, but I also like the way the '-no-' better
communicates that the default is [probably] 'yes'.

All interested parties, please vote. I'll be sending v2 soon and I can
call this thing anything the majority (or the dominate minority) prefer.

Thanks,
drew



  reply	other threads:[~2019-12-10 16:09 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-10-16 14:34 [PATCH v1 0/5] target/arm/kvm: Provide an option to adjust virtual time Andrew Jones
2019-10-16 14:34 ` [PATCH v1 1/5] target/arm/kvm64: kvm64 cpus have timer registers Andrew Jones
2019-10-16 14:34 ` [PATCH v1 2/5] timer: arm: Introduce functions to get the host cntfrq Andrew Jones
2019-12-10 15:47   ` Peter Maydell
2019-12-10 16:41     ` Andrew Jones
2019-10-16 14:34 ` [PATCH v1 3/5] target/arm/kvm: Implement cpu feature kvm-adjvtime Andrew Jones
2019-12-10 15:54   ` Peter Maydell
2019-12-10 16:10     ` Andrew Jones
2019-10-16 14:34 ` [PATCH v1 4/5] tests/arm-cpu-features: Check feature default values Andrew Jones
2019-10-16 14:34 ` [PATCH v1 5/5] target/arm/cpu: Add the kvm-adjvtime CPU property Andrew Jones
2019-10-17 21:17 ` [PATCH v1 0/5] target/arm/kvm: Provide an option to adjust virtual time Masayoshi Mizuma
2019-10-18 12:02   ` Andrew Jones
2019-10-28 18:39     ` Masayoshi Mizuma
2019-12-06 15:22 ` Peter Maydell
2019-12-06 15:53   ` Andrew Jones
2019-12-10  9:51     ` Andrea Bolognani
2019-12-10 10:29       ` Peter Maydell
2019-12-10 11:05         ` Andrew Jones
2019-12-10 11:48           ` Peter Maydell
2019-12-10 13:32             ` Andrew Jones
2019-12-10 14:21               ` Andrea Bolognani
2019-12-10 14:33                 ` Andrew Jones
2019-12-10 15:47                   ` Andrea Bolognani
2019-12-10 16:08                     ` Andrew Jones [this message]
2019-12-10 17:16                       ` Andrea Bolognani
2019-12-10 15:45               ` Peter Maydell
2019-12-11  8:02   ` Guoheyi
2019-12-11  9:00     ` Andrew Jones
2019-12-11 13:50       ` Guoheyi

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20191210160825.ioah26u36eu2i3z2@kamzik.brq.redhat.com \
    --to=drjones@redhat.com \
    --cc=abologna@redhat.com \
    --cc=bijan.mottahedeh@oracle.com \
    --cc=maz@kernel.org \
    --cc=peter.maydell@linaro.org \
    --cc=qemu-arm@nongnu.org \
    --cc=qemu-devel@nongnu.org \
    --cc=richard.henderson@linaro.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.