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@xxxxxxxxxxxxxx> > > > > > --- > > > > > 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!
