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
The virt machine in the NEMU project has the
ambition to be a
that has no emulated legacy hardware. This patch series enables
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).
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
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
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
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).
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
General rule is still that we usually merge seabios support after the
qemu patches actually landed in qemu master.