From: Marc Zyngier <maz@kernel.org>
To: Steven Price <steven.price@arm.com>
Cc: kvm@vger.kernel.org, linux-doc@vger.kernel.org,
Catalin Marinas <catalin.marinas@arm.com>,
linux-kernel@vger.kernel.org,
Russell King <linux@armlinux.org.uk>,
Paolo Bonzini <pbonzini@redhat.com>,
Will Deacon <will@kernel.org>,
kvmarm@lists.cs.columbia.edu,
linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH 6/9] KVM: arm64: Provide a PV_TIME device to user space
Date: Wed, 7 Aug 2019 14:51:15 +0100 [thread overview]
Message-ID: <9c416f28-d078-4575-8095-8b4cccfe40ec@kernel.org> (raw)
In-Reply-To: <5aa54066-b9f6-22d1-fa2b-ce5cbf244ab5@arm.com>
On 07/08/2019 14:39, Steven Price wrote:
> On 03/08/2019 18:34, Marc Zyngier wrote:
>> On Sat, 3 Aug 2019 13:51:13 +0100
>> Marc Zyngier <maz@kernel.org> wrote:
>>
>> [forgot that one]
>>
>>> On Fri, 2 Aug 2019 15:50:14 +0100
>>> Steven Price <steven.price@arm.com> wrote:
>>
>> [...]
>>
>>>> +static int __init kvm_pvtime_init(void)
>>>> +{
>>>> + kvm_register_device_ops(&pvtime_ops, KVM_DEV_TYPE_ARM_PV_TIME);
>>>> +
>>>> + return 0;
>>>> +}
>>>> +
>>>> +late_initcall(kvm_pvtime_init);
>>
>> Why is it an initcall? So far, the only initcall we've used is the one
>> that initializes KVM itself. Can't we just the device_ops just like we
>> do for the vgic?
>
> So would you prefer a direct call from init_subsystems() in
> virt/kvm/arm/arm.c?
Yes. Consistency is important.
> The benefit of initcall is just that it keeps the code self-contained.
> In init_subsystems() I'd either need a #ifdef CONFIG_ARM64 or a dummy
> function for arm.
Having a dummy function for 32bit ARM is fine. Most of the code we add
to the 32bit port is made of empty stubs anyway.
Thanks,
M.
--
Jazz is not dead, it just smells funny...
WARNING: multiple messages have this Message-ID (diff)
From: Marc Zyngier <maz@kernel.org>
To: Steven Price <steven.price@arm.com>
Cc: kvm@vger.kernel.org, linux-doc@vger.kernel.org,
Catalin Marinas <catalin.marinas@arm.com>,
Russell King <linux@armlinux.org.uk>,
linux-kernel@vger.kernel.org, Paolo Bonzini <pbonzini@redhat.com>,
Will Deacon <will@kernel.org>,
kvmarm@lists.cs.columbia.edu,
linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH 6/9] KVM: arm64: Provide a PV_TIME device to user space
Date: Wed, 7 Aug 2019 14:51:15 +0100 [thread overview]
Message-ID: <9c416f28-d078-4575-8095-8b4cccfe40ec@kernel.org> (raw)
In-Reply-To: <5aa54066-b9f6-22d1-fa2b-ce5cbf244ab5@arm.com>
On 07/08/2019 14:39, Steven Price wrote:
> On 03/08/2019 18:34, Marc Zyngier wrote:
>> On Sat, 3 Aug 2019 13:51:13 +0100
>> Marc Zyngier <maz@kernel.org> wrote:
>>
>> [forgot that one]
>>
>>> On Fri, 2 Aug 2019 15:50:14 +0100
>>> Steven Price <steven.price@arm.com> wrote:
>>
>> [...]
>>
>>>> +static int __init kvm_pvtime_init(void)
>>>> +{
>>>> + kvm_register_device_ops(&pvtime_ops, KVM_DEV_TYPE_ARM_PV_TIME);
>>>> +
>>>> + return 0;
>>>> +}
>>>> +
>>>> +late_initcall(kvm_pvtime_init);
>>
>> Why is it an initcall? So far, the only initcall we've used is the one
>> that initializes KVM itself. Can't we just the device_ops just like we
>> do for the vgic?
>
> So would you prefer a direct call from init_subsystems() in
> virt/kvm/arm/arm.c?
Yes. Consistency is important.
> The benefit of initcall is just that it keeps the code self-contained.
> In init_subsystems() I'd either need a #ifdef CONFIG_ARM64 or a dummy
> function for arm.
Having a dummy function for 32bit ARM is fine. Most of the code we add
to the 32bit port is made of empty stubs anyway.
Thanks,
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: Steven Price <steven.price@arm.com>
Cc: kvm@vger.kernel.org, linux-doc@vger.kernel.org,
Catalin Marinas <catalin.marinas@arm.com>,
Russell King <linux@armlinux.org.uk>,
linux-kernel@vger.kernel.org, Paolo Bonzini <pbonzini@redhat.com>,
Will Deacon <will@kernel.org>,
kvmarm@lists.cs.columbia.edu,
linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH 6/9] KVM: arm64: Provide a PV_TIME device to user space
Date: Wed, 7 Aug 2019 14:51:15 +0100 [thread overview]
Message-ID: <9c416f28-d078-4575-8095-8b4cccfe40ec@kernel.org> (raw)
In-Reply-To: <5aa54066-b9f6-22d1-fa2b-ce5cbf244ab5@arm.com>
On 07/08/2019 14:39, Steven Price wrote:
> On 03/08/2019 18:34, Marc Zyngier wrote:
>> On Sat, 3 Aug 2019 13:51:13 +0100
>> Marc Zyngier <maz@kernel.org> wrote:
>>
>> [forgot that one]
>>
>>> On Fri, 2 Aug 2019 15:50:14 +0100
>>> Steven Price <steven.price@arm.com> wrote:
>>
>> [...]
>>
>>>> +static int __init kvm_pvtime_init(void)
>>>> +{
>>>> + kvm_register_device_ops(&pvtime_ops, KVM_DEV_TYPE_ARM_PV_TIME);
>>>> +
>>>> + return 0;
>>>> +}
>>>> +
>>>> +late_initcall(kvm_pvtime_init);
>>
>> Why is it an initcall? So far, the only initcall we've used is the one
>> that initializes KVM itself. Can't we just the device_ops just like we
>> do for the vgic?
>
> So would you prefer a direct call from init_subsystems() in
> virt/kvm/arm/arm.c?
Yes. Consistency is important.
> The benefit of initcall is just that it keeps the code self-contained.
> In init_subsystems() I'd either need a #ifdef CONFIG_ARM64 or a dummy
> function for arm.
Having a dummy function for 32bit ARM is fine. Most of the code we add
to the 32bit port is made of empty stubs anyway.
Thanks,
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:[~2019-08-07 13:51 UTC|newest]
Thread overview: 141+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-08-02 14:50 [PATCH 0/9] arm64: Stolen time support Steven Price
2019-08-02 14:50 ` Steven Price
2019-08-02 14:50 ` Steven Price
2019-08-02 14:50 ` [PATCH 1/9] KVM: arm64: Document PV-time interface Steven Price
2019-08-02 14:50 ` Steven Price
2019-08-02 14:50 ` Steven Price
2019-08-03 11:13 ` Marc Zyngier
2019-08-03 11:13 ` Marc Zyngier
2019-08-03 11:13 ` Marc Zyngier
2019-08-05 13:06 ` Steven Price
2019-08-05 13:06 ` Steven Price
2019-08-05 13:06 ` Steven Price
2019-08-05 3:23 ` Zenghui Yu
2019-08-05 3:23 ` Zenghui Yu
2019-08-05 3:23 ` Zenghui Yu
2019-08-05 13:06 ` Steven Price
2019-08-05 13:06 ` Steven Price
2019-08-05 13:06 ` Steven Price
2019-08-05 16:40 ` Christophe de Dinechin
2019-08-05 16:40 ` Christophe de Dinechin
2019-08-05 16:40 ` Christophe de Dinechin
2019-08-07 13:21 ` Steven Price
2019-08-07 13:21 ` Steven Price
2019-08-07 13:21 ` Steven Price
2019-08-07 14:28 ` Christophe de Dinechin
2019-08-07 15:26 ` Steven Price
2019-08-07 15:26 ` Steven Price
2019-08-07 15:26 ` Steven Price
2019-08-02 14:50 ` [PATCH 2/9] KVM: arm/arm64: Factor out hypercall handling from PSCI code Steven Price
2019-08-02 14:50 ` Steven Price
2019-08-02 14:50 ` Steven Price
2019-08-02 14:50 ` [PATCH 3/9] KVM: arm64: Implement PV_FEATURES call Steven Price
2019-08-02 14:50 ` Steven Price
2019-08-02 14:50 ` Steven Price
2019-08-03 11:21 ` Marc Zyngier
2019-08-03 11:21 ` Marc Zyngier
2019-08-03 11:21 ` Marc Zyngier
2019-08-05 13:14 ` Steven Price
2019-08-05 13:14 ` Steven Price
2019-08-05 13:14 ` Steven Price
2019-08-02 14:50 ` [PATCH 4/9] KVM: arm64: Support stolen time reporting via shared structure Steven Price
2019-08-02 14:50 ` Steven Price
2019-08-02 14:50 ` Steven Price
2019-08-03 11:55 ` Marc Zyngier
2019-08-03 11:55 ` Marc Zyngier
2019-08-03 11:55 ` Marc Zyngier
2019-08-05 14:09 ` Steven Price
2019-08-05 14:09 ` Steven Price
2019-08-05 14:09 ` Steven Price
2019-08-03 17:58 ` Marc Zyngier
2019-08-03 17:58 ` Marc Zyngier
2019-08-03 17:58 ` Marc Zyngier
2019-08-03 18:13 ` Marc Zyngier
2019-08-03 18:13 ` Marc Zyngier
2019-08-03 18:13 ` Marc Zyngier
2019-08-05 14:18 ` Steven Price
2019-08-05 14:18 ` Steven Price
2019-08-05 14:18 ` Steven Price
2019-08-02 14:50 ` [PATCH 5/9] KVM: Allow kvm_device_ops to be const Steven Price
2019-08-02 14:50 ` Steven Price
2019-08-02 14:50 ` Steven Price
2019-08-02 14:50 ` [PATCH 6/9] KVM: arm64: Provide a PV_TIME device to user space Steven Price
2019-08-02 14:50 ` Steven Price
2019-08-02 14:50 ` Steven Price
2019-08-03 12:51 ` Marc Zyngier
2019-08-03 12:51 ` Marc Zyngier
2019-08-03 12:51 ` Marc Zyngier
2019-08-03 17:34 ` Marc Zyngier
2019-08-03 17:34 ` Marc Zyngier
2019-08-03 17:34 ` Marc Zyngier
2019-08-07 13:39 ` Steven Price
2019-08-07 13:39 ` Steven Price
2019-08-07 13:39 ` Steven Price
2019-08-07 13:51 ` Marc Zyngier [this message]
2019-08-07 13:51 ` Marc Zyngier
2019-08-07 13:51 ` Marc Zyngier
2019-08-05 16:10 ` Steven Price
2019-08-05 16:10 ` Steven Price
2019-08-05 16:10 ` Steven Price
2019-08-05 16:28 ` Marc Zyngier
2019-08-05 16:28 ` Marc Zyngier
2019-08-05 16:28 ` Marc Zyngier
2019-08-02 14:50 ` [PATCH 7/9] arm/arm64: Provide a wrapper for SMCCC 1.1 calls Steven Price
2019-08-02 14:50 ` Steven Price
2019-08-02 14:50 ` Steven Price
2019-08-05 10:03 ` Will Deacon
2019-08-05 10:03 ` Will Deacon
2019-08-05 10:03 ` Will Deacon
2019-08-02 14:50 ` [PATCH 8/9] arm/arm64: Make use of the SMCCC 1.1 wrapper Steven Price
2019-08-02 14:50 ` Steven Price
2019-08-02 14:50 ` Steven Price
2019-08-02 14:50 ` [PATCH 9/9] arm64: Retrieve stolen time as paravirtualized guest Steven Price
2019-08-02 14:50 ` Steven Price
2019-08-02 14:50 ` Steven Price
2019-08-04 9:53 ` Marc Zyngier
2019-08-04 9:53 ` Marc Zyngier
2019-08-04 9:53 ` Marc Zyngier
2019-08-08 15:29 ` Steven Price
2019-08-08 15:29 ` Steven Price
2019-08-08 15:29 ` Steven Price
2019-08-08 15:49 ` Marc Zyngier
2019-08-08 15:49 ` Marc Zyngier
2019-08-08 15:49 ` Marc Zyngier
2019-08-09 13:51 ` Zenghui Yu
2019-08-09 13:51 ` Zenghui Yu
2019-08-09 13:51 ` Zenghui Yu
2019-08-12 10:39 ` Steven Price
2019-08-12 10:39 ` Steven Price
2019-08-12 10:39 ` Steven Price
2019-08-13 6:06 ` Zenghui Yu
2019-08-13 6:06 ` Zenghui Yu
2019-08-13 6:06 ` Zenghui Yu
2019-08-03 18:05 ` [PATCH 0/9] arm64: Stolen time support Marc Zyngier
2019-08-03 18:05 ` Marc Zyngier
2019-08-03 18:05 ` Marc Zyngier
2019-08-05 13:06 ` Steven Price
2019-08-05 13:06 ` Steven Price
2019-08-05 13:06 ` Steven Price
2019-08-05 13:26 ` Marc Zyngier
2019-08-05 13:26 ` Marc Zyngier
2019-08-05 13:26 ` Marc Zyngier
2019-08-14 13:02 ` Alexander Graf
2019-08-14 13:02 ` Alexander Graf
2019-08-14 13:02 ` Alexander Graf
2019-08-14 14:19 ` Marc Zyngier
2019-08-14 14:19 ` Marc Zyngier
2019-08-14 14:52 ` [UNVERIFIED SENDER] " Alexander Graf
2019-08-14 14:52 ` Alexander Graf
2019-08-14 14:52 ` Alexander Graf
2019-08-16 10:23 ` Steven Price
2019-08-16 10:23 ` Steven Price
2019-08-16 10:23 ` Steven Price
2020-07-21 3:26 ` zhukeqian
2020-07-21 3:26 ` zhukeqian
2020-07-21 3:26 ` zhukeqian
2020-07-27 10:48 ` Steven Price
2020-07-27 10:48 ` Steven Price
2020-07-27 10:48 ` Steven Price
2020-07-29 2:57 ` zhukeqian
2020-07-29 2:57 ` zhukeqian
2020-07-29 2:57 ` zhukeqian
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=9c416f28-d078-4575-8095-8b4cccfe40ec@kernel.org \
--to=maz@kernel.org \
--cc=catalin.marinas@arm.com \
--cc=kvm@vger.kernel.org \
--cc=kvmarm@lists.cs.columbia.edu \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@armlinux.org.uk \
--cc=pbonzini@redhat.com \
--cc=steven.price@arm.com \
--cc=will@kernel.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.