All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jianyong Wu <Jianyong.Wu@arm.com>
To: Marc Zyngier <maz@kernel.org>
Cc: "netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	"yangbo.lu@nxp.com" <yangbo.lu@nxp.com>,
	"john.stultz@linaro.org" <john.stultz@linaro.org>,
	"tglx@linutronix.de" <tglx@linutronix.de>,
	"pbonzini@redhat.com" <pbonzini@redhat.com>,
	"sean.j.christopherson@intel.com"
	<sean.j.christopherson@intel.com>,
	"richardcochran@gmail.com" <richardcochran@gmail.com>,
	Mark Rutland <Mark.Rutland@arm.com>,
	"will@kernel.org" <will@kernel.org>,
	Suzuki Poulose <Suzuki.Poulose@arm.com>,
	Steven Price <Steven.Price@arm.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-arm-kernel@lists.infradead.org" 
	<linux-arm-kernel@lists.infradead.org>,
	"kvmarm@lists.cs.columbia.edu" <kvmarm@lists.cs.columbia.edu>,
	"kvm@vger.kernel.org" <kvm@vger.kernel.org>,
	Steve Capper <Steve.Capper@arm.com>, Kaly Xin <Kaly.Xin@arm.com>,
	Justin He <Justin.He@arm.com>, nd <nd@arm.com>
Subject: RE: [RFC PATCH v9 7/8] ptp: arm64: Enable ptp_kvm for arm64
Date: Mon, 13 Jan 2020 10:37:48 +0000	[thread overview]
Message-ID: <HE1PR0801MB16765F2905CD0F381E33AD9EF4350@HE1PR0801MB1676.eurprd08.prod.outlook.com> (raw)
In-Reply-To: <a85deebc23c1fa77e6f70b6eaef22a34@kernel.org>

Hi Marc,

> -----Original Message-----
> From: Marc Zyngier <maz@kernel.org>
> Sent: Friday, January 10, 2020 6:35 PM
> To: Jianyong Wu <Jianyong.Wu@arm.com>
> Cc: netdev@vger.kernel.org; yangbo.lu@nxp.com; john.stultz@linaro.org;
> tglx@linutronix.de; pbonzini@redhat.com; sean.j.christopherson@intel.com;
> richardcochran@gmail.com; Mark Rutland <Mark.Rutland@arm.com>;
> will@kernel.org; Suzuki Poulose <Suzuki.Poulose@arm.com>; Steven Price
> <Steven.Price@arm.com>; linux-kernel@vger.kernel.org; linux-arm-
> kernel@lists.infradead.org; kvmarm@lists.cs.columbia.edu;
> kvm@vger.kernel.org; Steve Capper <Steve.Capper@arm.com>; Kaly Xin
> <Kaly.Xin@arm.com>; Justin He <Justin.He@arm.com>; nd <nd@arm.com>
> Subject: Re: [RFC PATCH v9 7/8] ptp: arm64: Enable ptp_kvm for arm64
> 
> Hi Jianyong,
> 
> On 2020-01-10 10:15, Jianyong Wu wrote:
> > Hi Marc,
> 
> [...]
> 
> >> >> > +	ktime_overall = hvc_res.a0 << 32 | hvc_res.a1;
> >> >> > +	*ts = ktime_to_timespec64(ktime_overall);
> >> >> > +	*cycle = hvc_res.a2 << 32 | hvc_res.a3;
> >> >>
> >> >> So why isn't that just a read of the virtual counter, given that
> >> >> what you do in the hypervisor seems to be "cntpct - cntvoff"?
> >> >>
> >> >> What am I missing here?
> >> >>
> >> > We need get clock time and counter cycle at the same time, so we
> >> > can't just read virtual counter at guest and must get it from host.
> >>
> >> See my comment in my reply to patch #6: *Must* seems like a very
> >> strong word, and you don't explain *why* that's better than just
> >> computing the total hypercall cost. Hint: given the frequency of the
> >> counter (in the few MHz
> >> range) vs the frequency of a CPU (in the multiple GHz range, and with
> >> an IPC close enough to 1), I doubt that you'll see the counter making
> >> much progress across a hypercall.
> >>
> > Sorry, I will avoid to use those strong words.
> >
> > It's really the case that the hypercall won't across cycle in general.
> > But sometimes, kernel preempt
> > may happen in the middle of the hypercall which we can't assume how
> > long before schedule back. so it's better capture them together at the
> > same time.
> 
> Fair enough. Please document the rational, as I guess others will ask the
> same questions.
> 
Ok

