[SeaBIOS] RFC: Add support for virt machine to Seabios

[Gerd Hoffmann]

On Fri, Nov 30, 2018 at 02:46:57PM +0000, Rob Bradford wrote:
> Hi Gerd, thanks for you prompt reply,
> 
> On Fri, 2018-11-30 at 14:48 +0100, Gerd Hoffmann wrote:
> > On Thu, Nov 29, 2018 at 05:37:41PM +0000, Rob Bradford wrote:
> > > The virt machine in the NEMU project has the ambition to be a
> > > platform
> > > that has no emulated legacy hardware. This patch series enables
> > > support
> > > for that machine type in Seabios.
> > 
> > What exactly does "no legacy hardware" mean?  Does that include lpc
> > devices such as pit and pic?
> 
> That is correct, the host Linux kernel does provide some emulation of
> devices as part of KVM though.

Which is configurable though (-M kernel_irqchip=on|off|split).

> > What will seabios use as time source with -M virt?
> > Seems there is no pmtimer ...
> 
> That is correct. There does not appear to negative side effects with
> lack of a time source when running Seabios against virt

Well, if there is no pmtimer seabios will use tsc, calibrated using pit
(see src/hw/timer.c).

That works ok most of the time, but sometimes it doesn't.  When booting
a guest on a loaded host it may happen that the vcpu gets scheduled away
while running the calibration loop and the calibration can be *way* off
because of that.

pmtimer is simple and reliable (fixed frequency, so no calibration
needed).  So, with that not being available having some other reliable
time source would be very useful.  kvmclock maybe?

> (In the OVMF port I implement MicroSleep/NanoSleep with a KVM pvclock
> and TSC based solution but i'm currently evaluating if this can be a
> no-op as sleeping in a firmware is usually part of programming physical
> hardware which is something that is not required with the virt machine
> type.)

Programming the virtual hardware maybe doesn't need exact timing.
But you still need working timeouts for anything which can trigger
actual I/O on the host.  Read a block from disk.  Wait for a DHCP
response.

Or the three seconds we wait for a keypress with "-boot menu=on".

So, I don't think there is a way around having a reliable time source
even on virtual hardware.  Also note that you might have physical
hardware in a virtual machine (via pci passthrough for example).

> > Doing that makes sense anyway, I'd say these three patches can be
> > merged.  The other two should wait until the qemu patches are merged,
> > to be sure the pci ids are the final ones.
> > 
> 
> This PCI ID (0x8086 / 0x0d57) is from our internal registry which is
> allocated exclusively for the use of the PCI host bridge on the virt
> platform.

Good.

General rule is still that we usually merge seabios support after the
qemu patches actually landed in qemu master.

cheers,
  Gerd