[libvirt] [PATCH] qemu: Default hwclock source for sPAPR to RTC

[Cole Robinson]

On 07/13/2017 09:52 AM, Madhu Pavan wrote:
> 
> 
> On 07/13/2017 05:49 PM, Cole Robinson wrote:
>> On 07/13/2017 04:36 AM, Kothapally Madhu Pavan wrote:
>>> QEMU fails to launch a sPAPR guest with clock sources other that RTC.
>>> Internally qemu only uses RTC timer for hwclock. This patch reports
>>> the right error message instead of qemu erroring out when any other
>>> timer other than RTC is used.
>>>
>> How does it fail exactly? Is it a qemu error message or a guest OS failure?
>>
>> If it's from qemu, and the error message is reasonably clear what hardware/xml
>> config option is at fauly, then these checks don't add much functional
>> benefit, just more code to maintain.
> 
> If it's from qemu, and the error message is reasonably clear what hardware/xml
> config option is at fauly, then these checks don't add much functional
> benefit, just more code to maintain.
> 
> When we use kvmclock timer in domain xml as:
>   <clock offset='utc'>
>     <timer name='kvmclock' present='yes'/>
>   </clock>
> Domain fails to start with following error:
> #virsh start --console virt-tests-vm1
> error: Failed to start domain virt-tests-vm1
> error: internal error: process exited while connecting to monitor:
> 2017-04-25T09:31:58.180062Z qemu-system-ppc64: Unable to find CPU definition:
> qemu64
> 
> This is because the qemu cpu command line generated when kvmclock
> timer is used is:
>  -cpu qemu64,+kvmclock
> This happens because in qemuBuildCpuCommandLine has default_model = qemu64,
> When I corrected the default model to "host" for ppc64 machine,
> qemu cpu commandline generated is:
>  -cpu host,+kvmclock
> This is a valid qemu command for ppc64 machine. Now the qemu
> fails to start with folloeing error:
> qemu-system-ppc64: Expected key=value format, found +kvmclock.
> 

Hmm, well that qemu64 bit seems like something else to fix, but not a blocker
for this.

> Similarly when kvm-pit timer is used qemu warns as below:
> sudo ./qemu-system-ppc64 -name migrate_qemu -boot strict=on -device
> nec-usb-xhci,id=usb,bus=pci.0,addr=0xf -device spapr-vscsi,id=scsi0,reg=0x2000
> -smp 1,maxcpus=4,sockets=4,cores=1,threads=1 --machine
> pseries,accel=kvm,kvm-type=HV,usb=off,dump-guest-core=off -m
> 4G,slots=32,maxmem=32G -drive
> file=/home/danielhb/vm_imgs/ubuntu1704.qcow2,format=qcow2,if=none,id=drive-virtio-disk0,cache=none
> -device
> virtio-blk-pci,scsi=off,bus=pci.0,addr=0x2,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1
> -nographic -global kvm-pit.lost_tick_policy=discard
> 
> qemu-system-ppc64: Warning: global kvm-pit.lost_tick_policy has invalid class
> name
> 
> Basically, RTC is the only valid clocksource for sPAPR guests. For other clock
> sources
> qemu either errors out or internally considers RTC as default.
> 

If qemu just prints a warning in that case, then I agree we should explicitly
reject it in libvirt. Though that does mean that guests that were possibly
working before, but with a qemu warning, will now fail to redefine. Not sure
we care enough for this case though

>>
>> A general point, these types of checks should be considered for
>> qemuDomainDefValidate which adds the benefit of rejecting the config at XML
>> define time.
> I was of the opinion, the existing the domain definitions would fail to be
> parsed if I add
> in qemuDomainDefValidate(). Now, while I reply to you I realise, there is no
> way someone
> would have attempted to use non-RTC clock sources. So, its perfectly safe to
> move these
> checks to qemuDomainDefValidate().
> 
> Will attempt it in V2.
> 

That was the case at one point, but nowadays this is skipped when reading XML
from disk, see the VIR_DOMAIN_DEF_PARSE_SKIP_VALIDATE flag.

Thanks,
Cole