> Then the problem to solve is that of the reference counter, as you so far
> assume the virtual counter. I guess you need to be able to let the guest
> select the reference counter when calling the PTP service.
> 
I could not come up with an idea about the point where the guest give this info of counter value.
Where we give that interface to ptp service, as it's not a user space application.

> [...]
> 
> > By the way, does nested virtualization diff between arm64 and arm32?
> 
> There is no nested virt for 32bit (it is explicitly forbidden by the architecture).
>  
Ok, thanks

Thanks
Jianyong 

>          M.
> --
> Jazz is not dead. It just smells funny...

WARNING: multiple messages have this Message-ID (diff)
From: Jianyong Wu <Jianyong.Wu@arm.com>
To: Marc Zyngier <maz@kernel.org>
Cc: Justin He <Justin.He@arm.com>,
	"kvm@vger.kernel.org" <kvm@vger.kernel.org>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	"richardcochran@gmail.com" <richardcochran@gmail.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"sean.j.christopherson@intel.com"
	<sean.j.christopherson@intel.com>,
	Steven Price <Steven.Price@arm.com>,
	"john.stultz@linaro.org" <john.stultz@linaro.org>,
	"yangbo.lu@nxp.com" <yangbo.lu@nxp.com>,
	"pbonzini@redhat.com" <pbonzini@redhat.com>,
	"tglx@linutronix.de" <tglx@linutronix.de>, nd <nd@arm.com>,
	"will@kernel.org" <will@kernel.org>,
	"kvmarm@lists.cs.columbia.edu" <kvmarm@lists.cs.columbia.edu>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: RE: [RFC PATCH v9 7/8] ptp: arm64: Enable ptp_kvm for arm64
Date: Mon, 13 Jan 2020 10:37:48 +0000	[thread overview]
Message-ID: <HE1PR0801MB16765F2905CD0F381E33AD9EF4350@HE1PR0801MB1676.eurprd08.prod.outlook.com> (raw)
In-Reply-To: <a85deebc23c1fa77e6f70b6eaef22a34@kernel.org>

Hi Marc,

> -----Original Message-----
> From: Marc Zyngier <maz@kernel.org>
> Sent: Friday, January 10, 2020 6:35 PM
> To: Jianyong Wu <Jianyong.Wu@arm.com>
> Cc: netdev@vger.kernel.org; yangbo.lu@nxp.com; john.stultz@linaro.org;
> tglx@linutronix.de; pbonzini@redhat.com; sean.j.christopherson@intel.com;
> richardcochran@gmail.com; Mark Rutland <Mark.Rutland@arm.com>;
> will@kernel.org; Suzuki Poulose <Suzuki.Poulose@arm.com>; Steven Price
> <Steven.Price@arm.com>; linux-kernel@vger.kernel.org; linux-arm-
> kernel@lists.infradead.org; kvmarm@lists.cs.columbia.edu;
> kvm@vger.kernel.org; Steve Capper <Steve.Capper@arm.com>; Kaly Xin
> <Kaly.Xin@arm.com>; Justin He <Justin.He@arm.com>; nd <nd@arm.com>
> Subject: Re: [RFC PATCH v9 7/8] ptp: arm64: Enable ptp_kvm for arm64
> 
> Hi Jianyong,
> 
> On 2020-01-10 10:15, Jianyong Wu wrote:
> > Hi Marc,
> 
> [...]
> 
> >> >> > +	ktime_overall = hvc_res.a0 << 32 | hvc_res.a1;
> >> >> > +	*ts = ktime_to_timespec64(ktime_overall);
> >> >> > +	*cycle = hvc_res.a2 << 32 | hvc_res.a3;
> >> >>
> >> >> So why isn't that just a read of the virtual counter, given that
> >> >> what you do in the hypervisor seems to be "cntpct - cntvoff"?
> >> >>
> >> >> What am I missing here?
> >> >>
> >> > We need get clock time and counter cycle at the same time, so we
> >> > can't just read virtual counter at guest and must get it from host.
> >>
> >> See my comment in my reply to patch #6: *Must* seems like a very
> >> strong word, and you don't explain *why* that's better than just
> >> computing the total hypercall cost. Hint: given the frequency of the
> >> counter (in the few MHz
> >> range) vs the frequency of a CPU (in the multiple GHz range, and with
> >> an IPC close enough to 1), I doubt that you'll see the counter making
> >> much progress across a hypercall.
> >>
> > Sorry, I will avoid to use those strong words.
> >
> > It's really the case that the hypercall won't across cycle in general.
> > But sometimes, kernel preempt
> > may happen in the middle of the hypercall which we can't assume how
> > long before schedule back. so it's better capture them together at the
> > same time.
> 
> Fair enough. Please document the rational, as I guess others will ask the
> same questions.
> 
Ok

