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 -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
