Re: [PATCH v2] mc146818rtc: fix timer interrupt reinjection

[Alex Williamson <alex.williamson@redhat.com>]

On Sun, 17 Nov 2019 01:20:19 -0200
Marcelo Tosatti <mtosatti@redhat.com> wrote:

> On Sat, Nov 16, 2019 at 01:58:55PM -0700, Alex Williamson wrote:
> > On Thu, 10 Oct 2019 09:30:08 -0300
> > Marcelo Tosatti <mtosatti@redhat.com> wrote:
> >   
> > > commit 369b41359af46bded5799c9ef8be2b641d92e043 broke timer interrupt
> > > reinjection when there is no period change by the guest.
> > > 
> > > In that case, old_period is 0, which ends up zeroing irq_coalesced
> > > (counter of reinjected interrupts).
> > > 
> > > The consequence is Windows 7 is unable to synchronize time via NTP.
> > > Easily reproducible by playing a fullscreen video with cirrus and VNC.
> > > 
> > > Fix by not updating s->irq_coalesced when old_period is 0.
> > > 
> > > V2: reorganize code (Paolo Bonzini)
> > > 
> > > Signed-off-by: Marcelo Tosatti <mtosatti@redhat.com>  
> > 
> > This causes a regression for me, my win10 VM with assigned GPU
> > experiences hangs and slowness with this.  Found via bisect, reverting
> > restores normal behavior.  libvirt uses this commandline:
> > 
> > /usr/local/bin/qemu-system-x86_64 \
> > -name guest=Steam-GeForce,debug-threads=on \
> > -S \
> > -object secret,id=masterKey0,format=raw,file=/var/lib/libvirt/qemu/domain-1-Steam-GeForce/master-key.aes \
> > -machine pc-i440fx-4.1,accel=kvm,usb=off,vmport=off,dump-guest-core=off \
> > -cpu host,hv-time,hv-relaxed,hv-vapic,hv-spinlocks=0x1fff,hv-vendor-id=KeenlyKVM,kvm=off \
> > -drive file=/usr/share/edk2/ovmf/OVMF_CODE.fd,if=pflash,format=raw,unit=0,readonly=on \
> > -drive file=/var/lib/libvirt/qemu/nvram/Steam_VARS.fd,if=pflash,format=raw,unit=1 \
> > -m 4096 \
> > -mem-prealloc \
> > -mem-path /dev/hugepages/libvirt/qemu/1-Steam-GeForce \
> > -overcommit mem-lock=off \
> > -smp 4,sockets=1,cores=2,threads=2 \
> > -uuid 2b417d4b-f25b-4522-a5be-e105f032f99c \
> > -display none \
> > -no-user-config \
> > -nodefaults \
> > -chardev socket,id=charmonitor,fd=38,server,nowait \
> > -mon chardev=charmonitor,id=monitor,mode=control \
> > -rtc base=localtime,driftfix=slew \
> > -global kvm-pit.lost_tick_policy=delay \
> > -no-hpet \
> > -no-shutdown \
> > -boot menu=on,strict=on \
> > -device nec-usb-xhci,id=usb,bus=pci.0,addr=0x8 \
> > -device virtio-scsi-pci,id=scsi0,num_queues=4,bus=pci.0,addr=0x5 \
> > -drive file=/mnt/ssd/Steam.qcow2,format=qcow2,if=none,id=drive-scsi0-0-0-0,cache=none \
> > -device scsi-hd,bus=scsi0.0,channel=0,scsi-id=0,lun=0,device_id=drive-scsi0-0-0-0,drive=drive-scsi0-0-0-0,id=scsi0-0-0-0,bootindex=2,write-cache=on \
> > -netdev tap,fd=40,id=hostnet0,vhost=on,vhostfd=41 \
> > -device virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:60:ef:ac,bus=pci.0,addr=0x3 \
> > -device vfio-pci,host=0000:01:00.0,id=hostdev0,bus=pci.0,addr=0x4,rombar=1 \
> > -device vfio-pci,host=0000:01:00.1,id=hostdev1,bus=pci.0,addr=0x6,rombar=0 \
> > -S \
> > -debugcon file:/tmp/Steam-ovmf-debug.log \
> > -global isa-debugcon.iobase=0x402 \
> > -set device.hostdev0.x-pci-vendor-id=0x10de \
> > -trace events=/var/lib/libvirt/images/Steam-GeForce.events \
> > -sandbox on,obsolete=deny,elevateprivileges=deny,spawn=deny,resourcecontrol=deny \
> > -msg timestamp=on  
> 
> Alex,
> 
> -rtc base=localtime,driftfix=none should fix it. Can you confirm?

How do I translate that to xml?  I'm currently using:

  <clock offset='localtime'>
    <timer name='rtc' tickpolicy='catchup'/>
    <timer name='pit' tickpolicy='delay'/>
    <timer name='hpet' present='no'/>
    <timer name='hypervclock' present='yes'/>
  </clock>

According to this[1] bz, 'catchup' translates to 'slew' and seems to be
the default policy in use.  The 'discard' option seemed the most
likely, but my VM fails to start with that:

error: unsupported configuration: unsupported rtc timer tickpolicy 'discard'

The 'merge' option gives me a similar error.  The 'delay' option is the
only other choice where I can actually start the VM, but this results in
the commandline:

-rtc base=localtime

(no driftfix specified)  This does appear to resolve the issue, but of
course compatibility with existing configurations has regressed.
Thanks,

Alex

[1] https://bugzilla.redhat.com/show_bug.cgi?id=865315