On 26 July 2018 at 20:43, Peter Maydell <peter.mayd...@linaro.org> wrote: > On 26 July 2018 at 13:35, Andrew Jones <drjo...@redhat.com> wrote: >> On Thu, Jul 26, 2018 at 01:10:34PM +0100, Peter Maydell wrote: >>> On 26 July 2018 at 12:41, Andrew Jones <drjo...@redhat.com> wrote: >>> > The patch guards the generation. It'll only modify DT and ACPI for the >>> > new machine type. But, while modifying the DT makes sense, as that >>> > generated DT will get consumed >>> >>> ...will it? Why would we want the firmware to read the >>> QEMU-generated DT? Real hardware doesn't work that way. >>> >> >> Good point. If the plan for this reference software is to always >> prepare its own DTB and ACPI tables, then this patch shouldn't >> touch the DT generation either. Of course a lot of the device >> and fdt node creation is intertwined in mach-virt, so it's going >> to create a DTB anyway. > > I haven't yet looked at this patch so I might change my mind > once I've had time to look at the code, but my initial > thought is to prefer it to be in its own file rather than > trying to share code with the virt board. There's a lot > of stuff 'virt' needs that this doesn't (DT generation, > ACPI generation, switches to disable virtualization or > trustzone support, options to select GICv2, etc etc). > > Q: is this new board model intended to be able to work > under KVM, or is that out of scope? (You wouldn't be able > to run guest EL3 firmware under KVM, certainly.) > KVM is out of scope.
> thanks > -- PMM
