On 11/07/2019 10: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. Funnily enough, kvmtool does have a RTC emulation (MC146818). The support code in Linux is so braindead that I gave up on it about 5 years ago. M. -- Jazz is not dead. It just smells funny...
