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: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <942ec747-04f6-4fd6-abcd-eea60c3ba041@yandex-team.ru>
Date: Mon, 30 Sep 2024 17:29:10 +0300
From: Denis Plotnikov <den-plotnikov@...dex-team.ru>
To: Sean Christopherson <seanjc@...gle.com>
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 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@...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.

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.

Thanks for the answers!

Best,
Denis

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