All of lore.kernel.org
 help / color / mirror / Atom feed
From: Reiji Watanabe <reijiw@google.com>
To: Raghavendra Rao Ananta <rananta@google.com>
Cc: Marc Zyngier <maz@kernel.org>, Andrew Jones <drjones@redhat.com>,
	James Morse <james.morse@arm.com>,
	Alexandru Elisei <alexandru.elisei@arm.com>,
	Suzuki K Poulose <suzuki.poulose@arm.com>,
	Paolo Bonzini <pbonzini@redhat.com>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Will Deacon <will@kernel.org>, Peter Shier <pshier@google.com>,
	Ricardo Koller <ricarkol@google.com>,
	Oliver Upton <oupton@google.com>,
	Jing Zhang <jingzhangos@google.com>,
	Linux ARM <linux-arm-kernel@lists.infradead.org>,
	kvmarm@lists.cs.columbia.edu, linux-kernel@vger.kernel.org,
	kvm@vger.kernel.org
Subject: Re: [RFC PATCH v3 03/11] KVM: Introduce KVM_CAP_ARM_HVC_FW_REG_BMAP
Date: Fri, 7 Jan 2022 21:40:14 -0800	[thread overview]
Message-ID: <CAAeT=FxCCD+H1z8+gfyBZNeibfAUqUenZZe56Vj_3fCghJjy=Q@mail.gmail.com> (raw)
In-Reply-To: <20220104194918.373612-4-rananta@google.com>

Hi Raghu,

On Tue, Jan 4, 2022 at 11:49 AM Raghavendra Rao Ananta
<rananta@google.com> wrote:
>
> Introduce the KVM ARM64 capability, KVM_CAP_ARM_HVC_FW_REG_BMAP,
> to indicate the support for psuedo-firmware bitmap extension.
> Each of these registers holds a feature-set exposed to the guest
> in the form of a bitmap. If supported, a simple 'read' of the
> capability should return the number of psuedo-firmware registers
> supported. User-space can utilize this to discover the registers.
> It can further explore or modify the features using the classical
> GET/SET_ONE_REG interface.
>
> Signed-off-by: Raghavendra Rao Ananta <rananta@google.com>
> ---
>  Documentation/virt/kvm/api.rst | 21 +++++++++++++++++++++
>  include/uapi/linux/kvm.h       |  1 +
>  2 files changed, 22 insertions(+)
>
> diff --git a/Documentation/virt/kvm/api.rst b/Documentation/virt/kvm/api.rst
> index aeeb071c7688..646176537f2c 100644
> --- a/Documentation/virt/kvm/api.rst
> +++ b/Documentation/virt/kvm/api.rst
> @@ -6925,6 +6925,27 @@ indicated by the fd to the VM this is called on.
>  This is intended to support intra-host migration of VMs between userspace VMMs,
>  upgrading the VMM process without interrupting the guest.
>
> +7.30 KVM_CAP_ARM_HVC_FW_REG_BMAP

IMHO, instead of including its format of the register in the name,
including its purpose/function in the name might be better.
e.g. KVM_CAP_ARM_HVC_FEATURE_REG ?
(Feature fields don't necessarily have to be in a bitmap format
 if they don't fit well although I'm not sure if we have such fields.)

> +--------------------------------
> +
> +:Architectures: arm64
> +:Parameters: None
> +:Returns: Number of psuedo-firmware registers supported

Looking at patch-4, the return value of this would be the number of
pseudo-firmware *bitmap* registers supported.
BTW, "4.68 KVM_SET_ONE_REG" in the doc uses the word "arm64 firmware
pseudo-registers".  It would be nicer to use the same term.

