On 2018-01-25 04:29 AM, Stefan Hajnoczi wrote: > On Wed, Jan 24, 2018 at 10:56:26AM -0500, Geneviève Bastien wrote: >> Thanks for the hint, I didn't know about those. But the uevents are only >> for the host right? There is no specific value in debugfs for guest. > I'm not sure I understand the question. > > Uevent are emitted on the host. Given the PID field, it should be > possible to correlate them to a specific guest (e.g. by looking at > information from the user or VM management tools, or simply by looking > at /proc/$PID/cmdline for the QEMU -name argument that can be used to > identify guests on the host side). > > Stefan With the information from the host and those uevents, we can indeed easily figure out in our traces which processes are associated with a guest and get its command line and a lot more information. The missing piece is in the guest trace. For example, we have lttng traces taken on the guest and the host. We may have multiple guests and multiple hosts to trace. It's easy to know which traces are from hosts from the events, but which are from guests? And which guest trace goes with which of the kvm processes on which host? The guest trace contains no information that can be linked to the host. I was thinking that the guest could do a hypercall to the host after bootup to share some unique information, for instance its bootid, that the host could store somewhere. That information would be available in the traces so that we can easily associate the guest with its host process and the states of its virtual CPUs to that of the corresponding threads, and much more. I hope this describes our need a little better. Thanks, Geneviève (tahini on irc)
