[Kata-hypervisor] Link to the Hypervisor Prototype

Samuel Ortiz samuel.ortiz at intel.com
Thu Jun 14 10:53:57 UTC 2018

On Wed, Jun 13, 2018 at 07:25:10PM +0200, Paolo Bonzini wrote:
> On 13/06/2018 18:54, Samuel Ortiz wrote:
> > This is
> > going to be a simplified, emulation free and virtual hardware based
> > machine type for running modern cloud and container workloads.
> > We believe that this new machine type will allow us to reduce even
> > further the number of devices that QEMU needs to support in order to run
> > this kind of workloads.
> > 
> > We will start by implementing this new machine type on top of an
> > upstream QEMU code base, as we hope that this could become upstream
> > acceptable material.
> > Then we will re-run our automatic code reduction tooling on top of a
> > QEMU code base that would only support this machine type and the ARM
> > virt one. This will become the new NEMU master branch.
> Some notes:
> - the ARM virt machine type is not a "virtual hardware platform".  It
> has PL011 serial, PL031 RTC, PL061 GPIO controller, a generic PCIe
> bridge, fw_cfg for the firmware to get data from QEMU, and emulated
> flash.  The idea behind the ARM virt machine type is simply to make
> everything discoverable via device tree; the "virtualness" of it is
> simply that the device tree is provided by QEMU and not embedded into
> something like U-Boot or Linux.
Yes, we're aware of that. It's also one of the very few ARM machine type
that does not map to an existing SoC.
On that topic, one question: Would you be accepting patches for
optionally making the ARM virt machine discoverable through ACPI only?
Booting an ARM64 kernel on top of that should work in theory at least.

> - support for legacy BIOS is irrelevant to QEMU; if any developer wants
> to port SeaBIOS to this new machine, why not?
Oh absolutely. It's just that this is not something we'll work on
initially but obviously everyone is free to add BIOS support for this
new machine.

> - UEFI runtime services need to provide an RTC, so you need to emulate one.
Ok. I was not awatre of that, thanks.

> - without MCH, you'll have to find a different way to handle SMRAM.
> - no ISA means no serial port for early boot messages, no debug port for
> firmware logs, and more painful debugging in general.  I'm not sure
> that's a good idea.  Of course you don't want any IDE or floppy crap,
> but that's orthogonal to having ISA.
Yes, I forgot to add it to the github issue (I'll fix that), but we do
want to add basic support for a PIO based serial port for early
debugging. Output only.

> IMNSHO, a more interesting starting point would be to upstream the
> patches to remove legacy devices from the binary (e.g. the infamous floppy).
I think this is not exclusive, we can do both.

Intel Corporation SAS (French simplified joint stock company)
Registered headquarters: "Les Montalets"- 2, rue de Paris, 
92196 Meudon Cedex, France
Registration Number:  302 456 199 R.C.S. NANTERRE
Capital: 4,572,000 Euros

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.

More information about the Kata-hypervisor mailing list