[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH v2 2/2] hw/arm: Add Arm Enterprise machine type

From: Hongbo Zhang
Subject: Re: [Qemu-devel] [PATCH v2 2/2] hw/arm: Add Arm Enterprise machine type
Date: Wed, 25 Jul 2018 18:22:17 +0800

On 25 July 2018 at 17:54, Andrew Jones <address@hidden> wrote:
> On Wed, Jul 25, 2018 at 01:30:52PM +0800, Hongbo Zhang wrote:
>> For the Aarch64, there is one machine 'virt', it is primarily meant to
>> run on KVM and execute virtualization workloads, but we need an
>> environment as faithful as possible to physical hardware, for supporting
>> firmware and OS development for pysical Aarch64 machines.
>> This patch introduces new machine type 'Enterprise' with main features:
>>  - Based on 'virt' machine type.
>>  - Re-designed memory map.
>>  - EL2 and EL3 are enabled by default.
>>  - GIC version 3 by default.
>>  - AHCI controller attached to system bus, and then CDROM and hard disc
>>    can be added to it.
>>  - EHCI controller attached to system bus, with USB mouse and key board
>>    installed by default.
>>  - E1000E ethernet card on PCIE bus.
>>  - VGA display adaptor on PCIE bus.
>>  - Default CPU type cortex-a57, 4 cores, and 1G bytes memory.
>>  - No virtio functions enabled, since this is to emulate real hardware.
> In the last review it was pointed out that using virtio-pci should still
> be "real" enough, so there's not much reason to avoid it. Well, unless
> there's some concern as to what drivers are available in the firmware and
> guest kernel. But that concern usually only applies to legacy firmwares
> and kernels, and therefore shouldn't apply to AArch64.
In real physical arm hardware, *HCI are system memory mapped, not on PCIE.
we need a QEMU platform like that. We need firmware developed on this
QEMU platform can run on real hardware without change(or only a minor
Concern is not only available firmwares, but more emphasis is on new
firmwares to be developed on this platform (target is developing
firmware for hardware, but using qemu if hardware is not available
temporarily), if virtio device used, then the newly developed firmware
must include virtio front-end codes, but it isn't needed while run on
real hardware at last.

>>  - No paravirtualized fw_cfg device either.
>> Arm Trusted Firmware and UEFI porting to this are done accordingly.
> How will UEFI get the ACPI tables from QEMU without fw-cfg? I didn't
> see any sort of reserved ROM region in the patch for them.
UEFI gets ACPI and kernel from network or mass storage, just like the
real hardware.
If we develop firmware depends on paravirtualized device like fw_cfg,
then we canot run such firmware on real hardware.

> Thanks,
> drew

reply via email to

[Prev in Thread] Current Thread [Next in Thread]