Description of problem: when specify '-rtc ...,driftfix=slew' in the qemu command line, '(qemu) qemu-kvm: warning: global mc146818rtc.lost_tick_policy has invalid class name' is print out in hmp. Please note the guest could boot up normally. Version-Release number of selected component (if applicable): Host kernel: 4.18.0-85.el8.ppc64le Qemu: qemu-kvm-4.0.0-0.module+el8.1.0+3169+3c501422.ppc64le How reproducible: 100% Steps to Reproduce: 1. Boot up a guest with '-rtc ...t,driftfix=slew': /usr/libexec/qemu-kvm \ -name 'avocado-vt-vm1' \ -m 1024 \ -smp 2,maxcpus=2,cores=2,threads=1,sockets=1 \ -vnc :10 \ -rtc base=utc,clock=host,driftfix=slew \ -monitor stdio Actual results: It will prompt following warning info in hmp: # ./vm-timedevice.sh QEMU 4.0.0 monitor - type 'help' for more information (qemu) qemu-kvm: warning: global mc146818rtc.lost_tick_policy has invalid class name (qemu) Expected results: No the warning displayed Additional info: 1. Please note the bug has no relation with the 'base' type and 'clock' type in '-rtc' command line, it only has relation with 'driftfix=slew'; if I change it to 'driftfix=none', the bug disappears. 2. I have check the qemu src code, the warning info is included in file '../hw/core/qdev-properties.c', and it's not ppc specific.
I took a look at this. It's not really a bug with driftfix at all, but rather with the qemu legacy command line parsing. The -rtc driftfix=slew option is translated into setting an option on the mc146818rtc driver. But the pseries (POWER) machine doesn't use the mc146818rtc device (it has its own, builtin paravirt RTC). The easy answer here is simply to say this option is unsupported for power, not sure if that's acceptable. I'm not really sure how to fix it better. 1) There's no obvious corresponding behaviour we should have for driftfix for the pseries RTC 2) The -rtc option - like many of the legacy options - doesn't play very nicely with having different machine types with different setups
QEMU has been recently split into sub-components and as a one-time operation to avoid breakage of tools, we are setting the QEMU sub-component of this BZ to "General". Please review and change the sub-component if necessary the next time you review this BZ. Thanks
Marcelo, Do you actually want to do anything with this, or should we mark it WONTFIX or CANTFIX because of the factors from comment 2.
(In reply to David Gibson from comment #2) > I took a look at this. It's not really a bug with driftfix at all, but > rather with the qemu legacy command line parsing. > > The -rtc driftfix=slew option is translated into setting an option on the > mc146818rtc driver. But the pseries (POWER) machine doesn't use the > mc146818rtc device (it has its own, builtin paravirt RTC). > > The easy answer here is simply to say this option is unsupported for power, > not sure if that's acceptable. If RTC device is not used, i don't see why marking it as unsupported is a problem. > I'm not really sure how to fix it better. > 1) There's no obvious corresponding behaviour we should have for driftfix > for the pseries RTC This is for reinjecting lost timer interrupts. > 2) The -rtc option - like many of the legacy options - doesn't play very > nicely with having different machine types with different setups
(In reply to David Gibson from comment #5) > Marcelo, > > Do you actually want to do anything with this, or should we mark it WONTFIX > or CANTFIX because of the factors from comment 2. David, Nothing useful to be done, apparently. So WONTFIX/CANTFIX seem the right thing to do.
> If RTC device is not used, i don't see why marking it as unsupported is a problem. There is an RTC device (effectively), it's just not of the 'mc146818rtc' model specifically. But unless a customer gets confused by this, I don't see any value to worrying about it.