> Then the problem to solve is that of the reference counter, as you so far
> assume the virtual counter. I guess you need to be able to let the guest
> select the reference counter when calling the PTP service.
> 
I could not come up with an idea about the point where the guest give this info of counter value.
Where we give that interface to ptp service, as it's not a user space application.

> [...]
> 
> > By the way, does nested virtualization diff between arm64 and arm32?
> 
> There is no nested virt for 32bit (it is explicitly forbidden by the architecture).
>  
Ok, thanks

Thanks
Jianyong 

>          M.
> --
> Jazz is not dead. It just smells funny...
_______________________________________________
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm

WARNING: multiple messages have this Message-ID (diff)
From: Jianyong Wu <Jianyong.Wu@arm.com>
To: Marc Zyngier <maz@kernel.org>
Cc: Mark Rutland <Mark.Rutland@arm.com>,
	Justin He <Justin.He@arm.com>,
	"kvm@vger.kernel.org" <kvm@vger.kernel.org>,
	Suzuki Poulose <Suzuki.Poulose@arm.com>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	"richardcochran@gmail.com" <richardcochran@gmail.com>,
	Steve Capper <Steve.Capper@arm.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"sean.j.christopherson@intel.com"
	<sean.j.christopherson@intel.com>,
	Steven Price <Steven.Price@arm.com>, Kaly Xin <Kaly.Xin@arm.com>,
	"john.stultz@linaro.org" <john.stultz@linaro.org>,
	"yangbo.lu@nxp.com" <yangbo.lu@nxp.com>,
	"pbonzini@redhat.com" <pbonzini@redhat.com>,
	"tglx@linutronix.de" <tglx@linutronix.de>, nd <nd@arm.com>,
	"will@kernel.org" <will@kernel.org>,
	"kvmarm@lists.cs.columbia.edu" <kvmarm@lists.cs.columbia.edu>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: RE: [RFC PATCH v9 7/8] ptp: arm64: Enable ptp_kvm for arm64
Date: Mon, 13 Jan 2020 10:37:48 +0000	[thread overview]
Message-ID: <HE1PR0801MB16765F2905CD0F381E33AD9EF4350@HE1PR0801MB1676.eurprd08.prod.outlook.com> (raw)
In-Reply-To: <a85deebc23c1fa77e6f70b6eaef22a34@kernel.org>

Hi Marc,

> -----Original Message-----
> From: Marc Zyngier <maz@kernel.org>
> Sent: Friday, January 10, 2020 6:35 PM
> To: Jianyong Wu <Jianyong.Wu@arm.com>
> Cc: netdev@vger.kernel.org; yangbo.lu@nxp.com; john.stultz@linaro.org;
> tglx@linutronix.de; pbonzini@redhat.com; sean.j.christopherson@intel.com;
> richardcochran@gmail.com; Mark Rutland <Mark.Rutland@arm.com>;
> will@kernel.org; Suzuki Poulose <Suzuki.Poulose@arm.com>; Steven Price
> <Steven.Price@arm.com>; linux-kernel@vger.kernel.org; linux-arm-
> kernel@lists.infradead.org; kvmarm@lists.cs.columbia.edu;
> kvm@vger.kernel.org; Steve Capper <Steve.Capper@arm.com>; Kaly Xin
> <Kaly.Xin@arm.com>; Justin He <Justin.He@arm.com>; nd <nd@arm.com>
> Subject: Re: [RFC PATCH v9 7/8] ptp: arm64: Enable ptp_kvm for arm64
> 
> Hi Jianyong,
> 
> On 2020-01-10 10:15, Jianyong Wu wrote:
> > Hi Marc,
> 
> [...]
> 
> >> >> > +	ktime_overall = hvc_res.a0 << 32 | hvc_res.a1;
> >> >> > +	*ts = ktime_to_timespec64(ktime_overall);
> >> >> > +	*cycle = hvc_res.a2 << 32 | hvc_res.a3;
> >> >>
> >> >> So why isn't that just a read of the virtual counter, given that
> >> >> what you do in the hypervisor seems to be "cntpct - cntvoff"?
> >> >>
> >> >> What am I missing here?
> >> >>
> >> > We need get clock time and counter cycle at the same time, so we
> >> > can't just read virtual counter at guest and must get it from host.
> >>
> >> See my comment in my reply to patch #6: *Must* seems like a very
> >> strong word, and you don't explain *why* that's better than just
> >> computing the total hypercall cost. Hint: given the frequency of the
> >> counter (in the few MHz
> >> range) vs the frequency of a CPU (in the multiple GHz range, and with
> >> an IPC close enough to 1), I doubt that you'll see the counter making
> >> much progress across a hypercall.
> >>
> > Sorry, I will avoid to use those strong words.
> >
> > It's really the case that the hypercall won't across cycle in general.
> > But sometimes, kernel preempt
> > may happen in the middle of the hypercall which we can't assume how
> > long before schedule back. so it's better capture them together at the
> > same time.
> 
> Fair enough. Please document the rational, as I guess others will ask the
> same questions.
> 
Ok

