[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <b99c0f94-da56-4963-984d-ae177b0b7b0b@linux.microsoft.com>
Date: Fri, 8 Dec 2023 13:45:01 +0100
From: Jeremi Piotrowski <jpiotrowski@...ux.microsoft.com>
To: "Reshetova, Elena" <elena.reshetova@...el.com>
Cc: "cascardo@...onical.com" <cascardo@...onical.com>,
"Huang, Kai" <kai.huang@...el.com>,
"Cui, Dexuan" <decui@...rosoft.com>,
"mhkelley58@...il.com" <mhkelley58@...il.com>,
"kirill.shutemov@...ux.intel.com" <kirill.shutemov@...ux.intel.com>,
"tim.gardner@...onical.com" <tim.gardner@...onical.com>,
"dave.hansen@...ux.intel.com" <dave.hansen@...ux.intel.com>,
"thomas.lendacky@....com" <thomas.lendacky@....com>,
"roxana.nicolescu@...onical.com" <roxana.nicolescu@...onical.com>,
"stable@...r.kernel.org" <stable@...r.kernel.org>,
"haiyangz@...rosoft.com" <haiyangz@...rosoft.com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"mingo@...hat.com" <mingo@...hat.com>,
"tglx@...utronix.de" <tglx@...utronix.de>,
"stefan.bader@...onical.com" <stefan.bader@...onical.com>,
"nik.borisov@...e.com" <nik.borisov@...e.com>,
"kys@...rosoft.com" <kys@...rosoft.com>,
"hpa@...or.com" <hpa@...or.com>,
"peterz@...radead.org" <peterz@...radead.org>,
"wei.liu@...nel.org" <wei.liu@...nel.org>,
"sashal@...nel.org" <sashal@...nel.org>,
"linux-hyperv@...r.kernel.org" <linux-hyperv@...r.kernel.org>,
"bp@...en8.de" <bp@...en8.de>, "x86@...nel.org" <x86@...nel.org>
Subject: Re: [PATCH v1 1/3] x86/tdx: Check for TDX partitioning during early
TDX init
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
Powered by blists - more mailing lists