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