On 24.10.19 13:46, Rob Miller wrote: > Pls see below > > Rob Miller > rob.mil...@broadcom.com <mailto:rob.mil...@broadcom.com> > (919)721-3339 > > > On Thu, Oct 24, 2019 at 6:25 AM Jan Kiszka <jan.kis...@web.de > <mailto:jan.kis...@web.de>> wrote: > > On 23.10.19 23:23, Rob Miller via Xenomai wrote: > > Correction, stock images work by removing the enable-kvm and *NOT > *adding > > the -no-hpet QEMU cmdline options. > > > > also latency numbers are crazy with avg being 1678.126 usec w/ > worst case > > being 15463.240usec > > > > at this point, I'm not sure which way to go: > > > > 1) do I hunt down issues in HPET failing w/ KVM mode enabled? > > 2) just go to dovetail > > 3) ??? > > Don't have a the reference image around, but I'm pretty sure it would > work here with QEMU 4300b7c2cd9f3f273804e8cca325842ccb93b1ad (post 4.1) > and KVM from 5.3.6. At least a different image is being used like that > for ages, and kernel config in xenomai-image is basically derived > from it. > > RJM>] Will try > > > For the xenomai-images check, did you use "start-qemu.sh x86" as-is? > > RJM>] Yes, my 1st failed attempts used unmodified start-qemu.sh x86, > then I mod'd the file to remove the -enable-kvm, and it started to work > UNTIL also added -no-hpet, then I can't even boot up. >
Number of host cores >= number of guest CPUs? If not, reduce -smp in the QEMU invocation. Oh, and don't expect any kind of determinism in these setups. KVM and QEMU are for functional testing only. Jan
