linux-kernel - Re: Use CPUID to communicate with the hypervisor.

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <48E1DF2C.9050409@redhat.com>
Date:	Tue, 30 Sep 2008 10:11:24 +0200
From:	Gerd Hoffmann <kraxel@...hat.com>
To:	akataria@...are.com
CC:	Ingo Molnar <mingo@...e.hu>, "H. Peter Anvin" <hpa@...or.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	LKML <linux-kernel@...r.kernel.org>,
	the arch/x86 maintainers <x86@...nel.org>,
	Jeremy Fitzhardinge <jeremy@...p.org>,
	"avi@...hat.com" <avi@...hat.com>,
	Rusty Russell <rusty@...tcorp.com.au>,
	Zach Amsden <zach@...are.com>,
	Daniel Hecht <dhecht@...are.com>,
	"Jun.Nakajima@...el.Com" <Jun.Nakajima@...el.Com>
Subject: Re: Use CPUID to communicate with the hypervisor.

Alok Kataria wrote:
> Hi Gerd,
> 
> I really fail to see your point here. Maybe you can point out what am i
> missing.
> Think about the current situation, whenever there is migration to such a
> tsc-is-different system , how does the guest come to know about the
> frequency change, either through a $event or if it reboots it runs the
> calibration algorithm.

Well, that should be clearly defined, that is my point.  When asking the
hypervisor for the tsc instead of running a calibration loop, then we
have a small bit of paravirtualization:  The guest is aware that it runs
on a hypervisor and just asks it directly.  So while we are at it we can
also define a way to communicate tsc freq changes between host and
guest, so the cost of trap'n'emulate tsc reads can be avoided.  Or we
define "tsc is constant" and leave it to the hypervisor to make sure it
actually appears being constant to the guest, even in case it changes on
the host.  But it must be defined one way or another, so the guest knows
whenever it should expect the tsc frequency change or not.  And in case
we allow tsc changes, we also need a way to signal that to the guest.

Is the tsc cpu leaf interface set in stone already (aka implemented in
vmware versions released to public)?

> What special things does Xen do at migration, which would be affected by
> this interface ?

paravirtualized xen guests have a paravirtual clock.  That is a struct
containing three pieces of information: system time, tsc counter for the
last system time update, tsc frequency.  The guest gets the current time
by reading the system time and adding a delta calculated from current
tsc, tsc of last systime update and tsc frequency.  Handling tsc
frequency changes is obviously trivial here, just update the field on
the next systime update ;)

cheers,
  Gerd
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/