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