From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 20 16:45:07 2008 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 92D9A1065673 for ; Thu, 20 Mar 2008 16:45:07 +0000 (UTC) (envelope-from dillon@apollo.backplane.com) Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by mx1.freebsd.org (Postfix) with ESMTP id 791B78FC1C for ; Thu, 20 Mar 2008 16:45:06 +0000 (UTC) (envelope-from dillon@apollo.backplane.com) Received: from apollo.backplane.com (localhost [127.0.0.1]) by apollo.backplane.com (8.14.1/8.13.7) with ESMTP id m2KGj65D053981; Thu, 20 Mar 2008 09:45:06 -0700 (PDT) Received: (from dillon@localhost) by apollo.backplane.com (8.14.1/8.13.4/Submit) id m2KGj6BP053980; Thu, 20 Mar 2008 09:45:06 -0700 (PDT) Date: Thu, 20 Mar 2008 09:45:06 -0700 (PDT) From: Matthew Dillon Message-Id: <200803201645.m2KGj6BP053980@apollo.backplane.com> To: John Baldwin References: <200803172158.m2HLwPSI021438@apollo.backplane.com> <200803192248.m2JMmkEn045986@apollo.backplane.com> <200803200854.26258.jhb@freebsd.org> Cc: freebsd-hackers@freebsd.org, walt Subject: Re: vkernel & GSoC, some questions X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Mar 2008 16:45:07 -0000 :Except that you still need "real" hardware concurrency to see some races and :that is important for testing. I'd worry about the overhead of any :non-hardware assisted virtualization basically enforcing more serialization :and coherency than is present in real-world systems meaning that code will :work fine in the virtual environment and only break on real hardware. For :example, when I worked on the rwlock implementation for FreeBSD 6/7, I wrote :a custom kernel module that banged on the locks a lot and used KTR traces to :verify that every single code path in the lock and unlock routines was :exercised on a 4-way machine. : :I do think that vitualized environments can certainly be useful for many :things (I used qemu for the recent GPT boot stuff and BTX changes and being :able to single step in gdb for that was extremely useful and time-saving), :but with concurrency races I think it is very important to make sure there is :a lot of testing on full-speed, concurrent hardware. : :-- :John Baldwin Hardware and vkernel/qemu environments exercise different code paths and different timing mechanics. Certain bugs show up on vkernel's more readily then on real hardware, while other bugs show up more readily on real hardware then on vkernel's. I don't think one is particularly better then another with regards to testing, they just cover different continuums. -Matt Matthew Dillon