From: Marc Zyngier <maz@kernel.org>
To: Raghavendra Rao Ananta <rananta@google.com>
Cc: kvm@vger.kernel.org, Will Deacon <will@kernel.org>,
Catalin Marinas <catalin.marinas@arm.com>,
Peter Shier <pshier@google.com>,
linux-kernel@vger.kernel.org, Paolo Bonzini <pbonzini@redhat.com>,
kvmarm@lists.cs.columbia.edu,
linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH v7 0/9] KVM: arm64: Add support for hypercall services selection
Date: Tue, 03 May 2022 21:33:40 +0100 [thread overview]
Message-ID: <878rriicez.wl-maz@kernel.org> (raw)
In-Reply-To: <CAJHc60xp=UQT_CX0zoiSjAmkS8JSe+NB5Gr+F5mmybjJAWkUtQ@mail.gmail.com>
On Tue, 03 May 2022 19:49:13 +0100,
Raghavendra Rao Ananta <rananta@google.com> wrote:
>
> Hi Marc,
>
> On Tue, May 3, 2022 at 10:24 AM Marc Zyngier <maz@kernel.org> wrote:
> >
> > On Tue, 03 May 2022 00:38:44 +0100,
> > Raghavendra Rao Ananta <rananta@google.com> wrote:
> > >
> > > Hello,
> > >
> > > Continuing the discussion from [1], the series tries to add support
> > > for the userspace to elect the hypercall services that it wishes
> > > to expose to the guest, rather than the guest discovering them
> > > unconditionally. The idea employed by the series was taken from
> > > [1] as suggested by Marc Z.
> >
> > As it took some time to get there, and that there was still a bunch of
> > things to address, I've taken the liberty to apply my own fixes to the
> > series.
> >
> > Please have a look at [1], and let me know if you're OK with the
> > result. If you are, I'll merge the series for 5.19.
> >
> > Thanks,
> >
> > M.
> >
> Thank you for speeding up the process; appreciate it. However, the
> series's selftest patches have a dependency on Oliver's
> PSCI_SYSTEM_SUSPEND's selftest patches [1][2]. Can we pull them in
> too?
Urgh... I guess this is the time to set some ground rules:
- Please don't introduce dependencies between series, that's
unmanageable. I really need to see each series independently, and if
there is a merge conflict, that's my job to fix (and I don't really
mind).
- If there is a dependency between series, please post a version of
the required patches as a prefix to your series, assuming this
prefix is itself standalone. If it isn't, then something really is
wrong, and the series should be resplit.
- You also should be basing your series on an *official* tag from
Linus' tree (preferably -rc1, -rc2 or -rc3), and not something
random like any odd commit from the KVM tree (I had conflicts while
applying this on -rc3, probably due to the non-advertised dependency
on Oliver's series).
>
> aarch64/hypercalls.c: In function ‘guest_test_hvc’:
> aarch64/hypercalls.c:95:30: error: storage size of ‘res’ isn’t known
> 95 | struct arm_smccc_res res;
> | ^~~
> aarch64/hypercalls.c:103:17: warning: implicit declaration of function
> ‘smccc_hvc’ [-Wimplicit-function-declaration]
> 103 | smccc_hvc(hc_info->func_id, hc_info->arg1, 0,
> 0, 0, 0, 0, 0, &res);
> | ^~~~~~~~~
>
I've picked the two patches, which means they will most likely appear
twice in the history. In the future, please reach out so that we can
organise this better.
> Also, just a couple of readability nits in the fixed version:
>
> 1. Patch-2/9, hypercall.c:kvm_hvc_call_default_allowed(), in the
> 'default' case, do you think we should probably add a small comment
> that mentions we are checking for func_id in the PSCI range?
Dumped a one-liner there.
> 2. Patch-2/9, arm_hypercall.h, clear all the macros in this patch
> itself instead of doing it in increments (unless there's some reason
> that I'm missing)?
Ah, rebasing leftovers, now gone.
I've pushed an updated branch again, please have a look.
M.
--
Without deviation from the norm, progress is not possible.
_______________________________________________
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: Raghavendra Rao Ananta <rananta@google.com>
Cc: 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>,
Reiji Watanabe <reijiw@google.com>,
Jing Zhang <jingzhangos@google.com>,
linux-arm-kernel@lists.infradead.org,
kvmarm@lists.cs.columbia.edu, linux-kernel@vger.kernel.org,
kvm@vger.kernel.org
Subject: Re: [PATCH v7 0/9] KVM: arm64: Add support for hypercall services selection
Date: Tue, 03 May 2022 21:33:40 +0100 [thread overview]
Message-ID: <878rriicez.wl-maz@kernel.org> (raw)
In-Reply-To: <CAJHc60xp=UQT_CX0zoiSjAmkS8JSe+NB5Gr+F5mmybjJAWkUtQ@mail.gmail.com>
On Tue, 03 May 2022 19:49:13 +0100,
Raghavendra Rao Ananta <rananta@google.com> wrote:
>
> Hi Marc,
>
> On Tue, May 3, 2022 at 10:24 AM Marc Zyngier <maz@kernel.org> wrote:
> >
> > On Tue, 03 May 2022 00:38:44 +0100,
> > Raghavendra Rao Ananta <rananta@google.com> wrote:
> > >
> > > Hello,
> > >
> > > Continuing the discussion from [1], the series tries to add support
> > > for the userspace to elect the hypercall services that it wishes
> > > to expose to the guest, rather than the guest discovering them
> > > unconditionally. The idea employed by the series was taken from
> > > [1] as suggested by Marc Z.
> >
> > As it took some time to get there, and that there was still a bunch of
> > things to address, I've taken the liberty to apply my own fixes to the
> > series.
> >
> > Please have a look at [1], and let me know if you're OK with the
> > result. If you are, I'll merge the series for 5.19.
> >
> > Thanks,
> >
> > M.
> >
> Thank you for speeding up the process; appreciate it. However, the
> series's selftest patches have a dependency on Oliver's
> PSCI_SYSTEM_SUSPEND's selftest patches [1][2]. Can we pull them in
> too?
Urgh... I guess this is the time to set some ground rules:
- Please don't introduce dependencies between series, that's
unmanageable. I really need to see each series independently, and if
there is a merge conflict, that's my job to fix (and I don't really
mind).
- If there is a dependency between series, please post a version of
the required patches as a prefix to your series, assuming this
prefix is itself standalone. If it isn't, then something really is
wrong, and the series should be resplit.
- You also should be basing your series on an *official* tag from
Linus' tree (preferably -rc1, -rc2 or -rc3), and not something
random like any odd commit from the KVM tree (I had conflicts while
applying this on -rc3, probably due to the non-advertised dependency
on Oliver's series).
>
> aarch64/hypercalls.c: In function ‘guest_test_hvc’:
> aarch64/hypercalls.c:95:30: error: storage size of ‘res’ isn’t known
> 95 | struct arm_smccc_res res;
> | ^~~
> aarch64/hypercalls.c:103:17: warning: implicit declaration of function
> ‘smccc_hvc’ [-Wimplicit-function-declaration]
> 103 | smccc_hvc(hc_info->func_id, hc_info->arg1, 0,
> 0, 0, 0, 0, 0, &res);
> | ^~~~~~~~~
>
I've picked the two patches, which means they will most likely appear
twice in the history. In the future, please reach out so that we can
organise this better.
> Also, just a couple of readability nits in the fixed version:
>
> 1. Patch-2/9, hypercall.c:kvm_hvc_call_default_allowed(), in the
> 'default' case, do you think we should probably add a small comment
> that mentions we are checking for func_id in the PSCI range?
Dumped a one-liner there.
> 2. Patch-2/9, arm_hypercall.h, clear all the macros in this patch
> itself instead of doing it in increments (unless there's some reason
> that I'm missing)?
Ah, rebasing leftovers, now gone.
I've pushed an updated branch again, please have a look.
M.
--
Without deviation from the norm, progress is not possible.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
WARNING: multiple messages have this Message-ID (diff)
From: Marc Zyngier <maz@kernel.org>
To: Raghavendra Rao Ananta <rananta@google.com>
Cc: 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>,
Reiji Watanabe <reijiw@google.com>,
Jing Zhang <jingzhangos@google.com>,
linux-arm-kernel@lists.infradead.org,
kvmarm@lists.cs.columbia.edu, linux-kernel@vger.kernel.org,
kvm@vger.kernel.org
Subject: Re: [PATCH v7 0/9] KVM: arm64: Add support for hypercall services selection
Date: Tue, 03 May 2022 21:33:40 +0100 [thread overview]
Message-ID: <878rriicez.wl-maz@kernel.org> (raw)
In-Reply-To: <CAJHc60xp=UQT_CX0zoiSjAmkS8JSe+NB5Gr+F5mmybjJAWkUtQ@mail.gmail.com>
On Tue, 03 May 2022 19:49:13 +0100,
Raghavendra Rao Ananta <rananta@google.com> wrote:
>
> Hi Marc,
>
> On Tue, May 3, 2022 at 10:24 AM Marc Zyngier <maz@kernel.org> wrote:
> >
> > On Tue, 03 May 2022 00:38:44 +0100,
> > Raghavendra Rao Ananta <rananta@google.com> wrote:
> > >
> > > Hello,
> > >
> > > Continuing the discussion from [1], the series tries to add support
> > > for the userspace to elect the hypercall services that it wishes
> > > to expose to the guest, rather than the guest discovering them
> > > unconditionally. The idea employed by the series was taken from
> > > [1] as suggested by Marc Z.
> >
> > As it took some time to get there, and that there was still a bunch of
> > things to address, I've taken the liberty to apply my own fixes to the
> > series.
> >
> > Please have a look at [1], and let me know if you're OK with the
> > result. If you are, I'll merge the series for 5.19.
> >
> > Thanks,
> >
> > M.
> >
> Thank you for speeding up the process; appreciate it. However, the
> series's selftest patches have a dependency on Oliver's
> PSCI_SYSTEM_SUSPEND's selftest patches [1][2]. Can we pull them in
> too?
Urgh... I guess this is the time to set some ground rules:
- Please don't introduce dependencies between series, that's
unmanageable. I really need to see each series independently, and if
there is a merge conflict, that's my job to fix (and I don't really
mind).
- If there is a dependency between series, please post a version of
the required patches as a prefix to your series, assuming this
prefix is itself standalone. If it isn't, then something really is
wrong, and the series should be resplit.
- You also should be basing your series on an *official* tag from
Linus' tree (preferably -rc1, -rc2 or -rc3), and not something
random like any odd commit from the KVM tree (I had conflicts while
applying this on -rc3, probably due to the non-advertised dependency
on Oliver's series).
>
> aarch64/hypercalls.c: In function ‘guest_test_hvc’:
> aarch64/hypercalls.c:95:30: error: storage size of ‘res’ isn’t known
> 95 | struct arm_smccc_res res;
> | ^~~
> aarch64/hypercalls.c:103:17: warning: implicit declaration of function
> ‘smccc_hvc’ [-Wimplicit-function-declaration]
> 103 | smccc_hvc(hc_info->func_id, hc_info->arg1, 0,
> 0, 0, 0, 0, 0, &res);
> | ^~~~~~~~~
>
I've picked the two patches, which means they will most likely appear
twice in the history. In the future, please reach out so that we can
organise this better.
> Also, just a couple of readability nits in the fixed version:
>
> 1. Patch-2/9, hypercall.c:kvm_hvc_call_default_allowed(), in the
> 'default' case, do you think we should probably add a small comment
> that mentions we are checking for func_id in the PSCI range?
Dumped a one-liner there.
> 2. Patch-2/9, arm_hypercall.h, clear all the macros in this patch
> itself instead of doing it in increments (unless there's some reason
> that I'm missing)?
Ah, rebasing leftovers, now gone.
I've pushed an updated branch again, please have a look.
M.
--
Without deviation from the norm, progress is not possible.
next prev parent reply other threads:[~2022-05-03 20:33 UTC|newest]
Thread overview: 63+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-05-02 23:38 [PATCH v7 0/9] KVM: arm64: Add support for hypercall services selection Raghavendra Rao Ananta
2022-05-02 23:38 ` Raghavendra Rao Ananta
2022-05-02 23:38 ` Raghavendra Rao Ananta
2022-05-02 23:38 ` [PATCH v7 1/9] KVM: arm64: Factor out firmware register handling from psci.c Raghavendra Rao Ananta
2022-05-02 23:38 ` Raghavendra Rao Ananta
2022-05-02 23:38 ` Raghavendra Rao Ananta
2022-05-03 10:35 ` Marc Zyngier
2022-05-03 10:35 ` Marc Zyngier
2022-05-03 10:35 ` Marc Zyngier
2022-05-02 23:38 ` [PATCH v7 2/9] KVM: arm64: Setup a framework for hypercall bitmap firmware registers Raghavendra Rao Ananta
2022-05-02 23:38 ` Raghavendra Rao Ananta
2022-05-02 23:38 ` Raghavendra Rao Ananta
2022-05-03 13:28 ` Marc Zyngier
2022-05-03 13:28 ` Marc Zyngier
2022-05-03 13:28 ` Marc Zyngier
2022-05-02 23:38 ` [PATCH v7 3/9] KVM: arm64: Add standard hypervisor firmware register Raghavendra Rao Ananta
2022-05-02 23:38 ` Raghavendra Rao Ananta
2022-05-02 23:38 ` Raghavendra Rao Ananta
2022-05-02 23:38 ` [PATCH v7 4/9] KVM: arm64: Add vendor " Raghavendra Rao Ananta
2022-05-02 23:38 ` Raghavendra Rao Ananta
2022-05-02 23:38 ` Raghavendra Rao Ananta
2022-05-02 23:38 ` [PATCH v7 5/9] Docs: KVM: Rename psci.rst to hypercalls.rst Raghavendra Rao Ananta
2022-05-02 23:38 ` Raghavendra Rao Ananta
2022-05-02 23:38 ` Raghavendra Rao Ananta
2022-05-02 23:38 ` [PATCH v7 6/9] Docs: KVM: Add doc for the bitmap firmware registers Raghavendra Rao Ananta
2022-05-02 23:38 ` Raghavendra Rao Ananta
2022-05-02 23:38 ` Raghavendra Rao Ananta
2022-05-03 17:14 ` Marc Zyngier
2022-05-03 17:14 ` Marc Zyngier
2022-05-03 17:14 ` Marc Zyngier
2022-05-02 23:38 ` [PATCH v7 7/9] tools: Import ARM SMCCC definitions Raghavendra Rao Ananta
2022-05-02 23:38 ` Raghavendra Rao Ananta
2022-05-02 23:38 ` Raghavendra Rao Ananta
2022-05-02 23:38 ` [PATCH v7 8/9] selftests: KVM: aarch64: Introduce hypercall ABI test Raghavendra Rao Ananta
2022-05-02 23:38 ` Raghavendra Rao Ananta
2022-05-02 23:38 ` Raghavendra Rao Ananta
2022-05-02 23:38 ` [PATCH v7 9/9] selftests: KVM: aarch64: Add the bitmap firmware registers to get-reg-list Raghavendra Rao Ananta
2022-05-02 23:38 ` Raghavendra Rao Ananta
2022-05-02 23:38 ` Raghavendra Rao Ananta
2022-05-03 17:24 ` [PATCH v7 0/9] KVM: arm64: Add support for hypercall services selection Marc Zyngier
2022-05-03 17:24 ` Marc Zyngier
2022-05-03 17:24 ` Marc Zyngier
2022-05-03 18:49 ` Raghavendra Rao Ananta
2022-05-03 18:49 ` Raghavendra Rao Ananta
2022-05-03 18:49 ` Raghavendra Rao Ananta
2022-05-03 20:33 ` Marc Zyngier [this message]
2022-05-03 20:33 ` Marc Zyngier
2022-05-03 20:33 ` Marc Zyngier
2022-05-03 21:09 ` Raghavendra Rao Ananta
2022-05-03 21:09 ` Raghavendra Rao Ananta
2022-05-03 21:09 ` Raghavendra Rao Ananta
2022-05-16 16:44 ` Marc Zyngier
2022-05-16 16:44 ` Marc Zyngier
2022-05-16 16:44 ` Marc Zyngier
2022-05-16 18:30 ` Raghavendra Rao Ananta
2022-05-16 18:30 ` Raghavendra Rao Ananta
2022-05-16 18:30 ` Raghavendra Rao Ananta
2022-05-04 3:39 ` Oliver Upton
2022-05-04 3:39 ` Oliver Upton
2022-05-04 3:39 ` Oliver Upton
2022-05-04 12:01 ` Marc Zyngier
2022-05-04 12:01 ` Marc Zyngier
2022-05-04 12:01 ` 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=878rriicez.wl-maz@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-kernel@vger.kernel.org \
--cc=pbonzini@redhat.com \
--cc=pshier@google.com \
--cc=rananta@google.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.