Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) client-ip=2620:137:e000::1:18;
MIME-Version: 1.0
References: <20220412195846.3692374-1-zhanwei@google.com> <YnmqgFkhqWklrQIw@google.com>
 <CAN86XOYNpzEUN0aL9g=_GQFz5zdXX9Pvcs_TDmBVyJZDTfXREg@mail.gmail.com>
 <YnwRld0aH8489+XQ@google.com> <CAN86XOZdW7aZXhSU2=gP5TrRQc8wLmtTQui0J2kwhchp2pnbeQ@mail.gmail.com>
In-Reply-To: <CAN86XOZdW7aZXhSU2=gP5TrRQc8wLmtTQui0J2kwhchp2pnbeQ@mail.gmail.com>
From:   Suleiman Souhlal <suleiman@google.com>
Date:   Wed, 18 May 2022 13:27:30 +0900
Message-ID: <CABCjUKCCc2irAnJrGWfKAnXJj-pb=YNL4F0uAEr-c0LMX22_hw@mail.gmail.com>
Subject: Re: [PATCH 0/2] KVM: x86: Fix incorrect VM-exit profiling
To:     Wei Zhang <zhanwei@google.com>
Cc:     Sean Christopherson <seanjc@google.com>,
        Sangwhan Moon <sxm@google.com>, Ingo Molnar <mingo@redhat.com>,
        Paolo Bonzini <pbonzini@redhat.com>,
        Vitaly Kuznetsov <vkuznets@redhat.com>,
        Wanpeng Li <wanpengli@tencent.com>,
        Jim Mattson <jmattson@google.com>,
        Joerg Roedel <joro@8bytes.org>, kvm@vger.kernel.org,
        Linux Kernel <linux-kernel@vger.kernel.org>,
        Jing Zhang <jingzhangos@google.com>,
        David Matlack <dmatlack@google.com>
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

On Tue, May 17, 2022 at 4:30 AM Wei Zhang <zhanwei@google.com> wrote:
>
> > Please don't top-post.  From https://people.kernel.org/tglx/notes-about-netiquette:
>
> Ah, I didn't know this should be avoided. Thanks for the info!
>
> > My preference would be to find a more complete, KVM-specific solution.  The
> > profiling stuff seems like it's a dead end, i.e. will always be flawed in some
> > way.  If this cleanup didn't require a new hypercall then I wouldn't care, but
> > I don't love having to extend KVM's guest/host ABI for something that ideally
> > will become obsolete sooner than later.
>
> I also feel that adding a new hypercall is too much here. A
> KVM-specific solution is definitely better, and the eBPF based
> approach you mentioned sounds like the ultimate solution (at least for
> inspecting exit reasons).
>
> +Suleiman What do you think? The on-going work Sean described sounds
> promising, perhaps we should put this patch aside for the time being.

I'm ok with that.
That said, the advantage of the current solution is that it already
exists and is very easy to use, by anyone, without having to write any
code. The proposed solution doesn't sound like it will be as easy.

Regarding the earlier question about wanting to know which
instructions trigger exits, most times I've needed to get exit
profiles, I actually wanted to know where the guest was at the time of
the exit, regardless of who triggered the exit.

-- Suleiman