linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Reshetova, Elena" <elena.reshetova@intel.com>
To: Jeremi Piotrowski <jpiotrowski@linux.microsoft.com>,
	"Huang, Kai" <kai.huang@intel.com>,
	"kirill.shutemov@linux.intel.com"
	<kirill.shutemov@linux.intel.com>,
	"mhkelley58@gmail.com" <mhkelley58@gmail.com>,
	"Cui, Dexuan" <decui@microsoft.com>
Cc: "cascardo@canonical.com" <cascardo@canonical.com>,
	"tim.gardner@canonical.com" <tim.gardner@canonical.com>,
	"dave.hansen@linux.intel.com" <dave.hansen@linux.intel.com>,
	"thomas.lendacky@amd.com" <thomas.lendacky@amd.com>,
	"roxana.nicolescu@canonical.com" <roxana.nicolescu@canonical.com>,
	"stable@vger.kernel.org" <stable@vger.kernel.org>,
	"haiyangz@microsoft.com" <haiyangz@microsoft.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"mingo@redhat.com" <mingo@redhat.com>,
	"tglx@linutronix.de" <tglx@linutronix.de>,
	"stefan.bader@canonical.com" <stefan.bader@canonical.com>,
	"nik.borisov@suse.com" <nik.borisov@suse.com>,
	"kys@microsoft.com" <kys@microsoft.com>,
	"hpa@zytor.com" <hpa@zytor.com>,
	"peterz@infradead.org" <peterz@infradead.org>,
	"wei.liu@kernel.org" <wei.liu@kernel.org>,
	"sashal@kernel.org" <sashal@kernel.org>,
	"linux-hyperv@vger.kernel.org" <linux-hyperv@vger.kernel.org>,
	"bp@alien8.de" <bp@alien8.de>, "x86@kernel.org" <x86@kernel.org>
Subject: RE: [PATCH v1 1/3] x86/tdx: Check for TDX partitioning during early TDX init
Date: Thu, 7 Dec 2023 17:36:22 +0000	[thread overview]
Message-ID: <DM8PR11MB57503924C64E1C79FB585496E78BA@DM8PR11MB5750.namprd11.prod.outlook.com> (raw)
In-Reply-To: <fa86fbd1-998b-456b-971f-a5a94daeca28@linux.microsoft.com>

> >> The TDVMCALLs are related to the I/O path (networking/block io) into the L2
> guest, and
> >> so they intentionally go straight to L0 and are never injected to L1. L1 is not
> >> involved in that path at all.
> >>
> >> Using something different than TDVMCALLs here would lead to additional
> traps to L1 and
> >> just add latency/complexity.
> >
> > Looks by default you assume we should use TDX partitioning as "paravisor L1" +
> > "L0 device I/O emulation".
> >
> 
> I don't actually want to impose this model on anyone, but this is the one that
> could use some refactoring. I intend to rework these patches to not use a single
> "td_partitioning_active" for decisions.
> 
> > 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 information?
> 
> Let's differentiate between fast and slow I/O. The whole point of the paravisor in
> L1 is to provide device emulation for slow I/O: TPM, RTC, NVRAM, IO-APIC, serial
> ports.

Out of my curiosity and not really related to this discussion, but could you please
elaborate on RTC part here? Do you actually host secure time in L1 to be provided
to the L2? 

Best Regards,
Elena.

  parent reply	other threads:[~2023-12-07 17:37 UTC|newest]

Thread overview: 42+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-11-22 17:01 [PATCH v1 1/3] x86/tdx: Check for TDX partitioning during early TDX init Jeremi Piotrowski
2023-11-22 17:01 ` [PATCH v1 2/3] x86/coco: Disable TDX module calls when TD partitioning is active Jeremi Piotrowski
2023-11-23 14:13   ` Kirill A. Shutemov
2023-11-24 10:38     ` Jeremi Piotrowski
2023-11-29 10:37       ` Huang, Kai
2023-12-01 15:27         ` Jeremi Piotrowski
2023-11-22 17:01 ` [PATCH v1 3/3] x86/tdx: Provide stub tdx_accept_memory() for non-TDX configs Jeremi Piotrowski
2023-11-23 14:11   ` Kirill A. Shutemov
2023-11-24 10:00     ` Jeremi Piotrowski
2023-11-22 17:19 ` [PATCH v1 1/3] x86/tdx: Check for TDX partitioning during early TDX init Jeremi Piotrowski
2023-11-29 16:40   ` Borislav Petkov
2023-11-30  7:08     ` Reshetova, Elena
2023-11-30  7:55       ` Borislav Petkov
2023-11-30  8:31         ` Reshetova, Elena
2023-11-30  9:21           ` Borislav Petkov
2023-12-04 16:44             ` Jeremi Piotrowski
2023-12-04 13:39           ` Jeremi Piotrowski
2023-12-04 19:37     ` Jeremi Piotrowski
2023-11-23 13:58 ` Kirill A. Shutemov
2023-11-24 10:31   ` Jeremi Piotrowski
2023-11-24 10:43     ` Kirill A. Shutemov
2023-11-24 11:04       ` Jeremi Piotrowski
2023-11-24 13:33         ` Kirill A. Shutemov
2023-11-24 16:19           ` Jeremi Piotrowski
2023-11-29  4:36             ` Huang, Kai
2023-12-01 16:16               ` Jeremi Piotrowski
2023-12-05 13:26                 ` Huang, Kai
2023-12-06 18:47                   ` Jeremi Piotrowski
2023-12-07 12:58                     ` Huang, Kai
2023-12-07 17:21                       ` Jeremi Piotrowski
2023-12-07 19:35                         ` Jeremi Piotrowski
2023-12-08 10:51                           ` Huang, Kai
2023-12-07 17:36                     ` Reshetova, Elena [this message]
2023-12-08 12:45                       ` Jeremi Piotrowski
2023-12-04  9:17 ` Reshetova, Elena
2023-12-04 19:07   ` Jeremi Piotrowski
2023-12-05 10:54     ` Kirill A. Shutemov
2023-12-06 17:49       ` Jeremi Piotrowski
2023-12-06 22:54         ` Kirill A. Shutemov
2023-12-07 17:06           ` Jeremi Piotrowski
2023-12-07 20:56             ` Kirill A. Shutemov
2023-12-05 13:24     ` Reshetova, Elena

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=DM8PR11MB57503924C64E1C79FB585496E78BA@DM8PR11MB5750.namprd11.prod.outlook.com \
    --to=elena.reshetova@intel.com \
    --cc=bp@alien8.de \
    --cc=cascardo@canonical.com \
    --cc=dave.hansen@linux.intel.com \
    --cc=decui@microsoft.com \
    --cc=haiyangz@microsoft.com \
    --cc=hpa@zytor.com \
    --cc=jpiotrowski@linux.microsoft.com \
    --cc=kai.huang@intel.com \
    --cc=kirill.shutemov@linux.intel.com \
    --cc=kys@microsoft.com \
    --cc=linux-hyperv@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mhkelley58@gmail.com \
    --cc=mingo@redhat.com \
    --cc=nik.borisov@suse.com \
    --cc=peterz@infradead.org \
    --cc=roxana.nicolescu@canonical.com \
    --cc=sashal@kernel.org \
    --cc=stable@vger.kernel.org \
    --cc=stefan.bader@canonical.com \
    --cc=tglx@linutronix.de \
    --cc=thomas.lendacky@amd.com \
    --cc=tim.gardner@canonical.com \
    --cc=wei.liu@kernel.org \
    --cc=x86@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).