> From: Kirill A. Shutemov <kirill.shutemov@xxxxxxxxxxxxxxx> > Sent: Thursday, May 23, 2024 5:06 AM > To: Dexuan Cui <decui@xxxxxxxxxxxxx> > [...] > On Wed, May 22, 2024 at 07:24:41PM -0700, Dexuan Cui wrote: > > A TDX VM on Hyper-V may run in TD mode or Partitioned TD mode (L2). For > > the former, the VM has not enabled the Hyper-V TSC page (which is defined > > in drivers/clocksource/hyperv_timer.c: "... tsc_pg __bss_decrypted ...") > > because, for such a VM, the hypervisor requires that the page should be > > shared, but currently the __bss_decrypted is not working for such a VM > > yet. > > I don't see how it is safe. It opens guest clock for manipulations form > VMM. Could you elaborate on security implications? The intention of the patch is not to enable Hyper-V TSC page as a clocksource in such a VM. The default clocksource is still TSC. The intention of the patch is to enable Hyper-V TSC page only for Hyper-V timer. My understanding is that: "Hyper-V timer + Hyper-V TSC page" should be as safe as "local APIC timer + TSC" because the VM needs the hypervisor to emulate the timers, anyway. The guest may get a bad value of Hyper-V TSC page from a malicious hypervisor, and consequently the Hyper-V timer may fire too early or too late, but the similar thing can also happen to a local APIC timer, if a malicious hypervisor decides to deliver the timer interrupt too early or too late. > > Hyper-V TSC page can work as a clocksource device similar to KVM pv > > clock, and it's also used by the Hyper-V timer code to get the current > > time: see hv_init_tsc_clocksource(), which sets the global function > > pointer hv_read_reference_counter to read_hv_clock_tsc(); when > > Hyper-V TSC page is not enabled, hv_read_reference_counter defaults to > > be drivers/hv/hv_common.c: __hv_read_ref_counter(), which is suboptimal > > as it uses the slow MSR interface to get the time info. > > Why can't the guest just read the TSC directly? Why do we need the page? > I am confused. > > Kiryl Shutsemau / Kirill A. Shutemov Both Hyper-V TSC page and Hyper-V Reference Counter MSR return the absolute time in the unit of 0.1us since the VM starts to run, i.e. the "frequency" is 10M, which has a higher resolution than the emulated local APIC timer. Hyper-V timer depends on Hyper-V TSC page or Hyper-V Reference Counter MSR as it also uses the absolute time in the unit of 0.1us. We could potentially read the TSC and convert it to the absolute time in the unit of 0.1us, but the required math calculation is not very easy and can be unreliable (e.g. I suppose an AP's TSC is 0 when it's just being brought up online? But the Hyper-V TSC page value on the AP should be much bigger than 0) And, there will be an inaccuracy with the Hyper-V side conversion that may use a slightly different math calculation (e.g. slightly different TSC frequency or 'multi' or 'shift' values). It turns out the local APIC timer in such a VM also works! So probably the VM can just use local APIC timer and doesn't use Hyper-V timer. However, I noticed a strange thing: in my 128-VP VM, each local APIC timer constantly generates 100 interrupts per second, even if the VM is idle. Trying to find out why. I do enable tickles in my .config: CONFIG_NO_HZ_COMMON=y # CONFIG_HZ_PERIODIC is not set # CONFIG_NO_HZ_IDLE is not set CONFIG_NO_HZ_FULL=y CONFIG_NO_HZ=y CONFIG_HZ_100=y CONFIG_HZ=100 Thanks, -- Dexuan