> +
> +This capability indicates that KVM for arm64 supports the psuedo-firmware
> +register bitmap extension. Each of these registers represent the features
> +supported by a particular type in the form of a bitmap. By default, these
> +registers are set with the upper limit of the features that are supported.
> +
> +The registers can be accessed via the standard SET_ONE_REG and KVM_GET_ONE_REG
> +interfaces. The user-space is expected to read the number of these registers
> +available by reading KVM_CAP_ARM_HVC_FW_REG_BMAP, read the current bitmap
> +configuration via GET_ONE_REG for each register, and then write back the
> +desired bitmap of features that it wishes the guest to see via SET_ONE_REG.
> +
> +Note that KVM doesn't allow the user-space to modify these registers after
> +the VM (any of the vCPUs) has started running.

Since even if KVM_RUN fails, and the VM hasn't started yet,
it will get immutable. So, "after any of the vCPUs run KVM_RUN."
might be more clear ?

Thanks,
Reiji



> +
>  8. Other capabilities.
>  ======================
>
> diff --git a/include/uapi/linux/kvm.h b/include/uapi/linux/kvm.h
> index 1daa45268de2..209b43dbbc3c 100644
> --- a/include/uapi/linux/kvm.h
> +++ b/include/uapi/linux/kvm.h
> @@ -1131,6 +1131,7 @@ struct kvm_ppc_resize_hpt {
>  #define KVM_CAP_EXIT_ON_EMULATION_FAILURE 204
>  #define KVM_CAP_ARM_MTE 205
>  #define KVM_CAP_VM_MOVE_ENC_CONTEXT_FROM 206
> +#define KVM_CAP_ARM_HVC_FW_REG_BMAP 207
>
>  #ifdef KVM_CAP_IRQ_ROUTING
>
> --
> 2.34.1.448.ga2b2bfdf31-goog
>

WARNING: multiple messages have this Message-ID (diff)
From: Reiji Watanabe <reijiw@google.com>
To: Raghavendra Rao Ananta <rananta@google.com>
Cc: kvm@vger.kernel.org, Will Deacon <will@kernel.org>,
	Marc Zyngier <maz@kernel.org>, Peter Shier <pshier@google.com>,
	linux-kernel@vger.kernel.org,
	Catalin Marinas <catalin.marinas@arm.com>,
	Paolo Bonzini <pbonzini@redhat.com>,
	kvmarm@lists.cs.columbia.edu,
	Linux ARM <linux-arm-kernel@lists.infradead.org>
Subject: Re: [RFC PATCH v3 03/11] KVM: Introduce KVM_CAP_ARM_HVC_FW_REG_BMAP
Date: Fri, 7 Jan 2022 21:40:14 -0800	[thread overview]
Message-ID: <CAAeT=FxCCD+H1z8+gfyBZNeibfAUqUenZZe56Vj_3fCghJjy=Q@mail.gmail.com> (raw)
In-Reply-To: <20220104194918.373612-4-rananta@google.com>

Hi Raghu,

On Tue, Jan 4, 2022 at 11:49 AM Raghavendra Rao Ananta
<rananta@google.com> wrote:
>
> Introduce the KVM ARM64 capability, KVM_CAP_ARM_HVC_FW_REG_BMAP,
> to indicate the support for psuedo-firmware bitmap extension.
> Each of these registers holds a feature-set exposed to the guest
> in the form of a bitmap. If supported, a simple 'read' of the
> capability should return the number of psuedo-firmware registers
> supported. User-space can utilize this to discover the registers.
> It can further explore or modify the features using the classical
> GET/SET_ONE_REG interface.
>
> Signed-off-by: Raghavendra Rao Ananta <rananta@google.com>
> ---
>  Documentation/virt/kvm/api.rst | 21 +++++++++++++++++++++
>  include/uapi/linux/kvm.h       |  1 +
>  2 files changed, 22 insertions(+)
>
> diff --git a/Documentation/virt/kvm/api.rst b/Documentation/virt/kvm/api.rst
> index aeeb071c7688..646176537f2c 100644
> --- a/Documentation/virt/kvm/api.rst
> +++ b/Documentation/virt/kvm/api.rst
> @@ -6925,6 +6925,27 @@ indicated by the fd to the VM this is called on.
>  This is intended to support intra-host migration of VMs between userspace VMMs,
>  upgrading the VMM process without interrupting the guest.
>
> +7.30 KVM_CAP_ARM_HVC_FW_REG_BMAP

IMHO, instead of including its format of the register in the name,
including its purpose/function in the name might be better.
e.g. KVM_CAP_ARM_HVC_FEATURE_REG ?
(Feature fields don't necessarily have to be in a bitmap format
 if they don't fit well although I'm not sure if we have such fields.)

> +--------------------------------
> +
> +:Architectures: arm64
> +:Parameters: None
> +:Returns: Number of psuedo-firmware registers supported

Looking at patch-4, the return value of this would be the number of
pseudo-firmware *bitmap* registers supported.
BTW, "4.68 KVM_SET_ONE_REG" in the doc uses the word "arm64 firmware
pseudo-registers".  It would be nicer to use the same term.

> +
> +This capability indicates that KVM for arm64 supports the psuedo-firmware
> +register bitmap extension. Each of these registers represent the features
> +supported by a particular type in the form of a bitmap. By default, these
> +registers are set with the upper limit of the features that are supported.
> +
> +The registers can be accessed via the standard SET_ONE_REG and KVM_GET_ONE_REG
> +interfaces. The user-space is expected to read the number of these registers
> +available by reading KVM_CAP_ARM_HVC_FW_REG_BMAP, read the current bitmap
> +configuration via GET_ONE_REG for each register, and then write back the
> +desired bitmap of features that it wishes the guest to see via SET_ONE_REG.
> +
> +Note that KVM doesn't allow the user-space to modify these registers after
> +the VM (any of the vCPUs) has started running.

Since even if KVM_RUN fails, and the VM hasn't started yet,
it will get immutable. So, "after any of the vCPUs run KVM_RUN."
might be more clear ?

Thanks,
Reiji



> +
>  8. Other capabilities.
>  ======================
>
> diff --git a/include/uapi/linux/kvm.h b/include/uapi/linux/kvm.h
> index 1daa45268de2..209b43dbbc3c 100644
> --- a/include/uapi/linux/kvm.h
> +++ b/include/uapi/linux/kvm.h
> @@ -1131,6 +1131,7 @@ struct kvm_ppc_resize_hpt {
>  #define KVM_CAP_EXIT_ON_EMULATION_FAILURE 204
>  #define KVM_CAP_ARM_MTE 205
>  #define KVM_CAP_VM_MOVE_ENC_CONTEXT_FROM 206
> +#define KVM_CAP_ARM_HVC_FW_REG_BMAP 207
>
>  #ifdef KVM_CAP_IRQ_ROUTING
>
> --
> 2.34.1.448.ga2b2bfdf31-goog
>
_______________________________________________
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: Reiji Watanabe <reijiw@google.com>
To: Raghavendra Rao Ananta <rananta@google.com>
Cc: Marc Zyngier <maz@kernel.org>, Andrew Jones <drjones@redhat.com>,
	 James Morse <james.morse@arm.com>,
	Alexandru Elisei <alexandru.elisei@arm.com>,
	Suzuki K Poulose <suzuki.poulose@arm.com>,
	Paolo Bonzini <pbonzini@redhat.com>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Will Deacon <will@kernel.org>,  Peter Shier <pshier@google.com>,
	Ricardo Koller <ricarkol@google.com>,
	 Oliver Upton <oupton@google.com>,
	Jing Zhang <jingzhangos@google.com>,
	 Linux ARM <linux-arm-kernel@lists.infradead.org>,
	kvmarm@lists.cs.columbia.edu, linux-kernel@vger.kernel.org,
	kvm@vger.kernel.org
Subject: Re: [RFC PATCH v3 03/11] KVM: Introduce KVM_CAP_ARM_HVC_FW_REG_BMAP
Date: Fri, 7 Jan 2022 21:40:14 -0800	[thread overview]
Message-ID: <CAAeT=FxCCD+H1z8+gfyBZNeibfAUqUenZZe56Vj_3fCghJjy=Q@mail.gmail.com> (raw)
In-Reply-To: <20220104194918.373612-4-rananta@google.com>

Hi Raghu,

On Tue, Jan 4, 2022 at 11:49 AM Raghavendra Rao Ananta
<rananta@google.com> wrote:
>
> Introduce the KVM ARM64 capability, KVM_CAP_ARM_HVC_FW_REG_BMAP,
> to indicate the support for psuedo-firmware bitmap extension.
> Each of these registers holds a feature-set exposed to the guest
> in the form of a bitmap. If supported, a simple 'read' of the
> capability should return the number of psuedo-firmware registers
> supported. User-space can utilize this to discover the registers.
> It can further explore or modify the features using the classical
> GET/SET_ONE_REG interface.
>
> Signed-off-by: Raghavendra Rao Ananta <rananta@google.com>
> ---
>  Documentation/virt/kvm/api.rst | 21 +++++++++++++++++++++
>  include/uapi/linux/kvm.h       |  1 +
>  2 files changed, 22 insertions(+)
>
> diff --git a/Documentation/virt/kvm/api.rst b/Documentation/virt/kvm/api.rst
> index aeeb071c7688..646176537f2c 100644
> --- a/Documentation/virt/kvm/api.rst
> +++ b/Documentation/virt/kvm/api.rst
> @@ -6925,6 +6925,27 @@ indicated by the fd to the VM this is called on.
>  This is intended to support intra-host migration of VMs between userspace VMMs,
>  upgrading the VMM process without interrupting the guest.
>
> +7.30 KVM_CAP_ARM_HVC_FW_REG_BMAP

IMHO, instead of including its format of the register in the name,
including its purpose/function in the name might be better.
e.g. KVM_CAP_ARM_HVC_FEATURE_REG ?
(Feature fields don't necessarily have to be in a bitmap format
 if they don't fit well although I'm not sure if we have such fields.)

> +--------------------------------
> +
> +:Architectures: arm64
> +:Parameters: None
> +:Returns: Number of psuedo-firmware registers supported

Looking at patch-4, the return value of this would be the number of
pseudo-firmware *bitmap* registers supported.
BTW, "4.68 KVM_SET_ONE_REG" in the doc uses the word "arm64 firmware
pseudo-registers".  It would be nicer to use the same term.

> +
> +This capability indicates that KVM for arm64 supports the psuedo-firmware
> +register bitmap extension. Each of these registers represent the features
> +supported by a particular type in the form of a bitmap. By default, these
> +registers are set with the upper limit of the features that are supported.
> +
> +The registers can be accessed via the standard SET_ONE_REG and KVM_GET_ONE_REG
> +interfaces. The user-space is expected to read the number of these registers
> +available by reading KVM_CAP_ARM_HVC_FW_REG_BMAP, read the current bitmap
> +configuration via GET_ONE_REG for each register, and then write back the
> +desired bitmap of features that it wishes the guest to see via SET_ONE_REG.
> +
> +Note that KVM doesn't allow the user-space to modify these registers after
> +the VM (any of the vCPUs) has started running.

Since even if KVM_RUN fails, and the VM hasn't started yet,
it will get immutable. So, "after any of the vCPUs run KVM_RUN."
might be more clear ?

Thanks,
Reiji



> +
>  8. Other capabilities.
>  ======================
>
> diff --git a/include/uapi/linux/kvm.h b/include/uapi/linux/kvm.h
> index 1daa45268de2..209b43dbbc3c 100644
> --- a/include/uapi/linux/kvm.h
> +++ b/include/uapi/linux/kvm.h
> @@ -1131,6 +1131,7 @@ struct kvm_ppc_resize_hpt {
>  #define KVM_CAP_EXIT_ON_EMULATION_FAILURE 204
>  #define KVM_CAP_ARM_MTE 205
>  #define KVM_CAP_VM_MOVE_ENC_CONTEXT_FROM 206
> +#define KVM_CAP_ARM_HVC_FW_REG_BMAP 207
>
>  #ifdef KVM_CAP_IRQ_ROUTING
>
> --
> 2.34.1.448.ga2b2bfdf31-goog
>

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

  reply	other threads:[~2022-01-08  5:40 UTC|newest]

Thread overview: 153+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-01-04 19:49 [RFC PATCH v3 00/11] KVM: arm64: Add support for hypercall services selection Raghavendra Rao Ananta
2022-01-04 19:49 ` Raghavendra Rao Ananta
2022-01-04 19:49 ` Raghavendra Rao Ananta
2022-01-04 19:49 ` [RFC PATCH v3 01/11] KVM: Capture VM start Raghavendra Rao Ananta
2022-01-04 19:49   ` Raghavendra Rao Ananta
2022-01-04 19:49   ` Raghavendra Rao Ananta
2022-01-07  6:06   ` Reiji Watanabe
2022-01-07  6:06     ` Reiji Watanabe
2022-01-07  6:06     ` Reiji Watanabe
2022-01-07 23:43     ` Raghavendra Rao Ananta
2022-01-07 23:43       ` Raghavendra Rao Ananta
2022-01-07 23:43       ` Raghavendra Rao Ananta
2022-01-08  0:04       ` Jim Mattson
2022-01-08  0:04         ` Jim Mattson
2022-01-08  0:04         ` Jim Mattson
2022-01-10 23:07         ` Raghavendra Rao Ananta
2022-01-10 23:07           ` Raghavendra Rao Ananta
2022-01-10 23:07           ` Raghavendra Rao Ananta
2022-01-10 23:57           ` Jim Mattson
2022-01-10 23:57             ` Jim Mattson
2022-01-10 23:57             ` Jim Mattson
2022-01-11 18:52             ` Raghavendra Rao Ananta
2022-01-11 18:52               ` Raghavendra Rao Ananta
2022-01-11 18:52               ` Raghavendra Rao Ananta
2022-01-11 19:16               ` Jim Mattson
2022-01-11 19:16                 ` Jim Mattson
2022-01-11 19:16                 ` Jim Mattson
2022-01-12 18:29                 ` Raghavendra Rao Ananta
2022-01-12 18:29                   ` Raghavendra Rao Ananta
2022-01-12 18:29                   ` Raghavendra Rao Ananta
2022-01-13 17:21                   ` Sean Christopherson
2022-01-13 17:21                     ` Sean Christopherson
2022-01-13 17:21                     ` Sean Christopherson
2022-01-14  0:42                     ` Raghavendra Rao Ananta
2022-01-14  0:42                       ` Raghavendra Rao Ananta
2022-01-14  0:42                       ` Raghavendra Rao Ananta
2022-01-14  1:10                       ` Sean Christopherson
2022-01-14  1:10                         ` Sean Christopherson
2022-01-14  1:10                         ` Sean Christopherson
2022-01-14 21:51                     ` Reiji Watanabe
2022-01-14 21:51                       ` Reiji Watanabe
2022-01-14 21:51                       ` Reiji Watanabe
2022-01-18 22:54                       ` Raghavendra Rao Ananta
2022-01-18 22:54                         ` Raghavendra Rao Ananta
2022-01-18 22:54                         ` Raghavendra Rao Ananta
2022-01-19  0:07                       ` Sean Christopherson
2022-01-19  0:07                         ` Sean Christopherson
2022-01-19  0:07                         ` Sean Christopherson
2022-01-19  7:47                         ` Reiji Watanabe
2022-01-19  7:47                           ` Reiji Watanabe
2022-01-19  7:47                           ` Reiji Watanabe
2022-01-20  0:27                           ` Sean Christopherson
2022-01-20  0:27                             ` Sean Christopherson
2022-01-20  0:27                             ` Sean Christopherson
2022-01-20 19:16                             ` Raghavendra Rao Ananta
2022-01-20 19:16                               ` Raghavendra Rao Ananta
2022-01-20 19:16                               ` Raghavendra Rao Ananta
2022-01-25 15:15                         ` Marc Zyngier
2022-01-25 15:15                           ` Marc Zyngier
2022-01-25 15:15                           ` Marc Zyngier
2022-01-25 15:10                     ` Marc Zyngier
2022-01-25 15:10                       ` Marc Zyngier
2022-01-25 15:10                       ` Marc Zyngier
2022-01-11  0:03       ` Reiji Watanabe
2022-01-11  0:03         ` Reiji Watanabe
2022-01-11  0:03         ` Reiji Watanabe
2022-01-11 18:54         ` Raghavendra Rao Ananta
2022-01-11 18:54           ` Raghavendra Rao Ananta
2022-01-11 18:54           ` Raghavendra Rao Ananta
2022-01-08  1:06   ` Sean Christopherson
2022-01-08  1:06     ` Sean Christopherson
2022-01-08  1:06     ` Sean Christopherson
2022-01-10 23:23     ` Raghavendra Rao Ananta
2022-01-10 23:23       ` Raghavendra Rao Ananta
2022-01-10 23:23       ` Raghavendra Rao Ananta
2022-01-11 17:36       ` Sean Christopherson
2022-01-11 17:36         ` Sean Christopherson
2022-01-11 17:36         ` Sean Christopherson
2022-01-11 18:46         ` Raghavendra Rao Ananta
2022-01-11 18:46           ` Raghavendra Rao Ananta
2022-01-11 18:46           ` Raghavendra Rao Ananta
2022-01-11 19:04           ` Sean Christopherson
2022-01-11 19:04             ` Sean Christopherson
2022-01-11 19:04             ` Sean Christopherson
2022-01-12 18:08             ` Raghavendra Rao Ananta
2022-01-12 18:08               ` Raghavendra Rao Ananta
2022-01-12 18:08               ` Raghavendra Rao Ananta
2022-01-12 18:24               ` Sean Christopherson
2022-01-12 18:24                 ` Sean Christopherson
2022-01-12 18:24                 ` Sean Christopherson
2022-01-12 18:31                 ` Sean Christopherson
2022-01-12 18:31                   ` Sean Christopherson
2022-01-12 18:31                   ` Sean Christopherson
2022-01-04 19:49 ` [RFC PATCH v3 02/11] KVM: arm64: Factor out firmware register handling from psci.c Raghavendra Rao Ananta
2022-01-04 19:49   ` Raghavendra Rao Ananta
2022-01-04 19:49   ` Raghavendra Rao Ananta
2022-01-04 19:49 ` [RFC PATCH v3 03/11] KVM: Introduce KVM_CAP_ARM_HVC_FW_REG_BMAP Raghavendra Rao Ananta
2022-01-04 19:49   ` Raghavendra Rao Ananta
2022-01-04 19:49   ` Raghavendra Rao Ananta
2022-01-08  5:40   ` Reiji Watanabe [this message]
2022-01-08  5:40     ` Reiji Watanabe
2022-01-08  5:40     ` Reiji Watanabe
2022-01-10 23:40     ` Raghavendra Rao Ananta
2022-01-10 23:40       ` Raghavendra Rao Ananta
2022-01-10 23:40       ` Raghavendra Rao Ananta
2022-01-11  4:33       ` Reiji Watanabe
2022-01-11  4:33         ` Reiji Watanabe
2022-01-11  4:33         ` Reiji Watanabe
2022-01-04 19:49 ` [RFC PATCH v3 04/11] KVM: arm64: Setup a framework for hypercall bitmap firmware registers Raghavendra Rao Ananta
2022-01-04 19:49   ` Raghavendra Rao Ananta
2022-01-04 19:49   ` Raghavendra Rao Ananta
2022-01-10  6:28   ` Reiji Watanabe
2022-01-10  6:28     ` Reiji Watanabe
2022-01-10  6:28     ` Reiji Watanabe
2022-01-11  0:50     ` Raghavendra Rao Ananta
2022-01-11  0:50       ` Raghavendra Rao Ananta
2022-01-11  0:50       ` Raghavendra Rao Ananta
2022-01-12  5:11       ` Reiji Watanabe
2022-01-12  5:11         ` Reiji Watanabe
2022-01-12  5:11         ` Reiji Watanabe
2022-01-12 18:02         ` Raghavendra Rao Ananta
2022-01-12 18:02           ` Raghavendra Rao Ananta
2022-01-12 18:02           ` Raghavendra Rao Ananta
2022-01-14  6:23           ` Reiji Watanabe
2022-01-14  6:23             ` Reiji Watanabe
2022-01-14  6:23             ` Reiji Watanabe
2022-01-19  6:42   ` Jason Wang
2022-01-19  6:42     ` Jason Wang
2022-01-19  6:42     ` Jason Wang
2022-01-19 10:21     ` Marc Zyngier
2022-01-19 10:21       ` Marc Zyngier
2022-01-19 10:21       ` Marc Zyngier
2022-01-04 19:49 ` [RFC PATCH v3 05/11] KVM: arm64: Add standard hypervisor firmware register Raghavendra Rao Ananta
2022-01-04 19:49   ` Raghavendra Rao Ananta
2022-01-04 19:49   ` Raghavendra Rao Ananta
2022-01-04 19:49 ` [RFC PATCH v3 06/11] KVM: arm64: Add vendor " Raghavendra Rao Ananta
2022-01-04 19:49   ` Raghavendra Rao Ananta
2022-01-04 19:49   ` Raghavendra Rao Ananta
2022-01-04 19:49 ` [RFC PATCH v3 07/11] Docs: KVM: Add doc for the bitmap firmware registers Raghavendra Rao Ananta
2022-01-04 19:49   ` Raghavendra Rao Ananta
2022-01-04 19:49   ` Raghavendra Rao Ananta
2022-01-04 19:49 ` [RFC PATCH v3 08/11] Docs: KVM: Rename psci.rst to hypercalls.rst Raghavendra Rao Ananta
2022-01-04 19:49   ` Raghavendra Rao Ananta
2022-01-04 19:49   ` Raghavendra Rao Ananta
2022-01-04 19:49 ` [RFC PATCH v3 09/11] tools: Import ARM SMCCC definitions Raghavendra Rao Ananta
2022-01-04 19:49   ` Raghavendra Rao Ananta
2022-01-04 19:49   ` Raghavendra Rao Ananta
2022-01-04 19:49 ` [RFC PATCH v3 10/11] selftests: KVM: aarch64: Introduce hypercall ABI test Raghavendra Rao Ananta
2022-01-04 19:49   ` Raghavendra Rao Ananta
2022-01-04 19:49   ` Raghavendra Rao Ananta
2022-01-04 19:49 ` [RFC PATCH v3 11/11] selftests: KVM: aarch64: Add the bitmap firmware registers to get-reg-list Raghavendra Rao Ananta
2022-01-04 19:49   ` Raghavendra Rao Ananta
2022-01-04 19:49   ` Raghavendra Rao Ananta

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='CAAeT=FxCCD+H1z8+gfyBZNeibfAUqUenZZe56Vj_3fCghJjy=Q@mail.gmail.com' \
    --to=reijiw@google.com \
    --cc=alexandru.elisei@arm.com \
    --cc=catalin.marinas@arm.com \
    --cc=drjones@redhat.com \
    --cc=james.morse@arm.com \
    --cc=jingzhangos@google.com \
    --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=oupton@google.com \
    --cc=pbonzini@redhat.com \
    --cc=pshier@google.com \
    --cc=rananta@google.com \
    --cc=ricarkol@google.com \
    --cc=suzuki.poulose@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.