qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Peter Maydell <peter.maydell@linaro.org>
To: Christoffer Dall <christoffer.dall@linaro.org>
Cc: Patch Tracking <patches@linaro.org>,
	QEMU Developers <qemu-devel@nongnu.org>,
	"kvmarm@lists.cs.columbia.edu" <kvmarm@lists.cs.columbia.edu>
Subject: Re: [Qemu-devel] [PATCH v9 07/11] hw/arm: Add 'virt' platform
Date: Fri, 22 Nov 2013 18:17:51 +0000	[thread overview]
Message-ID: <CAFEAcA9fbxnupiHRY+58ypUsEy7nQtsH5ZMVs1vL0cwGPiKu1Q@mail.gmail.com> (raw)
In-Reply-To: <20131122181149.GL9314@cbox>

On 22 November 2013 18:11, Christoffer Dall <christoffer.dall@linaro.org> 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.

-- PMM

  reply	other threads:[~2013-11-22 18:18 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-11-22 17:17 [Qemu-devel] [PATCH v9 00/11] target-arm: mach virt and -cpu host support Peter Maydell
2013-11-22 17:17 ` [Qemu-devel] [PATCH v9 01/11] target-arm: Provide mechanism for getting KVM constants even if not CONFIG_KVM Peter Maydell
2013-11-22 17:17 ` [Qemu-devel] [PATCH v9 02/11] device_tree.c: Terminate the empty reservemap in create_device_tree() Peter Maydell
2013-11-24  8:04   ` Peter Crosthwaite
2013-11-22 17:17 ` [Qemu-devel] [PATCH v9 03/11] hw/arm/boot: Allow boards to provide an fdt blob Peter Maydell
2013-11-22 17:17 ` [Qemu-devel] [PATCH v9 04/11] target-arm: Provide PSCI constants to generic QEMU code Peter Maydell
2013-11-22 17:52   ` Christoffer Dall
2013-11-22 17:17 ` [Qemu-devel] [PATCH v9 05/11] target-arm: Add ARMCPU field for Linux device-tree 'compatible' string Peter Maydell
2013-11-22 17:17 ` [Qemu-devel] [PATCH v9 06/11] target-arm: Allow secondary KVM CPUs to be booted via PSCI Peter Maydell
2013-11-22 17:17 ` [Qemu-devel] [PATCH v9 07/11] hw/arm: Add 'virt' platform Peter Maydell
2013-11-22 18:11   ` Christoffer Dall
2013-11-22 18:17     ` Peter Maydell [this message]
2013-11-22 18:24       ` Christoffer Dall
2013-11-22 17:17 ` [Qemu-devel] [PATCH v9 08/11] linux-headers: Update from mainline Peter Maydell
2013-12-02 13:35   ` Peter Maydell
2013-11-22 17:17 ` [Qemu-devel] [PATCH v9 09/11] target-arm: Don't hardcode KVM target CPU to be A15 Peter Maydell
2013-11-22 17:17 ` [Qemu-devel] [PATCH v9 10/11] target-arm: Provide '-cpu host' when running KVM Peter Maydell
2013-11-22 18:25   ` Christoffer Dall
2013-11-22 18:50     ` Peter Maydell
2013-11-22 19:00       ` Christoffer Dall
2013-11-22 17:17 ` [Qemu-devel] [PATCH v9 11/11] hw/arm/virt: Support -cpu host Peter Maydell
2013-11-22 18:26 ` [Qemu-devel] [PATCH v9 00/11] target-arm: mach virt and -cpu host support Christoffer Dall
2013-12-02 13:46 ` Peter Maydell

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAFEAcA9fbxnupiHRY+58ypUsEy7nQtsH5ZMVs1vL0cwGPiKu1Q@mail.gmail.com \
    --to=peter.maydell@linaro.org \
    --cc=christoffer.dall@linaro.org \
    --cc=kvmarm@lists.cs.columbia.edu \
    --cc=patches@linaro.org \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).