KVM ARM Archive on lore.kernel.org
 help / color / Atom feed
From: Andrew Jones <drjones@redhat.com>
To: Marc Zyngier <maz@kernel.org>
Cc: pbonzini@redhat.com, kvmarm@lists.cs.columbia.edu,
	kvm@vger.kernel.org, steven.price@arm.com
Subject: Re: [PATCH 1/5] KVM: arm64: pvtime: steal-time is only supported when configured
Date: Tue, 28 Jul 2020 14:55:53 +0200
Message-ID: <20200728125553.3k65bfdxs6u5pb4i@kamzik.brq.redhat.com> (raw)
In-Reply-To: <e2f23a105af0d7cf2daa6f3f8b596177@kernel.org>

On Mon, Jul 27, 2020 at 06:25:50PM +0100, Marc Zyngier wrote:
> Hi Andrew,
> 
> On 2020-07-11 11:04, Andrew Jones wrote:
> > Don't confuse the guest by saying steal-time is supported when
> > it hasn't been configured by userspace and won't work.
> > 
> > Signed-off-by: Andrew Jones <drjones@redhat.com>
> > ---
> >  arch/arm64/kvm/pvtime.c | 5 ++++-
> >  1 file changed, 4 insertions(+), 1 deletion(-)
> > 
> > diff --git a/arch/arm64/kvm/pvtime.c b/arch/arm64/kvm/pvtime.c
> > index f7b52ce1557e..2b22214909be 100644
> > --- a/arch/arm64/kvm/pvtime.c
> > +++ b/arch/arm64/kvm/pvtime.c
> > @@ -42,9 +42,12 @@ long kvm_hypercall_pv_features(struct kvm_vcpu *vcpu)
> > 
> >  	switch (feature) {
> >  	case ARM_SMCCC_HV_PV_TIME_FEATURES:
> > -	case ARM_SMCCC_HV_PV_TIME_ST:
> >  		val = SMCCC_RET_SUCCESS;
> >  		break;
> > +	case ARM_SMCCC_HV_PV_TIME_ST:
> > +		if (vcpu->arch.steal.base != GPA_INVALID)
> > +			val = SMCCC_RET_SUCCESS;
> > +		break;
> >  	}
> > 
> >  	return val;
> 
> I'm not so sure about this. I have always considered the
> discovery interface to be "do you know about this SMCCC
> function". And if you look at the spec, it says (4.2,
> PV_TIME_FEATURES):
> 
> <quote>
> If PV_call_id identifies PV_TIME_FEATURES, this call returns:
> • NOT_SUPPORTED (-1) to indicate that all
> paravirtualized time functions in this specification are not
> supported.
> • SUCCESS (0) to indicate that all the paravirtualized time
> functions in this specification are supported.
> </quote>
> 
> So the way I understand it, you cannot return "supported"
> for PV_TIME_FEATURES, and yet return NOT_SUPPORTED for
> PV_TIME_ST. It applies to *all* features.
> 
> Yes, this is very bizarre. But I don't think we can deviate
> from it.

Ah, I see your point. But I wonder if we should drop this patch
or if we should change the return of ARM_SMCCC_HV_PV_TIME_FEATURES
to be dependant on all the pv calls?

Discovery would look like this

IF (SMCCC_ARCH_FEATURES, PV_TIME_FEATURES) == 0; THEN
  IF (PV_TIME_FEATURES, PV_TIME_FEATURES) == 0; THEN
    PV_TIME_ST is supported, as well as all other PV calls
  ELIF (PV_TIME_FEATURES, PV_TIME_ST) == 0; THEN
    PV_TIME_ST is supported
  ELIF (PV_TIME_FEATURES, <another-pv-call>) == 0; THEN
    <another-pv-call> is supported
  ...
  ENDIF
ELSE
  No PV calls are supported
ENDIF

I believe the above implements a reasonable interpretation of the
specification, but the all feature (PV_TIME_FEATURES, PV_TIME_FEATURES)
thing is indeed bizarre no matter how you look at it.

Thanks,
drew

_______________________________________________
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm

  reply index

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-07-11 10:04 [PATCH 0/5] KVM: arm64: pvtime: Fixes and a new cap Andrew Jones
2020-07-11 10:04 ` [PATCH 1/5] KVM: arm64: pvtime: steal-time is only supported when configured Andrew Jones
2020-07-27 17:25   ` Marc Zyngier
2020-07-28 12:55     ` Andrew Jones [this message]
2020-07-28 13:13       ` Marc Zyngier
2020-07-28 13:29         ` Andrew Jones
2020-07-11 10:04 ` [PATCH 2/5] KVM: arm64: pvtime: Fix potential loss of stolen time Andrew Jones
2020-07-27 17:29   ` Marc Zyngier
2020-07-11 10:04 ` [PATCH 3/5] KVM: arm64: pvtime: Fix stolen time accounting across migration Andrew Jones
2020-07-27 17:54   ` Marc Zyngier
2020-07-11 10:04 ` [PATCH 4/5] KVM: Documentation minor fixups Andrew Jones
2020-07-27 17:55   ` Marc Zyngier
2020-07-11 10:04 ` [PATCH 5/5] arm64/x86: KVM: Introduce steal-time cap Andrew Jones
2020-07-27 17:58   ` Marc Zyngier
2020-07-11 10:20 ` [PATCH 0/5] KVM: arm64: pvtime: Fixes and a new cap Andrew Jones
2020-07-13  8:25 ` Steven Price
2020-07-27 11:02 ` Andrew Jones
2020-07-27 11:15   ` Marc Zyngier
2020-07-27 18:01 ` Marc Zyngier
2020-07-28 12:59   ` Andrew Jones

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=20200728125553.3k65bfdxs6u5pb4i@kamzik.brq.redhat.com \
    --to=drjones@redhat.com \
    --cc=kvm@vger.kernel.org \
    --cc=kvmarm@lists.cs.columbia.edu \
    --cc=maz@kernel.org \
    --cc=pbonzini@redhat.com \
    --cc=steven.price@arm.com \
    /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

KVM ARM Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/kvmarm/0 kvmarm/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 kvmarm kvmarm/ https://lore.kernel.org/kvmarm \
		kvmarm@lists.cs.columbia.edu
	public-inbox-index kvmarm

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/edu.columbia.cs.lists.kvmarm


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git