Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.36 as permitted sender) client-ip=23.128.96.36;
Message-ID: <b99c0f94-da56-4963-984d-ae177b0b7b0b@linux.microsoft.com>
Date:   Fri, 8 Dec 2023 13:45:01 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v1 1/3] x86/tdx: Check for TDX partitioning during early
 TDX init
Content-Language: en-US
To:     "Reshetova, Elena" <elena.reshetova@intel.com>
Cc:     "cascardo@canonical.com" <cascardo@canonical.com>,
        "Huang, Kai" <kai.huang@intel.com>,
        "Cui, Dexuan" <decui@microsoft.com>,
        "mhkelley58@gmail.com" <mhkelley58@gmail.com>,
        "kirill.shutemov@linux.intel.com" <kirill.shutemov@linux.intel.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>
References: <20231122170106.270266-1-jpiotrowski@linux.microsoft.com>
 <20231123135846.pakk44rqbbi7njmb@box.shutemov.name>
 <9f550947-9d13-479c-90c4-2e3f7674afee@linux.microsoft.com>
 <20231124104337.gjfyasjmo5pp666l@box.shutemov.name>
 <58c82110-45b2-4e23-9a82-90e1f3fa43c2@linux.microsoft.com>
 <20231124133358.sdhomfs25seki3lg@box.shutemov.name>
 <6f27610f-afc4-4356-b297-13253bb0a232@linux.microsoft.com>
 <ffcc8c550d5ba6122b201d8170b42ee581826d47.camel@intel.com>
 <02e079e8-cc72-49d8-9191-8a753526eb18@linux.microsoft.com>
 <7b725783f1f9102c176737667bfec12f75099961.camel@intel.com>
 <fa86fbd1-998b-456b-971f-a5a94daeca28@linux.microsoft.com>
 <DM8PR11MB57503924C64E1C79FB585496E78BA@DM8PR11MB5750.namprd11.prod.outlook.com>
From:   Jeremi Piotrowski <jpiotrowski@linux.microsoft.com>
In-Reply-To: <DM8PR11MB57503924C64E1C79FB585496E78BA@DM8PR11MB5750.namprd11.prod.outlook.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Precedence: bulk

On 07/12/2023 18:36, Reshetova, Elena wrote:
>>>> 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.

Hi Elena,

I think this RTC is more for compatibility and to give the guest a way to initialize
the system clock. This could potentially be a secure time source in the future but it
isn't right now. This is what the guest sees right now (might need some more
enlightenment):

# dmesg | grep -E -i 'clock|rtc|tsc'
[    0.000000] clocksource: hyperv_clocksource_tsc_page: mask: 0xffffffffffffffff max_cycles: 0x24e6a1710, max_idle_ns: 440795202120 ns
[    0.000001] tsc: Marking TSC unstable due to running on Hyper-V
[    0.003621] tsc: Detected 2100.000 MHz processor
[    0.411943] clocksource: refined-jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 7645519600211568 ns
[    0.887459] clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 7645041785100000 ns
[    0.895842] PM: RTC time: 16:31:58, date: 2023-12-07
[    1.043431] PTP clock support registered
[    1.096563] clocksource: Switched to clocksource hyperv_clocksource_tsc_page
[    1.384341] rtc_cmos 00:02: registered as rtc0
[    1.387469] rtc_cmos 00:02: setting system clock to 2023-12-07T16:31:58 UTC (1701966718)
[    1.392529] rtc_cmos 00:02: alarms up to one day, 114 bytes nvram
[    1.484243] sched_clock: Marking stable (1449873200, 33603000)->(3264982600, -1781506400)

Jeremi