> Then the problem to solve is that of the reference counter, as you so far
> assume the virtual counter. I guess you need to be able to let the guest
> select the reference counter when calling the PTP service.
> 
I could not come up with an idea about the point where the guest give this info of counter value.
Where we give that interface to ptp service, as it's not a user space application.

> [...]
> 
> > By the way, does nested virtualization diff between arm64 and arm32?
> 
> There is no nested virt for 32bit (it is explicitly forbidden by the architecture).
>  
Ok, thanks

Thanks
Jianyong 

>          M.
> --
> Jazz is not dead. It just smells funny...

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2020-01-13 10:38 UTC|newest]

Thread overview: 90+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-12-10  3:40 [RFC PATCH v9 0/8] Enable ptp_kvm for arm64 Jianyong Wu
2019-12-10  3:40 ` Jianyong Wu
2019-12-10  3:40 ` Jianyong Wu
2019-12-10  3:40 ` [RFC PATCH v9 1/8] arm/arm64: smccc/psci: add arm_smccc_1_1_get_conduit() Jianyong Wu
2019-12-10  3:40   ` Jianyong Wu
2019-12-10  3:40   ` Jianyong Wu
2019-12-10  3:40 ` [RFC PATCH v9 2/8] psci: let arm_smccc_1_1_invoke available by modules Jianyong Wu
2019-12-10  3:40   ` Jianyong Wu
2019-12-10  3:40   ` Jianyong Wu
2019-12-10  3:40 ` [RFC PATCH v9 3/8] ptp: Reorganize ptp_kvm modules to make it arch-independent Jianyong Wu
2019-12-10  3:40   ` Jianyong Wu
2019-12-10  3:40   ` Jianyong Wu
2019-12-10  3:40 ` [RFC PATCH v9 4/8] time: Add mechanism to recognize clocksource in time_get_snapshot Jianyong Wu
2019-12-10  3:40   ` Jianyong Wu
2019-12-10  3:40   ` Jianyong Wu
2019-12-10  3:40 ` [RFC PATCH v9 5/8] clocksource: Add clocksource id for arm arch counter Jianyong Wu
2019-12-10  3:40   ` Jianyong Wu
2019-12-10  3:40   ` Jianyong Wu
2019-12-10  3:40 ` [RFC PATCH v9 6/8] psci: Add hvc call service for ptp_kvm Jianyong Wu
2019-12-10  3:40   ` Jianyong Wu
2019-12-10  3:40   ` Jianyong Wu
2020-01-07  9:16   ` Marc Zyngier
2020-01-07  9:16     ` Marc Zyngier
2020-01-07  9:16     ` Marc Zyngier
2020-01-09  5:45     ` Jianyong Wu
2020-01-09  5:45       ` Jianyong Wu
2020-01-09  5:45       ` Jianyong Wu
2020-01-09  9:16       ` Marc Zyngier
2020-01-09  9:16         ` Marc Zyngier
2020-01-09  9:16         ` Marc Zyngier
2020-01-10  9:51         ` Jianyong Wu
2020-01-10  9:51           ` Jianyong Wu
2020-01-10  9:51           ` Jianyong Wu
2020-01-10 10:56           ` Marc Zyngier
2020-01-10 10:56             ` Marc Zyngier
2020-01-10 10:56             ` Marc Zyngier
2020-01-13 10:30             ` Jianyong Wu
2020-01-13 10:30               ` Jianyong Wu
2020-01-13 10:30               ` Jianyong Wu
2020-01-13 11:16               ` Marc Zyngier
2020-01-13 11:16                 ` Marc Zyngier
2020-01-13 11:16                 ` Marc Zyngier
2020-01-14 10:34                 ` Jianyong Wu
2020-01-14 10:34                   ` Jianyong Wu
2020-01-14 10:34                   ` Jianyong Wu
2019-12-10  3:40 ` [RFC PATCH v9 7/8] ptp: arm64: Enable ptp_kvm for arm64 Jianyong Wu
2019-12-10  3:40   ` Jianyong Wu
2019-12-10  3:40   ` Jianyong Wu
2020-01-07  9:29   ` Marc Zyngier
2020-01-07  9:29     ` Marc Zyngier
2020-01-07  9:29     ` Marc Zyngier
2020-01-09  5:59     ` Jianyong Wu
2020-01-09  5:59       ` Jianyong Wu
2020-01-09  5:59       ` Jianyong Wu
2020-01-09  9:24       ` Marc Zyngier
2020-01-09  9:24         ` Marc Zyngier
2020-01-09  9:24         ` Marc Zyngier
2020-01-09  9:46         ` Marc Zyngier
2020-01-09  9:46           ` Marc Zyngier
2020-01-09  9:46           ` Marc Zyngier
2020-01-10 10:15           ` Jianyong Wu
2020-01-10 10:15             ` Jianyong Wu
2020-01-10 10:15             ` Jianyong Wu
2020-01-10 10:15         ` Jianyong Wu
2020-01-10 10:15           ` Jianyong Wu
2020-01-10 10:15           ` Jianyong Wu
2020-01-10 10:35           ` Marc Zyngier
2020-01-10 10:35             ` Marc Zyngier
2020-01-10 10:35             ` Marc Zyngier
2020-01-13 10:37             ` Jianyong Wu [this message]
2020-01-13 10:37               ` Jianyong Wu
2020-01-13 10:37               ` Jianyong Wu
2020-01-13 11:21               ` Marc Zyngier
2020-01-13 11:21                 ` Marc Zyngier
2020-01-13 11:21                 ` Marc Zyngier
2020-01-14 10:22                 ` Jianyong Wu
2020-01-14 10:22                   ` Jianyong Wu
2020-01-14 10:22                   ` Jianyong Wu
2019-12-10  3:40 ` [RFC PATCH v9 8/8] kvm: arm64: Add capability check extension for ptp_kvm Jianyong Wu
2019-12-10  3:40   ` Jianyong Wu
2019-12-10  3:40   ` Jianyong Wu
2020-01-06  9:38 ` [RFC PATCH v9 0/8] Enable ptp_kvm for arm64 Jianyong Wu
2020-01-06  9:38   ` Jianyong Wu
2020-01-06  9:38   ` Jianyong Wu
2020-01-07  8:15   ` Paolo Bonzini
2020-01-07  8:15     ` Paolo Bonzini
2020-01-07  8:15     ` Paolo Bonzini
2020-01-07  9:33     ` Marc Zyngier
2020-01-07  9:33       ` Marc Zyngier
2020-01-07  9:33       ` Marc Zyngier

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=HE1PR0801MB16765F2905CD0F381E33AD9EF4350@HE1PR0801MB1676.eurprd08.prod.outlook.com \
    --to=jianyong.wu@arm.com \
    --cc=Justin.He@arm.com \
    --cc=Kaly.Xin@arm.com \
    --cc=Mark.Rutland@arm.com \
    --cc=Steve.Capper@arm.com \
    --cc=Steven.Price@arm.com \
    --cc=Suzuki.Poulose@arm.com \
    --cc=john.stultz@linaro.org \
    --cc=kvm@vger.kernel.org \
    --cc=kvmarm@lists.cs.columbia.edu \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=maz@kernel.org \
    --cc=nd@arm.com \
    --cc=netdev@vger.kernel.org \
    --cc=pbonzini@redhat.com \
    --cc=richardcochran@gmail.com \
    --cc=sean.j.christopherson@intel.com \
    --cc=tglx@linutronix.de \
    --cc=will@kernel.org \
    --cc=yangbo.lu@nxp.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
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.