From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NTJiI-0002Gx-OF for qemu-devel@nongnu.org; Fri, 08 Jan 2010 13:37:34 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NTJiE-0002Aw-NE for qemu-devel@nongnu.org; Fri, 08 Jan 2010 13:37:34 -0500 Received: from [199.232.76.173] (port=39347 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NTJiE-0002Ak-G5 for qemu-devel@nongnu.org; Fri, 08 Jan 2010 13:37:30 -0500 Received: from cantor2.suse.de ([195.135.220.15]:36315 helo=mx2.suse.de) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NTJiD-0005Iv-L1 for qemu-devel@nongnu.org; Fri, 08 Jan 2010 13:37:30 -0500 Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Alexander Graf In-Reply-To: Date: Fri, 8 Jan 2010 19:37:25 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <31A952FA-8EA7-48FB-BE71-C7EFC953F262@suse.de> References: <1262972592-7317-1-git-send-email-agraf@suse.de> <6374C4B6-BFB4-4EC5-8DA9-1377392623CF@suse.de> <6C965A04-49D9-4529-B1A0-E931C7626C87@suse.de> Subject: [Qemu-devel] Re: [PATCH] PPC: tell the guest about the time base frequency List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Blue Swirl Cc: QEMU Developers , Aurelien Jarno On 08.01.2010, at 19:29, Blue Swirl wrote: > On Fri, Jan 8, 2010 at 6:27 PM, Alexander Graf wrote: >>=20 >> On 08.01.2010, at 19:22, Blue Swirl wrote: >>=20 >>> On Fri, Jan 8, 2010 at 6:07 PM, Alexander Graf = wrote: >>>>=20 >>>> On 08.01.2010, at 19:04, Blue Swirl wrote: >>>>=20 >>>>> On Fri, Jan 8, 2010 at 5:43 PM, Alexander Graf = wrote: >>>>>> Our guest systems need to know by how much the timebase increases = every second, >>>>>> so there usually is a "timebase-frequency" property in the cpu = leaf of the >>>>>> device tree. >>>>>>=20 >>>>>> This property is missing in OpenBIOS, as is the "clock-frequency" = property that >>>>>> tells the guest how fast the CPU is. FWIW that one is only used = for >>>>>> /proc/cpuinfo though. >>>>>>=20 >>>>>> With qemu, Linux's fallback timebase speed and qemu's internal = timebase speed >>>>>> match up. With KVM, that is no longer true. The guest is running = at the same >>>>>> timebase speed as the host. >>>>>>=20 >>>>>> This leads to massive timing problems. On my test machine, a = "sleep 2" takes >>>>>> about 14 seconds with KVM enabled. >>>>>>=20 >>>>>> This patch exports the timebase and clock frequencies to = OpenBIOS, so it can >>>>>> then put them into the device tree. I'll push the OpenBIOS change = with the >>>>>> NewWorld patch set, once that's either been reviewed or applied. >>>>>=20 >>>>> IIRC copying the host CPU frequency to guest was rejected earlier = for x86. >>>>=20 >>>> Well IIRC x86 Linux tries to find out the cpu frequency itself. >>>> PPC Linux doesn't - it completely relies on entries in the device = tree. >>>=20 >>> The frequency could be a parameter for the -cpu flag, like -cpu >>> 970fx,frequency=3D1000000000. >>=20 >> We could implement that as an override to the current static code = path. >> For KVM it doesn't make any sense, as you really want to see the host = frequency in the guest here. That's what users expect. Period. >=20 > Even with 10 guests? What about migration? Boot up a hypervisor of your choice on any random x86 box. Yes, that's = exactly what you get. cpuinfo wrt migration is broken. Since the timebase isn't trapable on = ppc, you can also expect things to blow up completely when migrating a = ppc VM. That being said the only chance of ever getting migration to work = properly on ppc would be to notify the guest that the timer frequency = just changed, at which point it would have to reload it, rebase all = timers off the new frequency and try to temper over everything as much = as it can. Either way, that's completely orthogonal to the question of exposing the = host cpu frequency to the guest. I think we should do what users expect. I agree that having a -cpu flag = to set the exposed frequency is a good idea. However, the default = shouldn't be hardcoded but determined as cleverly as possible. If you like to do the -cpu flag, you're more than welcome to do so. I'm = trying to fix bugs for now, getting ppc64 working fine in qemu. And = there are seriously worse things out there than a lacking way of = defining the cpu frequency with -cpu I'd rather spend my time on. Alex=