From mboxrd@z Thu Jan 1 00:00:00 1970 From: Fabiano Rosas Date: Wed, 01 Sep 2021 14:23:08 +0000 Subject: Re: [PATCH kernel] KVM: PPC: Book3S HV: Make unique debugfs nodename Message-Id: <87lf4gv0hf.fsf@linux.ibm.com> List-Id: References: <20210707041344.3803554-1-aik@ozlabs.ru> <87pmubu306.fsf@linux.ibm.com> <2fe01488-5a9b-785e-7c05-1d527dead18d@ozlabs.ru> In-Reply-To: <2fe01488-5a9b-785e-7c05-1d527dead18d@ozlabs.ru> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit To: Alexey Kardashevskiy , Michael Ellerman Cc: linux-kernel@vger.kernel.org, kvm-ppc@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, Paul Mackerras Alexey Kardashevskiy writes: > On 24/08/2021 18:37, Alexey Kardashevskiy wrote: >> >> >> On 18/08/2021 08:20, Fabiano Rosas wrote: >>> Alexey Kardashevskiy writes: >>> >>>> On 07/07/2021 14:13, Alexey Kardashevskiy wrote: >>> >>>> alternatively move this debugfs stuff under the platform-independent >>>> directory, how about that? >>> >>> That's a good idea. I only now realized we have two separate directories >>> for the same guest: >>> >>> $ ls /sys/kernel/debug/kvm/ | grep $pid >>> 19062-11 >>> vm19062 >>> >>> Looks like we would have to implement kvm_arch_create_vcpu_debugfs for >>> the vcpu information and add a similar hook for the vm. >> >> Something like that. From the git history, it looks like the ppc folder >> was added first and then the generic kvm folder was added but apparently >> they did not notice the ppc one due to natural reasons :) >> >> If you are not too busy, can you please merge the ppc one into the >> generic one and post the patch, so we won't need to fix these >> duplication warnings again? Thanks, > > > > Turns out it is not that straight forward as I thought as the common KVM > debugfs entry is created after PPC HV KVM created its own and there is > no obvious way to change the order (no "post init" hook in > kvmppc_ops). That is why I mentioned creating a hook similar to kvm_create_vcpu_debugfs in the common KVM code. kvm_create_vm_debugfs or something. Alternatively, maybe kvm_create_vm_debugfs could be moved earlier into kvm_create_vm, before kvm_arch_post_init_vm and we could move our code into kvm_arch_post_init_vm. > > Also, unlike the common KVM debugfs setup, we do not allocate structures > to support debugfs nodes so we do not leak anything to bother with a > mutex like 85cd39af14f4 did. > > So I'd stick to the original patch to reduce the noise in the dmesg, and > it also exposes lpid which I find rather useful for finding the right > partition scope tree in partition_tb. > > Michael? > > >> >> >> >>>>> --- >>>>>    arch/powerpc/kvm/book3s_hv.c | 2 +- >>>>>    1 file changed, 1 insertion(+), 1 deletion(-) >>>>> >>>>> diff --git a/arch/powerpc/kvm/book3s_hv.c >>>>> b/arch/powerpc/kvm/book3s_hv.c >>>>> index 1d1fcc290fca..0223ddc0eed0 100644 >>>>> --- a/arch/powerpc/kvm/book3s_hv.c >>>>> +++ b/arch/powerpc/kvm/book3s_hv.c >>>>> @@ -5227,7 +5227,7 @@ static int kvmppc_core_init_vm_hv(struct kvm >>>>> *kvm) >>>>>        /* >>>>>         * Create a debugfs directory for the VM >>>>>         */ >>>>> -    snprintf(buf, sizeof(buf), "vm%d", current->pid); >>>>> +    snprintf(buf, sizeof(buf), "vm%d-lp%ld", current->pid, lpid); >>>>>        kvm->arch.debugfs_dir = debugfs_create_dir(buf, >>>>> kvm_debugfs_dir); >>>>>        kvmppc_mmu_debugfs_init(kvm); >>>>>        if (radix_enabled()) >>>>> >>