| Message ID | 20180119190422.6591-1-yamato@redhat.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On 01/19/2018 08:04 PM, Masatake YAMATO wrote: > All d-entries for vcpu have the same, "anon_inode:kvm-vcpu". That means > it is impossible to know the mapping between fds for vcpu and vcpu > from userland. > > # LC_ALL=C ls -l /proc/617/fd | grep vcpu > lrwx------. 1 qemu qemu 64 Jan 7 16:50 18 -> anon_inode:kvm-vcpu > lrwx------. 1 qemu qemu 64 Jan 7 16:50 19 -> anon_inode:kvm-vcpu > > It is also impossible to know the mapping between vma for kvm_run > structure and vcpu from userland. > > # LC_ALL=C grep vcpu /proc/617/maps > 7f9d842d0000-7f9d842d3000 rw-s 00000000 00:0d 20393 anon_inode:kvm-vcpu > 7f9d842d3000-7f9d842d6000 rw-s 00000000 00:0d 20393 anon_inode:kvm-vcpu > > This change adds vcpu id to d-entries for vcpu. With this change > you can get the following output: > > # LC_ALL=C ls -l /proc/617/fd | grep vcpu > lrwx------. 1 qemu qemu 64 Jan 7 16:50 18 -> anon_inode:kvm-vcpu:0 > lrwx------. 1 qemu qemu 64 Jan 7 16:50 19 -> anon_inode:kvm-vcpu:1 > > # LC_ALL=C grep vcpu /proc/617/maps > 7f9d842d0000-7f9d842d3000 rw-s 00000000 00:0d 20393 anon_inode:kvm-vcpu:0 > 7f9d842d3000-7f9d842d6000 rw-s 00000000 00:0d 20393 anon_inode:kvm-vcpu:1 > > With the mappings known from the output, a tool like strace can report more details > of qemu-kvm process activities. Here is the strace output of my local prototype: > > # ./strace -KK -f -p 617 2>&1 | grep 'KVM_RUN\| K' > ... > [pid 664] ioctl(18, KVM_RUN, 0) = 0 (KVM_EXIT_MMIO) > K ready_for_interrupt_injection=1, if_flag=0, flags=0, cr8=0000000000000000, apic_base=0x000000fee00d00 > K phys_addr=0, len=1634035803, [33, 0, 0, 0, 0, 0, 0, 0], is_write=112 > [pid 664] ioctl(18, KVM_RUN, 0) = 0 (KVM_EXIT_MMIO) > K ready_for_interrupt_injection=1, if_flag=1, flags=0, cr8=0000000000000000, apic_base=0x000000fee00d00 > K phys_addr=0, len=1634035803, [33, 0, 0, 0, 0, 0, 0, 0], is_write=112 > ... > > Signed-off-by: Masatake YAMATO <yamato@redhat.com> I like that idea a lot. In debugging sessions I often lookup /proc/*/fd/*. Acked-by: Christian Borntraeger <borntraeger@de.ibm.com> > --- > virt/kvm/kvm_main.c | 5 ++++- > 1 file changed, 4 insertions(+), 1 deletion(-) > > diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c > index 210bf820385a..e1e119865247 100644 > --- a/virt/kvm/kvm_main.c > +++ b/virt/kvm/kvm_main.c > @@ -2418,7 +2418,10 @@ static struct file_operations kvm_vcpu_fops = { > */ > static int create_vcpu_fd(struct kvm_vcpu *vcpu) > { > - return anon_inode_getfd("kvm-vcpu", &kvm_vcpu_fops, vcpu, O_RDWR | O_CLOEXEC); > + char name[8 + 1 + ITOA_MAX_LEN + 1]; > + > + snprintf(name, sizeof(name), "kvm-vcpu:%d", vcpu->vcpu_id); > + return anon_inode_getfd(name, &kvm_vcpu_fops, vcpu, O_RDWR | O_CLOEXEC); > } > > static int kvm_create_vcpu_debugfs(struct kvm_vcpu *vcpu) >
2018-01-20 04:04+0900, Masatake YAMATO: > All d-entries for vcpu have the same, "anon_inode:kvm-vcpu". That means > it is impossible to know the mapping between fds for vcpu and vcpu > from userland. > > # LC_ALL=C ls -l /proc/617/fd | grep vcpu > lrwx------. 1 qemu qemu 64 Jan 7 16:50 18 -> anon_inode:kvm-vcpu > lrwx------. 1 qemu qemu 64 Jan 7 16:50 19 -> anon_inode:kvm-vcpu > > It is also impossible to know the mapping between vma for kvm_run > structure and vcpu from userland. > > # LC_ALL=C grep vcpu /proc/617/maps > 7f9d842d0000-7f9d842d3000 rw-s 00000000 00:0d 20393 anon_inode:kvm-vcpu > 7f9d842d3000-7f9d842d6000 rw-s 00000000 00:0d 20393 anon_inode:kvm-vcpu > > This change adds vcpu id to d-entries for vcpu. With this change > you can get the following output: > > # LC_ALL=C ls -l /proc/617/fd | grep vcpu > lrwx------. 1 qemu qemu 64 Jan 7 16:50 18 -> anon_inode:kvm-vcpu:0 > lrwx------. 1 qemu qemu 64 Jan 7 16:50 19 -> anon_inode:kvm-vcpu:1 > > # LC_ALL=C grep vcpu /proc/617/maps > 7f9d842d0000-7f9d842d3000 rw-s 00000000 00:0d 20393 anon_inode:kvm-vcpu:0 > 7f9d842d3000-7f9d842d6000 rw-s 00000000 00:0d 20393 anon_inode:kvm-vcpu:1 > > With the mappings known from the output, a tool like strace can report more details > of qemu-kvm process activities. Here is the strace output of my local prototype: > > # ./strace -KK -f -p 617 2>&1 | grep 'KVM_RUN\| K' > ... > [pid 664] ioctl(18, KVM_RUN, 0) = 0 (KVM_EXIT_MMIO) > K ready_for_interrupt_injection=1, if_flag=0, flags=0, cr8=0000000000000000, apic_base=0x000000fee00d00 > K phys_addr=0, len=1634035803, [33, 0, 0, 0, 0, 0, 0, 0], is_write=112 > [pid 664] ioctl(18, KVM_RUN, 0) = 0 (KVM_EXIT_MMIO) > K ready_for_interrupt_injection=1, if_flag=1, flags=0, cr8=0000000000000000, apic_base=0x000000fee00d00 > K phys_addr=0, len=1634035803, [33, 0, 0, 0, 0, 0, 0, 0], is_write=112 > ... > > Signed-off-by: Masatake YAMATO <yamato@redhat.com> > --- Queued, thanks.
diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c index 210bf820385a..e1e119865247 100644 --- a/virt/kvm/kvm_main.c +++ b/virt/kvm/kvm_main.c @@ -2418,7 +2418,10 @@ static struct file_operations kvm_vcpu_fops = { */ static int create_vcpu_fd(struct kvm_vcpu *vcpu) { - return anon_inode_getfd("kvm-vcpu", &kvm_vcpu_fops, vcpu, O_RDWR | O_CLOEXEC); + char name[8 + 1 + ITOA_MAX_LEN + 1]; + + snprintf(name, sizeof(name), "kvm-vcpu:%d", vcpu->vcpu_id); + return anon_inode_getfd(name, &kvm_vcpu_fops, vcpu, O_RDWR | O_CLOEXEC); } static int kvm_create_vcpu_debugfs(struct kvm_vcpu *vcpu)
All d-entries for vcpu have the same, "anon_inode:kvm-vcpu". That means it is impossible to know the mapping between fds for vcpu and vcpu from userland. # LC_ALL=C ls -l /proc/617/fd | grep vcpu lrwx------. 1 qemu qemu 64 Jan 7 16:50 18 -> anon_inode:kvm-vcpu lrwx------. 1 qemu qemu 64 Jan 7 16:50 19 -> anon_inode:kvm-vcpu It is also impossible to know the mapping between vma for kvm_run structure and vcpu from userland. # LC_ALL=C grep vcpu /proc/617/maps 7f9d842d0000-7f9d842d3000 rw-s 00000000 00:0d 20393 anon_inode:kvm-vcpu 7f9d842d3000-7f9d842d6000 rw-s 00000000 00:0d 20393 anon_inode:kvm-vcpu This change adds vcpu id to d-entries for vcpu. With this change you can get the following output: # LC_ALL=C ls -l /proc/617/fd | grep vcpu lrwx------. 1 qemu qemu 64 Jan 7 16:50 18 -> anon_inode:kvm-vcpu:0 lrwx------. 1 qemu qemu 64 Jan 7 16:50 19 -> anon_inode:kvm-vcpu:1 # LC_ALL=C grep vcpu /proc/617/maps 7f9d842d0000-7f9d842d3000 rw-s 00000000 00:0d 20393 anon_inode:kvm-vcpu:0 7f9d842d3000-7f9d842d6000 rw-s 00000000 00:0d 20393 anon_inode:kvm-vcpu:1 With the mappings known from the output, a tool like strace can report more details of qemu-kvm process activities. Here is the strace output of my local prototype: # ./strace -KK -f -p 617 2>&1 | grep 'KVM_RUN\| K' ... [pid 664] ioctl(18, KVM_RUN, 0) = 0 (KVM_EXIT_MMIO) K ready_for_interrupt_injection=1, if_flag=0, flags=0, cr8=0000000000000000, apic_base=0x000000fee00d00 K phys_addr=0, len=1634035803, [33, 0, 0, 0, 0, 0, 0, 0], is_write=112 [pid 664] ioctl(18, KVM_RUN, 0) = 0 (KVM_EXIT_MMIO) K ready_for_interrupt_injection=1, if_flag=1, flags=0, cr8=0000000000000000, apic_base=0x000000fee00d00 K phys_addr=0, len=1634035803, [33, 0, 0, 0, 0, 0, 0, 0], is_write=112 ... Signed-off-by: Masatake YAMATO <yamato@redhat.com> --- virt/kvm/kvm_main.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-)