From: Sean Christopherson <seanjc@google.com>
To: Denis Plotnikov <den-plotnikov@yandex-team.ru>
Cc: kvm@vger.kernel.org, pbonzini@redhat.com, yc-core@yandex-team.ru,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] kvm/debugfs: add file to get vcpu steal time statistics
Date: Mon, 30 Sep 2024 08:44:34 -0700 [thread overview]
Message-ID: <ZvrHYoAuu2AntQYb@google.com> (raw)
In-Reply-To: <942ec747-04f6-4fd6-abcd-eea60c3ba041@yandex-team.ru>
On Mon, Sep 30, 2024, Denis Plotnikov wrote:
>
>
> On 9/23/24 14:46, Sean Christopherson wrote:
> > On Mon, Sep 23, 2024, Denis Plotnikov wrote:
> > > On 9/22/24 11:04, Sean Christopherson wrote:
> > > > On Tue, Sep 17, 2024, Denis Plotnikov wrote:
> > > > > It's helpful to know whether some other host activity affects a virtual
> > > > > machine to estimate virtual machine quality of sevice.
> > > > > The fact of virtual machine affection from the host side can be obtained
> > > > > by reading "preemption_reported" counter via kvm entries of sysfs, but
> > > > > the exact vcpu waiting time isn't reported to the host.
> > > > > This patch adds this reporting.
> > > > >
> > > > > Signed-off-by: Denis Plotnikov <den-plotnikov@yandex-team.ru>
> > > > > ---
> > > > > arch/x86/include/asm/kvm_host.h | 1 +
> > > > > arch/x86/kvm/debugfs.c | 17 +++++++++++++++++
> > > >
> > > > Using debugfs is undesirable, as it's (a) not ABI and (b) not guaranteed to be
> > > > present as KVM (correctly) ignores debugfs setup errors.
> > > >
> > > > Using debugfs is also unnecessary. The total steal time is available in guest
> > > > memory, and by definition that memory is shared with the host. To query total
> > > > steal time from userspace, use MSR filtering to trap writes (and reflect writes
> > > > back into KVM) so that the GPA of the steal time structure is known, and then
> > > > simply read the actual steal time from guest memory as needed.
> > > Thanks for the reply!
> > > Just to clarify, by reading the actual steal time from guest memory do you
> > > mean by using some kind of new vcpu ioctl?
> >
> > No, I mean by using the host userspace VMA to read the memory.
>
> Oh, I think I got your idea. You mean
> using KVM_CAP_X86_MSR_FILTER which...
>
> "In combination with KVM_CAP_X86_USER_SPACE_MSR, this allows user space to
> trap and emulate MSRs ..."
>
> And then having guest's steal time struct valid address read the value from
> userspace VMM like qemu directly.
Yep, exactly!
next prev parent reply other threads:[~2024-09-30 15:44 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-09-17 11:20 [PATCH] kvm/debugfs: add file to get vcpu steal time statistics Denis Plotnikov
2024-09-22 8:04 ` Sean Christopherson
2024-09-23 9:32 ` Denis Plotnikov
2024-09-23 11:46 ` Sean Christopherson
2024-09-30 14:29 ` Denis Plotnikov
2024-09-30 15:44 ` Sean Christopherson [this message]
2024-11-05 12:43 ` Denis Plotnikov
2024-11-26 9:54 ` Denis Plotnikov
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=ZvrHYoAuu2AntQYb@google.com \
--to=seanjc@google.com \
--cc=den-plotnikov@yandex-team.ru \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=pbonzini@redhat.com \
--cc=yc-core@yandex-team.ru \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox