linux-kernel - Re: Fwd: RFC - TSC virtualization for KVM

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>] [day] [month] [year] [list]

Message-ID: <20091222153059.GE14679@amd.com>
Date:	Tue, 22 Dec 2009 16:30:59 +0100
From:	Joerg Roedel <joerg.roedel@....com>
To:	Zachary Amsden <zamsden@...hat.com>
CC:	linux-kernel@...r.kernel.org, Avi Kivity <avi@...hat.com>,
	Marcelo Tosatti <mtosatti@...hat.com>,
	Dor Laor <dlaor@...hat.com>, Joerg Roedel <joro@...tes.org>
Subject: Re: Fwd: RFC - TSC virtualization for KVM

Hi Zachary,

On Mon, Dec 14, 2009 at 07:15:27PM -1000, Zachary Amsden wrote:
> The overall goal is to have a stable platform TSC and a mixed set of
> virtualization approaches that can be tailored for the need of the particular
> operating system running, which runs on systems regardless of hardware TSC
> frequency changes, CPU hotplug, or destabilization events, and which allows
> virtualization of multiple different TSC speeds.  I realize this is ambitious,
> but it is achievable, and I believe these patches provide a solid foundation.

I have some high-level comments on your patchset. 

First, I like the idea of introducing a new ioctl to set the guest tsc
rate. But I think it could be a little bit simpler. How about a single
__u32 parameter instead of a struct. This parameter is the tsc rate for
the guest in khz. If this value is configured to be 0 this means the cpu
tsc frequency should be used.

Second, the patchset implements very sophisticated code to keep the tsc
of different cpus synchronized. This code looks a bit fragile to me, it
does not protect against SMI or NMI (and there is no way to do so).
Have you thought about using the kernel system time as a reference and
calculate a tsc value for the vcpu? The kernel timekeeping solves most
of the problems you have here already.

Regards,

	Joerg

--
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/