Messages in this thread | | | Date | Fri, 25 Aug 2023 16:47:46 +0300 | From | "Kirill A. Shutemov" <> | Subject | Re: [PATCH] x86/tdx: Mark TSC reliable |
| |
On Thu, Aug 24, 2023 at 09:31:39PM +0200, Thomas Gleixner wrote: > On Tue, Aug 08 2023 at 23:01, Kirill A. Shutemov wrote: > > On Tue, Aug 08, 2023 at 10:13:05AM -0700, Dave Hansen wrote: > >> On 8/8/23 09:23, Kirill A. Shutemov wrote: > >> ... > >> > On the other hand, other clock sources (such as HPET, ACPI timer, > >> > APIC, etc.) necessitate VM exits to implement, resulting in more > >> > fluctuating measurements compared to TSC. Thus, those clock sources > >> > are not effective for calibrating TSC. > >> > >> Do we need to do anything to _those_ to mark them as slightly stinky? > > > > I don't know what the rules here. As far as I can see, all other clock > > sources relevant for TDX guest have lower rating. I guess we are fine? > > Ideally they are not enumerated in the first place, which prevents the > kernel from trying.
We can ask QEMU/KVM not to advertise them to TDX guest, but guest has to protect itself as the VMM is not trusted. And we are back to device filtering...
> > There's notable exception to the rating order is kvmclock which is higher > > than tsc. > > Which is silly aside of TDX. > > > It has to be disabled, but it is not clear to me how. This topic > > is related to how we are going to filter allowed devices/drivers, so I > > would postpone the decision until we settle on wider filtering schema. > > TDX aside it might be useful to have a mechanism to select TSC over KVM > clock in general.
Sean, Paolo, any comment on this?
-- Kiryl Shutsemau / Kirill A. Shutemov
| |