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

Rob Bradford robert.bradford at intel.com
Tue Dec 4 13:02:52 CET 2018


Hi Gerd,

On Mon, 2018-12-03 at 08:27 +0100, Gerd Hoffmann wrote:
> 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?

On the virt machine we don't use the kernel provided PIT emulation as
we don't call the KVM_CREATE_PIT[2] ioctls. Looking through the debug
output I can indeed see that Seabios is using the TSC/PIT code path.
However as we don't have a PIT present it's understandably getting the
frequency calculation wrong:

As can be seen from the debug output...

"""
tsc calibrate start=61956912 end=61961793 diff=4881
CPU Mhz=2
init timer
"""

As you can these numbers are wrong :-) so I definitely need to find a
better solution. As I mentioned below in the OVMF port I added a
version using KVM clock to calculate the TSC, that is definitely
workable for Seabios too. However i'm also thinking about proposing
adding the (counter only) ACPI timer in to the virt platform. As that
would not add much code and significantly simplify our firmware
changes.

> 
> > (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).
> 

This feedback makes sense.

> > > 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.
> 

Understood. What do you think about patches 3-5 which don't have any
virt machine specific details. Do you still think they could be merged?

Cheers,

Rob

> cheers,
>   Gerd
> 




More information about the SeaBIOS mailing list