On 11.07.19 11:42, Andre Przywara wrote:
On Thu, 11 Jul 2019 09:52:42 +0200
Paolo Bonzini <pbonzini@xxxxxxxxxx> wrote:
Hi,
On 11/07/19 07:49, Alexander Graf wrote:
I agree that it would belong more in qtest, but tests in not exactly the
right place is better than no tests.
The problem with qtest is that it tests QEMU device models from a QEMU
internal view.
Not really: fundamentally it tests QEMU device models with stimuli that
come from another process in the host, rather than code that runs in a
guest. It does have hooks into QEMU's internal view (mostly to
intercept interrupts and advance the clocks), but the main feature of
the protocol is the ability to do memory reads and writes.
I am much more interested in the guest visible side of things. If
kvmtool wanted to implement a PL031, it should be able to execute the
same test that we run against QEMU, no?
One of the design goals of kvmtool is to get away with as little emulation
as possible, in favour of paravirtualisation (so it's just virtio and not
IDE/flash). So a hardware RTC emulation sounds dispensable in this context.
The main reason to have a PL031 exposed to a VM is to make OVMF happy,
so that it can provide wall clock time runtime services. I suppose that
sooner or later you may want to run OVMF in kvmtool as well, no?
The alternative to the PL031 here is to do a PV interface, yes. I'm not
really convinced that that would be any easier though. The PL031 is a
very trivial device. The only real downside is that it will wrap around
in 2038.
Alex
_______________________________________________
kvmarm mailing list
kvmarm@xxxxxxxxxxxxxxxxxxxxx
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
