Re: [RFC PATCH 00/11] Tracefs support for pKVM

[Vincent Donnefort <vdonnefort@google.com>]

On Tue, Aug 06, 2024 at 04:11:38PM -0400, Steven Rostedt wrote:
> 
> Hi Vincent,
> 
> Thanks for sending this!

And thanks for already having a look at it!

[..]

> > 2. Tracefs interface
> > --------------------
> > 
> > The interface is a hyp/ folder at the root of the tracefs mount point.
> > This folder is like an instance and you'll find there a subset of the
> > regular Tracefs user-space interface:
> > 
> >   hyp/
> 
> Hmm, do we really need to shorten it? Why not just call it "hypervisor". I
> mean tab completion helps with the typing.

In most of the code we do refer to hyp, that's why we kept the naming here too.
But yeah we could expand it.

> 
> >      buffer_size_kb
> >      trace_pipe
> >      trace_pipe_raw
> >      trace
> >      per_cpu/
> >              cpuX/
> >                  trace_pipe
> >                  trace_pipe_raw
> >      events/
> >             hyp/
> >                 hyp_enter/
> >                           enable
> >                           id
> > 

[...]

> > 
> > 4. Few limitations:
> > -------------------
> > 
> > Non consuming reading of the buffer isn't supported (i.e. cat trace) due
> > to the lack of support in the ring-buffer meta-page.
> 
> Hmm, I don't think it should be hard to support that. I've been looking
> into it for the user mapping. But that can be added later. For now, perhaps
> "cat trace" just returns -EPERM?

Yeah, I am sure that's something we can make work. But definitely not a priority
as it is less reliable than _pipe and unused by user-space tools I believe.

For now we print "Not supported yet". But happy to modify it to a EPERM.

> 
> > 
> > Tracing must be stopped for the buffer to be reset. i.e. (echo 0 >
> > tracing_on; echo 0 > trace)
> 
> Hmm, why this?  I haven't looked at the patches yet, but why can't the
> write to trace just stop tracing and re-enable it after the reset?

I could reset the buffers from the hypervisor with a dedicated hypercall.

However I'd still need a way to "teardown" the buffer, that is unsharing it with
the hypervisor and freeing the allocated memory. Using that reset for this
purpose was nice even though it implied to stop tracing in a first place. 

Perhaps `echo 0 > trace` could reset the buffer if tracing_on=1 and teardown the
buffers if tracing_on=0?

Alternatively, I could use `echo 0 > buffer_size_kb` for the teardown. But I
prefer the former solution: interface users are more likely to just 0 tracing_on
and trace.

> 
> > 
> 
> -- Steve