[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <049c0f98-bd89-ee3c-7869-92972f2d7c31@amd.com>
Date: Mon, 26 Aug 2019 19:41:39 +0000
From: "Suthikulpanit, Suravee" <Suravee.Suthikulpanit@....com>
To: Alexander Graf <graf@...zon.com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"kvm@...r.kernel.org" <kvm@...r.kernel.org>
CC: "pbonzini@...hat.com" <pbonzini@...hat.com>,
"rkrcmar@...hat.com" <rkrcmar@...hat.com>,
"joro@...tes.org" <joro@...tes.org>,
"jschoenh@...zon.de" <jschoenh@...zon.de>,
"karahmed@...zon.de" <karahmed@...zon.de>,
"rimasluk@...zon.com" <rimasluk@...zon.com>,
"Grimm, Jon" <Jon.Grimm@....com>
Subject: Re: [PATCH v2 04/15] kvm: x86: Add per-VM APICv state debugfs
Alex,
On 8/19/2019 4:57 AM, Alexander Graf wrote:
>
>
> On 15.08.19 18:25, Suthikulpanit, Suravee wrote:
>> Currently, there is no way to tell whether APICv is active
>> on a particular VM. This often cause confusion since APICv
>> can be deactivated at runtime.
>>
>> Introduce a debugfs entry to report APICv state of a VM.
>> This creates a read-only file:
>>
>> /sys/kernel/debug/kvm/70860-14/apicv-state
>>
>> Signed-off-by: Suravee Suthikulpanit <suravee.suthikulpanit@....com>
>
> Shouldn't this first and foremost be a VM ioctl so that user space can inquire its own state?
>
>
> Alex
I introduce this mainly for debugging similar to how KVM is currently provides
some per-VCPU information:
/sys/kernel/debug/kvm/15957-14/vcpu0/
lapic_timer_advance_ns
tsc-offset
tsc-scaling-ratio
tsc-scaling-ratio-frac-bits
I'm not sure if this needs to be VM ioctl at this point. If this information is
useful for user-space tool to inquire via ioctl, we can also provide it.
Thanks,
Suravee
Powered by blists - more mailing lists