From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:35778) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VjvNM-0003de-UE for qemu-devel@nongnu.org; Fri, 22 Nov 2013 13:22:50 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VjvNH-0003w1-2M for qemu-devel@nongnu.org; Fri, 22 Nov 2013 13:22:44 -0500 Received: from mail-pb0-f50.google.com ([209.85.160.50]:35259) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VjvNG-0003vx-SG for qemu-devel@nongnu.org; Fri, 22 Nov 2013 13:22:38 -0500 Received: by mail-pb0-f50.google.com with SMTP id rr13so1652929pbb.9 for ; Fri, 22 Nov 2013 10:22:38 -0800 (PST) Date: Fri, 22 Nov 2013 10:24:06 -0800 From: Christoffer Dall Message-ID: <20131122182406.GM9314@cbox> References: <1385140638-10444-1-git-send-email-peter.maydell@linaro.org> <1385140638-10444-8-git-send-email-peter.maydell@linaro.org> <20131122181149.GL9314@cbox> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Subject: Re: [Qemu-devel] [PATCH v9 07/11] hw/arm: Add 'virt' platform List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Maydell Cc: Patch Tracking , QEMU Developers , "kvmarm@lists.cs.columbia.edu" On Fri, Nov 22, 2013 at 06:17:51PM +0000, Peter Maydell wrote: > On 22 November 2013 18:11, Christoffer Dall wrote: > > On Fri, Nov 22, 2013 at 05:17:14PM +0000, Peter Maydell wrote: > >> + * Emulate a virtual board which works by passing Linux all the information > >> + * it needs about what devices are present via the device tree. > >> + * There are some restrictions about what we can do here: > >> + * + we can only present devices whose Linux drivers will work based > >> + * purely on the device tree with no platform data at all > >> + * + we want to present a very stripped-down minimalist platform, > >> + * both because this reduces the security attack surface from the guest > >> + * and also because it reduces our exposure to being broken when > >> + * the kernel updates its device tree bindings and requires further > >> + * information in a device binding that we aren't providing. > >> + * This is essentially the same approach kvmtool uses. > > > > nit: questionable value of this last line in the comment. > > Well, it says we're not doing something completely bonkers > of our own devising ;-) > ;) > > + vbi->bootinfo.board_id = -1; > > > > board_id = -1 ? > > This is what the kernel's boot protocol says you should > pass as the board ID register for boards which are new > enough that they only support booting via device tree > and not the old-style board ID number system. > ok, thanks. -Christoffer