PUCK follow up: Trusted IO call details

PUCK follow up: Trusted IO call details

[Edgecombe, Rick P]

The call I mentioned is officially called: "TAC Subcommittee: Linux Kernel Special Interest Group (Linux
Kernel-SIG)". This seems to be the info:
https://confidentialcomputing.io/about/committees/#Linux-Kernel-SIG

Paolo, unfortunately I did remember correctly that it is not an EU friendly time. Also, it appears to be
canceled this week.

Re: PUCK follow up: Trusted IO call details

[Xu Yilun]

On Wed, Apr 15, 2026 at 06:59:05PM +0000, Edgecombe, Rick P wrote:
> The call I mentioned is officially called: "TAC Subcommittee: Linux Kernel Special Interest Group (Linux
> Kernel-SIG)". This seems to be the info:
> https://confidentialcomputing.io/about/committees/#Linux-Kernel-SIG
> 
> Paolo, unfortunately I did remember correctly that it is not an EU friendly time. Also, it appears to be
> canceled this week.

Here is the Link to Dan's call.

https://zoom-lfx.platform.linuxfoundation.org/meeting/93219227394?password=80705486-101a-4e19-8f11-0baaf92104be

Dan said "The April 16th instance will be cancelled, but will pick it
back up on the regular schedule on April 30th"

Thanks,
Yilun

Re: PUCK follow up: Trusted IO call details

[Paolo Bonzini]

On Wed, Apr 15, 2026 at 8:59 PM Edgecombe, Rick P
<rick.p.edgecombe@intel.com> wrote:
>
> The call I mentioned is officially called: "TAC Subcommittee: Linux Kernel Special Interest Group (Linux
> Kernel-SIG)". This seems to be the info:
> https://confidentialcomputing.io/about/committees/#Linux-Kernel-SIG
>
> Paolo, unfortunately I did remember correctly that it is not an EU friendly time.

This one is friendly (9AM PST = 6PM CEST). The unfriendly one is the
IOMMUFD one (5AM :)).

Paolo

Re: PUCK follow up: Trusted IO call details

[Edgecombe, Rick P]

On Thu, 2026-04-16 at 14:59 +0200, Paolo Bonzini wrote:
> This one is friendly (9AM PST = 6PM CEST). The unfriendly one is the
> IOMMUFD one (5AM :)).

Haha, the link Yilun just posted says 8pm PST. "Kernel-SIG" was the one I was
trying point out, at least.

Re: PUCK follow up: Trusted IO call details

[Dan Williams]

Paolo Bonzini wrote:
> On Wed, Apr 15, 2026 at 8:59 PM Edgecombe, Rick P
> <rick.p.edgecombe@intel.com> wrote:
> >
> > The call I mentioned is officially called: "TAC Subcommittee: Linux Kernel Special Interest Group (Linux
> > Kernel-SIG)". This seems to be the info:
> > https://confidentialcomputing.io/about/committees/#Linux-Kernel-SIG
> >
> > Paolo, unfortunately I did remember correctly that it is not an EU friendly time.
> 
> This one is friendly (9AM PST = 6PM CEST). The unfriendly one is the
> IOMMUFD one (5AM :)).

There are couple topics at present that would be suitable to raise at
the EU-US friendly time. Specifically whether all of the per-arch
implementations of "transport large attestation evidence blobs over
shared memory from host-to-guest" would be better served with a shared
generic transport (simple virtio-pipe / something equivalent for vmbus
to publish).

Then there are the next steps with the uapi to convey PCI device
attestation that was proposed here [1], and also discussed as part of
the Rust SPDM proposal [2].

[1]: http://lore.kernel.org/20260303000207.1836586-9-dan.j.williams@intel.com
[2]: http://lore.kernel.org/69976d7d39c60_2f4a1009@dwillia2-mobl4.notmuch

Re: PUCK follow up: Trusted IO call details

[James Bottomley]

On Thu, 2026-04-16 at 19:37 -0700, Dan Williams wrote:
> Paolo Bonzini wrote:
> > On Wed, Apr 15, 2026 at 8:59 PM Edgecombe, Rick P
> > <rick.p.edgecombe@intel.com> wrote:
> > > 
> > > The call I mentioned is officially called: "TAC Subcommittee:
> > > Linux Kernel Special Interest Group (Linux Kernel-SIG)". This
> > > seems to be the info:
> > > https://confidentialcomputing.io/about/committees/#Linux-Kernel-SIG
> > > 
> > > Paolo, unfortunately I did remember correctly that it is not an
> > > EU friendly time.
> > 
> > This one is friendly (9AM PST = 6PM CEST). The unfriendly one is
> > the IOMMUFD one (5AM :)).
> 
> There are couple topics at present that would be suitable to raise at
> the EU-US friendly time. Specifically whether all of the per-arch
> implementations of "transport large attestation evidence blobs over
> shared memory from host-to-guest" would be better served with a
> shared generic transport (simple virtio-pipe / something equivalent
> for vmbus to publish).

Sorry to be a bit late to the party, but why invent a new thing
(virtio-pipe), why not use the existing virtio-vsock (and hyperv-vsock,
so no new vmbus device is needed)?  If you're thinking it's because you
need a simple cat into host and out of guest, then you can do that with
the ncat --vsock utility:

https://man7.org/linux/man-pages/man1/ncat.1.html


Regards,

James