From: Marc Zyngier <maz@kernel.org>
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 6/8] psci: Add hvc call service for ptp_kvm.
Date: Mon, 13 Jan 2020 11:16:26 +0000 [thread overview]
Message-ID: <22ba1283a7b82f018c1fdf85414e5bfe@kernel.org> (raw)
In-Reply-To: <HE1PR0801MB167693BFB769ACEEA8A6B007F4350@HE1PR0801MB1676.eurprd08.prod.outlook.com>
Hi Jianyong,
On 2020-01-13 10:30, Jianyong Wu wrote:
> Hi Marc,
>
>> -----Original Message-----
>> From: Marc Zyngier <maz@kernel.org>
>> Sent: Friday, January 10, 2020 6:56 PM
>> NV breaks that assumtion, because the guest hypervisor is using the
>> physical
>> counter. Also, let's not forget that the hypercall isn't Linux
>> specific.
>> I can write my own non-Linux guest and still use this hypercall.
>> Nothing in
>> there says that I can't use the physical counter if I want to.
>>
>> So somehow, you need to convey the the hypervisor the notion of
>> *which*
>> counter the guest uses.
>>
>> Does it make sense? Or am I missing something?
>>
> I know what you say. Let me try to solve this problem.
> Step 0, summary out all the conditions we should process, which will
> sever as branch condition.(now only normal virt and nested virt, I
> think)
No. You shouldn't think of the various use cases, but of which time
references a guest can use. You don't need nested virt to use the
physical
counter, for example.
> Step 1, figure out the set of reference counter value used by guest
> in all condition.
That should be for the guest to tell you when it calls into the PV
service.
> Step 2, determine which reference counter value will be used by guest
> in a certain condition in hypercall.
> In step 1, can we give the set only 2 elements that one is physical
> counter the other is virtual counter?
I don't think returning the two values is useful. Just return what the
guest asks for.
> For step 2, I have no idea for that now. can you give me some hint
> about it?
Just expand your SMC call to take a parameter indicating the reference
counter, and return the sampled (or computed) value corresponding to
that counter.
M.
--
Jazz is not dead. It just smells funny...
WARNING: multiple messages have this Message-ID (diff)
From: Marc Zyngier <maz@kernel.org>
To: Jianyong Wu <Jianyong.Wu@arm.com>
Cc: Justin He <Justin.He@arm.com>,
kvm@vger.kernel.org, netdev@vger.kernel.org,
richardcochran@gmail.com, linux-kernel@vger.kernel.org,
sean.j.christopherson@intel.com,
Steven Price <Steven.Price@arm.com>,
john.stultz@linaro.org, yangbo.lu@nxp.com, pbonzini@redhat.com,
tglx@linutronix.de, nd <nd@arm.com>,
will@kernel.org, kvmarm@lists.cs.columbia.edu,
linux-arm-kernel@lists.infradead.org
Subject: Re: [RFC PATCH v9 6/8] psci: Add hvc call service for ptp_kvm.
Date: Mon, 13 Jan 2020 11:16:26 +0000 [thread overview]
Message-ID: <22ba1283a7b82f018c1fdf85414e5bfe@kernel.org> (raw)
In-Reply-To: <HE1PR0801MB167693BFB769ACEEA8A6B007F4350@HE1PR0801MB1676.eurprd08.prod.outlook.com>
Hi Jianyong,
On 2020-01-13 10:30, Jianyong Wu wrote:
> Hi Marc,
>
>> -----Original Message-----
>> From: Marc Zyngier <maz@kernel.org>
>> Sent: Friday, January 10, 2020 6:56 PM
>> NV breaks that assumtion, because the guest hypervisor is using the
>> physical
>> counter. Also, let's not forget that the hypercall isn't Linux
>> specific.
>> I can write my own non-Linux guest and still use this hypercall.
>> Nothing in
>> there says that I can't use the physical counter if I want to.
>>
>> So somehow, you need to convey the the hypervisor the notion of
>> *which*
>> counter the guest uses.
>>
>> Does it make sense? Or am I missing something?
>>
> I know what you say. Let me try to solve this problem.
> Step 0, summary out all the conditions we should process, which will
> sever as branch condition.(now only normal virt and nested virt, I
> think)
No. You shouldn't think of the various use cases, but of which time
references a guest can use. You don't need nested virt to use the
physical
counter, for example.
> Step 1, figure out the set of reference counter value used by guest
> in all condition.
That should be for the guest to tell you when it calls into the PV
service.
> Step 2, determine which reference counter value will be used by guest
> in a certain condition in hypercall.
> In step 1, can we give the set only 2 elements that one is physical
> counter the other is virtual counter?
I don't think returning the two values is useful. Just return what the
guest asks for.
> For step 2, I have no idea for that now. can you give me some hint
> about it?
Just expand your SMC call to take a parameter indicating the reference
counter, and return the sampled (or computed) value corresponding to
that counter.
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: Marc Zyngier <maz@kernel.org>
To: Jianyong Wu <Jianyong.Wu@arm.com>
Cc: Mark Rutland <Mark.Rutland@arm.com>,
Justin He <Justin.He@arm.com>,
kvm@vger.kernel.org, Suzuki Poulose <Suzuki.Poulose@arm.com>,
netdev@vger.kernel.org, richardcochran@gmail.com,
Steve Capper <Steve.Capper@arm.com>,
linux-kernel@vger.kernel.org, sean.j.christopherson@intel.com,
Steven Price <Steven.Price@arm.com>, Kaly Xin <Kaly.Xin@arm.com>,
john.stultz@linaro.org, yangbo.lu@nxp.com, pbonzini@redhat.com,
tglx@linutronix.de, nd <nd@arm.com>,
will@kernel.org, kvmarm@lists.cs.columbia.edu,
linux-arm-kernel@lists.infradead.org
Subject: Re: [RFC PATCH v9 6/8] psci: Add hvc call service for ptp_kvm.
Date: Mon, 13 Jan 2020 11:16:26 +0000 [thread overview]
Message-ID: <22ba1283a7b82f018c1fdf85414e5bfe@kernel.org> (raw)
In-Reply-To: <HE1PR0801MB167693BFB769ACEEA8A6B007F4350@HE1PR0801MB1676.eurprd08.prod.outlook.com>
Hi Jianyong,
On 2020-01-13 10:30, Jianyong Wu wrote:
> Hi Marc,
>
>> -----Original Message-----
>> From: Marc Zyngier <maz@kernel.org>
>> Sent: Friday, January 10, 2020 6:56 PM
>> NV breaks that assumtion, because the guest hypervisor is using the
>> physical
>> counter. Also, let's not forget that the hypercall isn't Linux
>> specific.
>> I can write my own non-Linux guest and still use this hypercall.
>> Nothing in
>> there says that I can't use the physical counter if I want to.
>>
>> So somehow, you need to convey the the hypervisor the notion of
>> *which*
>> counter the guest uses.
>>
>> Does it make sense? Or am I missing something?
>>
> I know what you say. Let me try to solve this problem.
> Step 0, summary out all the conditions we should process, which will
> sever as branch condition.(now only normal virt and nested virt, I
> think)
No. You shouldn't think of the various use cases, but of which time
references a guest can use. You don't need nested virt to use the
physical
counter, for example.
> Step 1, figure out the set of reference counter value used by guest
> in all condition.
That should be for the guest to tell you when it calls into the PV
service.
> Step 2, determine which reference counter value will be used by guest
> in a certain condition in hypercall.
> In step 1, can we give the set only 2 elements that one is physical
> counter the other is virtual counter?
I don't think returning the two values is useful. Just return what the
guest asks for.
> For step 2, I have no idea for that now. can you give me some hint
> about it?
Just expand your SMC call to take a parameter indicating the reference
counter, and return the sampled (or computed) value corresponding to
that counter.
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
next prev parent reply other threads:[~2020-01-13 11:16 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 [this message]
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
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=22ba1283a7b82f018c1fdf85414e5bfe@kernel.org \
--to=maz@kernel.org \
--cc=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=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.