On Fri, 2023-11-24 at 17:19 +0100, Jeremi Piotrowski wrote:
> On 24/11/2023 14:33, Kirill A. Shutemov wrote:
> > On Fri, Nov 24, 2023 at 12:04:56PM +0100, Jeremi Piotrowski wrote:
> > > On 24/11/2023 11:43, Kirill A. Shutemov wrote:
> > > > On Fri, Nov 24, 2023 at 11:31:44AM +0100, Jeremi Piotrowsk
On Fri, 2023-11-24 at 11:38 +0100, Jeremi Piotrowski wrote:
> On 23/11/2023 15:13, Kirill A. Shutemov wrote:
> > On Wed, Nov 22, 2023 at 06:01:05PM +0100, Jeremi Piotrowski wrote:
> > > Introduce CC_ATTR_TDX_MODULE_CALLS to allow code to check whether TDX
> > > module
> > > calls are available. Wh
>
> > > >
> > > > Hm. Okay.
> > > >
> > > > Can we take a step back? What is bigger picture here? What enlightenment
> > > > do you expect from the guest when everything is in-place?
> > > >
> > >
> > > All the functional enlightenment are already in place in the kernel and
> > > everything wo
>
> > I think we are lacking background of this usage model and how it works. For
> > instance, typically L2 is created by L1, and L1 is responsible for L2's
> > device
> > I/O emulation. I don't quite understand how could L0 emulate L2's device
> > I/O?
> >
> > Can you provide more informat
On Thu, 2023-12-07 at 20:35 +0100, Jeremi Piotrowski wrote:
> On 07/12/2023 18:21, Jeremi Piotrowski wrote:
> > On 07/12/2023 13:58, Huang, Kai wrote:
> > > >
> > > > That's how it currently works - all the enlightenments are in
> > > > hype
On Fri, 2024-05-17 at 08:18 -0700, Dave Hansen wrote:
> On 5/17/24 07:19, Kirill A. Shutemov wrote:
> > arch/x86/boot/compressed/tdx.c| 32 +---
> > arch/x86/coco/tdx/tdcall.S| 145 ++-
> > arch/x86/coco/tdx/tdx-shared.c| 26 +--
> > arch/x86/coco/tdx/tdx.c
