On Wed, Jul 25, 2018 at 11:47:39AM +0200, Ard Biesheuvel wrote: > On 25 July 2018 at 11:40, Andrew Jones <drjo...@redhat.com> wrote: > > On Wed, Jul 25, 2018 at 11:20:03AM +0200, Ard Biesheuvel wrote: > >> On 25 July 2018 at 11:17, Hongbo Zhang <hongbo.zh...@linaro.org> wrote: > >> > On 25 July 2018 at 17:13, Ard Biesheuvel <ard.biesheu...@linaro.org> > >> > wrote: > >> >> On 25 July 2018 at 11:09, Hongbo Zhang <hongbo.zh...@linaro.org> wrote: > >> >>> On 25 July 2018 at 17:01, Ard Biesheuvel <ard.biesheu...@linaro.org> > >> >>> wrote: > >> >>>> On 25 July 2018 at 10:48, Daniel P. Berrangé <berra...@redhat.com> > >> >>>> 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/qemu-devel@nongnu.org/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