From owner-freebsd-virtualization@freebsd.org Fri Mar 3 18:42:36 2017 Return-Path: Delivered-To: freebsd-virtualization@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A8253CF7864 for ; Fri, 3 Mar 2017 18:42:36 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 8D03A1E1C for ; Fri, 3 Mar 2017 18:42:36 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id v23IgaDl055244 for ; Fri, 3 Mar 2017 18:42:36 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-virtualization@FreeBSD.org Subject: [Bug 216759] [kern] Memory speed with small blocks (1K) up to 35 times slower than host system (under QEMU emulation, but not only) Date: Fri, 03 Mar 2017 18:42:36 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 11.0-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Many People X-Bugzilla-Who: andrew@azar-a.net X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-virtualization@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-virtualization@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Discussion of various virtualization techniques FreeBSD supports." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Mar 2017 18:42:36 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D216759 --- Comment #14 from andrew@azar-a.net --- Bob, this issue is a major one. I had to delve into almost academical works around all available timers and their connection with virtualization. Seems the only "correct" work is done by VMWare which does corrections to broken TSC. I say "correct" because it still requires a special reliable_tsc flag on virtual CPU that the OS believes it. Reason? Because virtualization software does not provide direct access there might be time outs (say host = is doing something) which leads to skewing of time or even negative timer. Here's the VMWare "fix": static void tsc_freq_vmware(void) { u_int regs[4]; if (hv_high >=3D 0x40000010) { do_cpuid(0x40000010, regs); tsc_freq =3D regs[0] * 1000; } else { vmware_hvcall(VMW_HVCMD_GETHZ, regs); if (regs[1] !=3D UINT_MAX) tsc_freq =3D regs[0] | ((uint64_t)regs[1] << 32); } tsc_is_invariant =3D 1; } static void probe_tsc_freq(void) { ... if (vm_guest =3D=3D VM_GUEST_VMWARE) { tsc_freq_vmware(); return; } ... So this issue arrived on KVM, also with ease of migration it came to attent= ion that non-standardized timers lead to migration and suspend resume FAILURE. KVM created kvmclock - which is a monstrosity and is still twice slower than native TSC. And works only on Linux. FreeBSD has no support for KVMClock. It has native support for VMWare in co= de, however it does not recognize constant_tsc flag for some reason. This leads= to issue where OS under virtualization uses HPET or ACPI-PM which are slower on some systems and are serial (why have them faster when you have TSC?). Here's the code which kills the quality of TSC under KVM in FreeBSD: static int test_tsc(void) { uint64_t *data, *tsc; u_int i, size, adj; if ((!smp_tsc && !tsc_is_invariant) || vm_guest) return (-100); ... As you can see, KVM has no chance of going around. What takes sets the vm_g= uest variable? Well it's the 'hypervisor' flag on CPU Disabling which brings on a new can of worms (not working virtio drivers). = And I think it hits the SMP test which never happens (KVM gives 1 core) --=20 You are receiving this mail because: You are the assignee for the bug.=