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

[Andrew Jones]

On Wed, Jul 25, 2018 at 11:47:39AM +0200, Ard Biesheuvel wrote:
> On 25 July 2018 at 11:40, Andrew Jones <address@hidden> wrote:
> > On Wed, Jul 25, 2018 at 11:20:03AM +0200, Ard Biesheuvel wrote:
> >> On 25 July 2018 at 11:17, Hongbo Zhang <address@hidden> wrote:
> >> > On 25 July 2018 at 17:13, Ard Biesheuvel <address@hidden> wrote:
> >> >> On 25 July 2018 at 11:09, Hongbo Zhang <address@hidden> wrote:
> >> >>> On 25 July 2018 at 17:01, Ard Biesheuvel <address@hidden> wrote:
> >> >>>> On 25 July 2018 at 10:48, Daniel P. Berrangé <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:
> >> >>>>>
> >> >>>>> The 'enterprise' name is really awful - this is essentially a 
> >> >>>>> marketing
> >> >>>>> term completely devoid of any useful meaning.
> >> >>>>>
> >> >>>>> You had previously called this "sbsa" which IIUC was related to a 
> >> >>>>> real
> >> >>>>> world hardware specification that it was based on. IOW, I think this 
> >> >>>>> old
> >> >>>>> name was preferrable to calling it "enterprise".
> >> >>>>>
> >> >>>>
> >> >>>> I couldn't agree more. However, IIUC this change was made at the
> >> >>>> request of one of the reviewers, although I wasn't part of the
> >> >>>> discussion at that point, so I'm not sure who it was.
> >> >>>>
> >> >>>> Hongbo, could you please share a link to that discussion?
> >> >>>>
> >> >>>> Thanks,
> >> >>>> Ard.
> >> >>>>
> >> >>>
> >> >>> V1 discussion here:
> >> >>> https://www.mail-archive.com/address@hidden/msg545775.html
> >> >>>
> >> >>
> >> >> So who asked for the sbsa -> enterprise change?
> >> >
> >> > Actually nobody, but it was argued that sbsa does not require ehci and
> >> > ahci etc, then we should find a name fitting for this platform better.
> >>
> >> That doesn't make sense to me. The SBSA describes a minimal
> >> configuration, it does not limit what peripherals may be attached to
> >> the core system.
> >>
> >
> > Hi Ard,
> >
> > I think that a machine model named 'sbsa' should provide all SBSA required
> > hardware, and nothing else, while providing a means to easily extend the
> > machine beyond that in any way the user likes. The user can easily add
> > devices with the command line and/or by using -readconfig to build a
> > "typical" machine. Note, it should even be possible to add, e.g. an ACHI
> > controller, to the memory map using the platform bus, if that's preferred
> > over PCIe.
> >
> 
> The purpose of the SBSA machine is not to provide a minimal
> configuration. It is intended to exercise all the moving parts one
> might find in a server firmware/OS stack, including pieces that are
> not usually found on x86 machines, such as DRAM starting above 4 GB
> and SATA/USB controllers that are not PCIe based.

To me, this purpose actually requires that the base config be minimal.
How else can you have the flexibility to build a wide range of
configurations for testing?

> 
> If we start layering the usual components on top, it is highly likely
> that checking the EHCI box gives you a PCI based USB2 controller,
> partially defeating the purpose of the exercise.
>

As I said, it should be possible to put these controllers on the system
bus, even if they're specified on the command line. This would be done
using the platform-bus framework. Naturally, providing platform-bus
support for devices/controllers that need it will take some machine-done
notifier code, etc., so this machine model patch series will get more
complex.

Thanks,
drew