From owner-freebsd-stable@FreeBSD.ORG Sat Mar 17 19:21:59 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D7B8A1065670 for ; Sat, 17 Mar 2012 19:21:59 +0000 (UTC) (envelope-from alan.l.cox@gmail.com) Received: from mail-pb0-f54.google.com (mail-pb0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id A913B8FC08 for ; Sat, 17 Mar 2012 19:21:59 +0000 (UTC) Received: by pbcwz17 with SMTP id wz17so575129pbc.13 for ; Sat, 17 Mar 2012 12:21:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=lXPRuQQdzmSX1I0EH7OEwmD63LvBi+KHp0gvzT0I4bo=; b=TZSeGjQ5k60YqCCIqVBC7XbYXs1Zh7b685h9cpiRkLWhhu9NeNYT6pRwV/ywaANigS b+j3mYFHH0E1mNe3cDqi4s7TaOgQZJN82i/Kg/w0qqFKwdjwFBAROxkVQzzt8MHZYWFW bOt6i0XWdcuxizQMlHO1eNoR3aiTsVh+cCA4MMa+mbnYCOUA6dui+m1tju1L4DHqeCmA A6N4pRpfApIpV43LTG6v4tGVegaYZ7N026SKyAswp/Z4aJG3tT6w/AyDPVEURsCqBEWs fF50izg9EIi2z1pTqtN6CjL/qcSUwIEL0wl3H4kjhKIQCzqr6RKZtlRae2qgJupzwnKG lu3g== MIME-Version: 1.0 Received: by 10.68.197.74 with SMTP id is10mr2421371pbc.153.1332012119274; Sat, 17 Mar 2012 12:21:59 -0700 (PDT) Received: by 10.68.223.5 with HTTP; Sat, 17 Mar 2012 12:21:59 -0700 (PDT) In-Reply-To: <4F64C57F.6040403@cs.stonybrook.edu> References: <4F64C50F.70409@cs.stonybrook.edu> <4F64C57F.6040403@cs.stonybrook.edu> Date: Sat, 17 Mar 2012 14:21:59 -0500 Message-ID: From: Alan Cox To: Richard Yao Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-stable@freebsd.org Subject: Re: AMD Erratum 383 crashes FreeBSD 9-Stable X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: alc@freebsd.org List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Mar 2012 19:21:59 -0000 On Sat, Mar 17, 2012 at 12:10 PM, Richard Yao wrote: > On 03/17/12 13:08, Richard Yao wrote: > > Dear FreeBSD Developers: > > > > I used the ZFS Guru LiveCD to install FreeBSD 9 in KVM on a host system > > with an AMD Thuban processor (K10h). I then proceeded to compile perl > > and the VM crashed. Linux's dmesg gave me the following hint as to the > > cause: > > > > [ 3568.234654] KVM: Guest triggered AMD Erratum 383 > > > > I also tried installing Gentoo Prefix, a userland package manager like > > NetBSD pkgsrc, and the VM also crashed with the same message when > > compiling the first component. AMD has documented this issue, with a > > workaround for hypervisors and a statement saying that they won't fix it: > > > > "If system software performs uncommon methods to change the page size of > > an active page table that is valid, the CPU core may, under a highly > > specific and detailed set of conditions, form duplicate TLB entries for > > a single linear address. The CPU core will machine check if this page is > > then accessed prior to it being invalidated from the TLB." > > > > http://support.amd.com/us/Embedded_TechDocs/41322.pdf > > > > Has anyone done anything to workaround this issue? I have a Gentoo > > Hardened VM running on this machine which has no problem compiling > > software, so I am sure that some sort of page table workaround is > possible. > > > > Yours truly, > > Richard Yao > > > > I was tired when I wrote that, so my eyes seem to have skipped some > advice from AMD on how to workaround this in the kernel: > > "Affected software must ensure that page sizes are only increased or > decreased after the entry is invalidated and flushed out of all TLBs. > When flushing multiple entries from the TLB, software may wish to use a > single MOV CR3 value to invalidate the TLB instead of repetitive INVLPG > instructions" > > Also, I am not on the mailing list, so please CC replies to me. > > When the FreeBSD kernel detects that it is running on an affected processor, it automatically enables the recommended workaround. However, because you are running within a virtual machine, the automatic detection may not be working. Alternatively, you may be using a newer processor revision that still suffers from the bug, but the kernel doesn't enable the workaround for. Can you tell us how the FreeBSD guest sees the underlying processor, e.g., the first few lines of dmesg from the guest? Alan