lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <ZvFVFulBrzHqj2SE@google.com>
Date: Mon, 23 Sep 2024 04:46:30 -0700
From: Sean Christopherson <seanjc@...gle.com>
To: Denis Plotnikov <den-plotnikov@...dex-team.ru>
Cc: kvm@...r.kernel.org, pbonzini@...hat.com, yc-core@...dex-team.ru, 
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] kvm/debugfs: add file to get vcpu steal time statistics

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@...dex-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.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