Hi Sandrine,
Yes, I think using debugfs on the kernel side to control this feature (and other firmware control/debug stuff) is perfectly fine and as a good a solution as any other. I am not quite sure about pulling the whole 9p interface into Trusted Firmware, though... it feels a bit "heavy" for a firmware use case (e.g. the 9p layer alone is a thousand lines of code). I'm not sure I see the benefit over using the same debugfs interface on the kernel side but backing it by a kernel driver that translates the file accesses into a simpler, record-based SMC interface (that could also avoid the shared memory requirement, at least for simple requests). Maybe this depends on what else you're planning to do with this interface.
It also seems that you're intending for this to only be used for developer builds and never make it into a production image (e.g. it's printing a warning when not building with DEBUG=1). In that case, I can see that code size and complexity may not be a big concern. However, for the use case I had in mind I'd need this to be enabled in production images (Chrome OS doesn't really distinguish between test and production images for automated testing), so I'm looking more for a lightweight API where each command can be enabled/disabled individually at compile time.
I'd have to look at and test it in more detail when it's done, but given that it will likely increase code size by quite a bit and that I'm not sure how much I can trust it to be secure for production, I don't think this would work for my use case.