On Mon, May 31, 2021 at 12:33:39PM +0200, Andrew Jones wrote:
> v3:
> - Took Ricardo's suggestions in order to avoid needing to update
>prepare_vcpu_init, finalize_vcpu, and check_supported when adding
>new register sublists by better associating the sublists with their
>vcpu feature b
Hi Andrew,
On Tue, 22 Jun 2021 08:07:32 +0100,
Andrew Jones wrote:
>
> On Mon, May 31, 2021 at 12:33:39PM +0200, Andrew Jones wrote:
> > v3:
> > - Took Ricardo's suggestions in order to avoid needing to update
> >prepare_vcpu_init, finalize_vcpu, and check_supported when adding
> >new r
On Tue, Jun 22, 2021 at 08:32:51AM +0100, Marc Zyngier wrote:
> Hi Andrew,
>
> On Tue, 22 Jun 2021 08:07:32 +0100,
> Andrew Jones wrote:
> >
> > On Mon, May 31, 2021 at 12:33:39PM +0200, Andrew Jones wrote:
> > > v3:
> > > - Took Ricardo's suggestions in order to avoid needing to update
> > >
On Mon, 31 May 2021 12:33:39 +0200, Andrew Jones wrote:
> v3:
> - Took Ricardo's suggestions in order to avoid needing to update
>prepare_vcpu_init, finalize_vcpu, and check_supported when adding
>new register sublists by better associating the sublists with their
>vcpu feature bits an
Hi Andre,
I follow the document
https://git.linaro.org/landing-teams/working/arm/arm-reference-platforms.git/about/docs/basefvp/user-guide.rst,
and I build a Linux-on-FVP environment successfully. However, I still cannot
boot KVM, the details are as follows:
1.I make sure that two configur
On Tue, 22 Jun 2021 09:07:51 +0100,
Fuad Tabba wrote:
>
> Hi,
>
> On Mon, Jun 21, 2021 at 12:18 PM Steven Price wrote:
> >
> > It's now safe for the VMM to enable MTE in a guest, so expose the
> > capability to user space.
> >
> > Reviewed-by: Catalin Marinas
> > Signed-off-by: Steven Price
>
On Tue, 22 Jun 2021 02:33:44 +
胤桦 陈 wrote:
Hi,
> I follow the document
> https://git.linaro.org/landing-teams/working/arm/arm-reference-platforms.git/about/docs/basefvp/user-guide.rst,
sorry for that ;-)
> and I build a Linux-on-FVP environment successfully. However, I still cannot
> boo
Hi Fuad,
On Tue, 22 Jun 2021 09:56:22 +0100,
Fuad Tabba wrote:
>
> Hi,
>
>
> On Mon, Jun 21, 2021 at 12:18 PM Steven Price wrote:
> >
> > The VMM may not wish to have it's own mapping of guest memory mapped
> > with PROT_MTE because this causes problems if the VMM has tag checking
> > enabled
On Tue, 22 Jun 2021 10:42:42 +0100,
Fuad Tabba wrote:
>
> Hi,
>
>
> On Mon, Jun 21, 2021 at 12:18 PM Steven Price wrote:
> >
> > A new capability (KVM_CAP_ARM_MTE) identifies that the kernel supports
> > granting a guest access to the tags, and provides a mechanism for the
> > VMM to enable it
On Mon, 21 Jun 2021 18:00:20 +0100,
Fuad Tabba wrote:
>
> Hi,
>
> On Mon, Jun 21, 2021 at 12:18 PM Steven Price wrote:
> >
> > Add a new VM feature 'KVM_ARM_CAP_MTE' which enables memory tagging
> > for a VM. This will expose the feature to the guest and automatically
> > tag memory pages touch
Hi,
On Mon, Jun 21, 2021 at 12:18 PM Steven Price wrote:
>
> It's now safe for the VMM to enable MTE in a guest, so expose the
> capability to user space.
>
> Reviewed-by: Catalin Marinas
> Signed-off-by: Steven Price
> ---
> arch/arm64/kvm/arm.c | 9 +
> arch/arm64/kvm/reset.c
Hi,
On Mon, Jun 21, 2021 at 12:18 PM Steven Price wrote:
>
> The VMM may not wish to have it's own mapping of guest memory mapped
> with PROT_MTE because this causes problems if the VMM has tag checking
> enabled (the guest controls the tags in physical RAM and it's unlikely
> the tags are corre
Hi,
On Mon, Jun 21, 2021 at 12:18 PM Steven Price wrote:
>
> A new capability (KVM_CAP_ARM_MTE) identifies that the kernel supports
> granting a guest access to the tags, and provides a mechanism for the
> VMM to enable it.
>
> A new ioctl (KVM_ARM_MTE_COPY_TAGS) provides a simple way for a VMM
Hi,
> diff --git a/arch/arm64/include/asm/kvm_mte.h
> b/arch/arm64/include/asm/kvm_mte.h
> new file mode 100644
> index ..88dd1199670b
> --- /dev/null
> +++ b/arch/arm64/include/asm/kvm_mte.h
> @@ -0,0 +1,66 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +/*
> + * Copyright (C) 2020-2
On Mon, 21 Jun 2021 12:17:10 +0100, Steven Price wrote:
> This series adds support for using the Arm Memory Tagging Extensions
> (MTE) in a KVM guest.
>
> Changes since v16[1]:
>
> - Dropped the first patch ("Handle race when synchronising tags") as
>it's not KVM specific and by restricting
Hi Marc,
On Tue, Jun 22, 2021 at 11:35 AM Marc Zyngier wrote:
>
> On Tue, 22 Jun 2021 10:42:42 +0100,
> Fuad Tabba wrote:
> >
> > Hi,
> >
> >
> > On Mon, Jun 21, 2021 at 12:18 PM Steven Price wrote:
> > >
> > > A new capability (KVM_CAP_ARM_MTE) identifies that the kernel supports
> > > grantin
Hi Marc,
On Tue, Jun 22, 2021 at 11:25 AM Marc Zyngier wrote:
>
> Hi Fuad,
>
> On Tue, 22 Jun 2021 09:56:22 +0100,
> Fuad Tabba wrote:
> >
> > Hi,
> >
> >
> > On Mon, Jun 21, 2021 at 12:18 PM Steven Price wrote:
> > >
> > > The VMM may not wish to have it's own mapping of guest memory mapped
>
From: Like Xu
For "struct perf_guest_info_callbacks", the two fields "is_in_guest"
and "is_user_mode" are replaced with a new multiplexed member named
"state", and the "get_guest_ip" field will be renamed to "get_ip".
For arm64, xen and kvm/x86, the application of DEFINE_STATIC_CALL_RET0
could m
From: Like Xu
For "struct perf_guest_info_callbacks", the two fields "is_in_guest"
and "is_user_mode" are replaced with a new multiplexed member named
"state", and the "get_guest_ip" field will be renamed to "get_ip".
For arm64, xen and kvm/x86, the application of DEFINE_STATIC_CALL_RET0
could m
Hi Marc,
On 6/1/21 11:39 AM, Marc Zyngier wrote:
> This is a new version of the series previously posted at [3], reworking
> the vGIC and timer code to cope with the M1 braindead^Wamusing nature.
>
> Hardly any change this time around, mostly rebased on top of upstream
> now that the dependencies
Hi Alex,
On Tue, 22 Jun 2021 16:39:11 +0100,
Alexandru Elisei wrote:
>
> Hi Marc,
>
> On 6/1/21 11:39 AM, Marc Zyngier wrote:
> > This is a new version of the series previously posted at [3], reworking
> > the vGIC and timer code to cope with the M1 braindead^Wamusing nature.
> >
> > Hardly any
On Tue, 15 Jun 2021 15:45:03 +0100,
Alexandru Elisei wrote:
>
> Hi Marc,
>
> On 6/1/21 11:40 AM, Marc Zyngier wrote:
> > We already have the option to attach a callback to an interrupt
> > to retrieve its pending state. As we are planning to expand this
> > facility, move this callback into its
Hi Marc,
On 6/22/21 4:51 PM, Marc Zyngier wrote:
> Hi Alex,
>
> On Tue, 22 Jun 2021 16:39:11 +0100,
> Alexandru Elisei wrote:
>> Hi Marc,
>>
>> On 6/1/21 11:39 AM, Marc Zyngier wrote:
>>> This is a new version of the series previously posted at [3], reworking
>>> the vGIC and timer code to cope w
On Thu, 17 Jun 2021 15:58:31 +0100,
Alexandru Elisei wrote:
>
> Hi Marc,
>
> On 6/1/21 11:40 AM, Marc Zyngier wrote:
> > In order to deal with these systems that do not offer HW-based
> > deactivation of interrupts, let implement a SW-based approach:
>
> Nitpick, but shouldn't that be "let's"?
On Tue, 15 Jun 2021 15:26:02 +0100,
Alexandru Elisei wrote:
>
> Hi Marc,
>
> On 6/1/21 11:40 AM, Marc Zyngier wrote:
> > The vGIC, as architected by ARM, allows a virtual interrupt to
> > trigger the deactivation of a physical interrupt. This allows
> > the following interrupt to be delivered wi
On Tue, 22 Jun 2021 17:03:22 +0100,
Alexandru Elisei wrote:
>
> Hi Marc,
>
> On 6/22/21 4:51 PM, Marc Zyngier wrote:
> > Hi Alex,
> >
> > On Tue, 22 Jun 2021 16:39:11 +0100,
> > Alexandru Elisei wrote:
> >> Hi Marc,
> >>
> >> On 6/1/21 11:39 AM, Marc Zyngier wrote:
> >>> This is a new version o
On 6/22/21 5:38 AM, Zhu Lingshan wrote:
> -static int xen_is_user_mode(void)
> -{
> - const struct xen_pmu_data *xenpmu_data = get_xenpmu_data();
> + state |= PERF_GUEST_ACTIVE;
>
> - if (!xenpmu_data) {
> - pr_warn_once("%s: pmudata not initialized\n", __func__);
> -
27 matches
Mail list logo
