Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.34 as permitted sender) client-ip=23.128.96.34;
MIME-Version: 1.0
References: <20230817003029.3073210-1-rananta@google.com> <20230817003029.3073210-3-rananta@google.com>
 <ZQSxgWWZ3YdNgeiC@linux.dev> <CAJHc60ytL7T73wwabD8C2+RkVgN3OQsNuBwdQKz+Qen9b_hq9A@mail.gmail.com>
 <ZQh/H5aMoqpYgVZg@linux.dev>
In-Reply-To: <ZQh/H5aMoqpYgVZg@linux.dev>
From:   Raghavendra Rao Ananta <rananta@google.com>
Date:   Mon, 18 Sep 2023 09:58:31 -0700
Message-ID: <CAJHc60wnYYxkav7+Lu3b0iPmyujz-cW-py5Ksg2+098fh5BtVQ@mail.gmail.com>
Subject: Re: [PATCH v5 02/12] KVM: arm64: PMU: Set the default PMU for the
 guest on vCPU reset
To:     Oliver Upton <oliver.upton@linux.dev>
Cc:     Marc Zyngier <maz@kernel.org>,
        Alexandru Elisei <alexandru.elisei@arm.com>,
        James Morse <james.morse@arm.com>,
        Suzuki K Poulose <suzuki.poulose@arm.com>,
        Paolo Bonzini <pbonzini@redhat.com>,
        Zenghui Yu <yuzenghui@huawei.com>,
        Shaoqin Huang <shahuang@redhat.com>,
        Jing Zhang <jingzhangos@google.com>,
        Reiji Watanabe <reijiw@google.com>,
        Colton Lewis <coltonlewis@google.com>,
        linux-arm-kernel@lists.infradead.org, kvmarm@lists.linux.dev,
        linux-kernel@vger.kernel.org, kvm@vger.kernel.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Precedence: bulk

On Mon, Sep 18, 2023 at 9:47=E2=80=AFAM Oliver Upton <oliver.upton@linux.de=
v> wrote:
>
> On Mon, Sep 18, 2023 at 09:41:02AM -0700, Raghavendra Rao Ananta wrote:
> > On Fri, Sep 15, 2023 at 12:33=E2=80=AFPM Oliver Upton <oliver.upton@lin=
ux.dev> wrote:
>
> [...]
>
> > > This would eliminate the possibility of returning ENODEV to userspace
> > > where we shouldn't.
> > >
> > I understand that we'll be breaking the API contract and userspace may
> > have to adapt to this change, but is it not acceptable to document and
> > return ENODEV, since ENODEV may offer more clarity to userspace as to
> > why the ioctl failed? In general, do we never extend the APIs?
>
> Yes, we extend the existing interfaces all the time, but we almost
> always require user opt in for user-visible changes in behavior. Look at
> the way arm64_check_features() is handled -- we hide the 'detailed'
> error and return EINVAL due to UAPI.
>
Got it. Let's return EINVAL then. Thanks!

- Raghavendra
> --
> Thanks,
> Oliver