Re: [Xen-devel] [RFC] ARM VM System Sepcification

[Grant Likely <grant.likely@xxxxxxxxxx>]

On Thu, 27 Feb 2014 12:27:58 +0000, Stefano Stabellini 
<stefano.stabellini@xxxxxxxxxxxxx> wrote:
> On Wed, 26 Feb 2014, Grant Likely wrote:
> > > VM Platform
> > > -----------
> > > The specification does not mandate any specific memory map. Â The guest
> > > OS must be able to enumerate all processing elements, devices, and
> > > memory through HW description data (FDT, ACPI) or a bus-specific
> > > mechanism such as PCI.
> > >
> > > The virtual platform must support at least one of the following ARM
> > > execution states:
> > > Â  (1) aarch32 virtual CPUs on aarch32 physical CPUs
> > > Â  (2) aarch32 virtual CPUs on aarch64 physical CPUs
> > > Â  (3) aarch64 virtual CPUs on aarch64 physical CPUs
> > >
> > > It is recommended to support both (2) and (3) on aarch64 capable
> > > physical systems.
> > >
> > > The virtual hardware platform must provide a number of mandatory
> > > peripherals:
> > >
> > > Â  Serial console: Â The platform should provide a console,
> > > Â  based on an emulated pl011, a virtio-console, or a Xen PV console.
> > 
> > For portable disk image, can Xen PV be dropped from the list? pl011 is part 
> > of SBSA, and virtio is getting standardised, but Xen PV is
> > implementation specific.
> 
> Does an interface need OASIS' rubber stamp to be "standard"?  If so, we
> should also drop FDT from this document. The SBSA has not been published
> by any OASIS-like standardization body either, so maybe we should drop
> the SBSA too.
> 
> If it doesn't need OASIS nice logo on the side to be a standard, then
> the Xen PV interfaces are a standard too. Give a look at
> xen/include/public/io, they go as back as 2004, and they have multiple
> different implementations of the frontends and backends in multiple
> operating systems today.
> 
> There is no reason why another hypervisor couldn't implement the same
> interface and in fact I know for a fact that it was considered for KVM.

Allow me to elaborate. I'm not trying to punish Xen here, but I'm
deliberately pushing back against "either/or" options in the spec. In
this case the spec says the VM must implement one of pl011 *or* virtio
*or* xenpv. That gives lots of implementation choice to VM projects.

The downside is that spec-compliant OSes are required to implement
support for *all three*. This is a non-issue for Linux guests because all
those drivers are already there*, but it a real cost for niche guests.

The reason why a cut-dowm pl011 exists in SBSA is to provide a
bare-minimum output device that is always available. I would be far
happier for this spec to not give the VMs an option at all here. Now
that I think about it, it probably isn't appropriate to allow
virtio-console to be an option either. It should flat out require the
cut-down pl011 register interface. Make everything else optional. 'sane'
linux distros will enable virtio-console and xenpv and the kernel should
use whichever it finds in normal operation. Then no matter what crazy
guest the user wants to run there is still a known-safe fallback for
console output when things go wrong.

* aside from the footprint required to enable all of them

I've just had another thought. In the majority of cases the fallback
pl011 won't get used by the guest anyway unless asked to because the
UEFI OS Loader (EFI_STUB for Linux) will use the UEFI console drivers.
I expect the Xen UEFI port will use xenpv, and the kvm UEFI port will
use virtio. After UEFI exit boot services the OS is responsible for it's
own console output. If it has drivers for virtio-console or xenpv, then
fine; it discovers the interface and all is good. But if it doesn't,
then the fallback will at least work.

g.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel