On Thu, Jun 22 2023 at 14:01, Erdem Aktas wrote:

On Mon, Jun 12, 2023 at 12:03 PM Dan Williams dan.j.williams@intel.com wrote:

...

Now multiple confidential computing vendors trying to develop similar flows with differentiated formats where that differentiation need not leak over the ABI boundary.

<Just my personal opinion below> I agree with this statement in the high level but it is also somehow surprising for me after all the discussion happened around this topic. Honestly, I feel like there are multiple versions of "Intel" working in different directions.

If we want multiple vendors trying to do the similar things behind a common ABI, it should start with the spec. Since this comment is coming from Intel, I wonder if there is any plan to combine the GHCB and GHCI interfaces under common ABI in the future or why it did not even happen in the first place.

You are conflating things here.

The GETQUOTE TDVMCALL interface is part of the Guest-Hypervisor Communication Interface (GHCI), which is a firmware interface.

Firmware (likewise hardware) interfaces have the unfortunate property that they are mostly cast in stone.

But that has absolutely nothing to do with the way how the kernel implements support for them. If we'd follow your reasoning then we'd have a gazillion of vendor specific SCSI stacks in the kernel.

What I see is that Intel has GETQUOTE TDVMCALL interface in its spec and again Intel does not really want to provide support for it in linux. It feels really frustrating.

Intel definitely wants to provide support for this interface and this very thread is about that support. But Intel is not in a position to define what the kernel community has to accept or not, neither is Google.

Sure, it would have been more efficient to come up with a better interface earlier, but that's neither an Intel nor a TDX specific problem.

It's just how kernel development works. Some ideas look good on first sight, some stuff slips through and at some point the maintainers realize that this is not the way to go and request a proper generalized and maintainable implementation.

If you can provide compelling technical reasons why the IOCTL is the better and more maintainable approach for the kernel, then we are all ears and happy to debate that on the technical level.

Feel free to be frustrated, but I can assure you that the only way to resolve this dilemma is to sit down and actually get work done in a way which is acceptable by the kernel community at the technical level.

Everything else is frustrating for everyone involved, not only you.

Thanks,

tglx