x86_64 kernel does not start under qemu

Jan Kiszka jan.kiszka at siemens.com
Thu Mar 21 12:02:45 CET 2019

On 08.03.19 12:28, Jan Kiszka wrote:
> On 08.03.19 12:19, Richard Weinberger wrote:
>> Am Mittwoch, 6. März 2019, 17:39:38 CET schrieb Jan Kiszka:
>>> On 06.03.19 16:33, Richard Weinberger wrote:
>>>> Am Mittwoch, 6. März 2019, 14:43:55 CET schrieb Jan Kiszka:
>>>>> On 06.03.19 14:10, Jan Kiszka wrote:
>>>>>> On 06.03.19 12:28, Lange Norbert via Xenomai wrote:
>>>>>>> Hello,
>>>>>>> I have a similar issue on real hardware (cc Philippe). Can you try booting
>>>>>>> with notscdeadline?
>>>>>> I would be surprised if it's that: QEMU does not emulate this APIC 
>>>>>> feature, only
>>>>>> KVM does.
>>>>>> I need to reproduce. Which QEMU version?
>>>>> Just booted current ipipe-x86-4.14.y (4.14.103) in QEMU 3.1+ (some development
>>>>> snapshot) with -smp 4 - works fine. But these are likely quite a few 
>>>>> variations
>>>>> from your setup.
>>>> I'm on qemu 2.11.2.
>>> That one might still be serializing SMP, thus only use one core on the host.
>> Well, why is this a problem for Xenomai?
>> Does it deadlock if you have more than one cpu and these are not truly parallel?
>> This seems a little odd to me.
> I the past, this de-parallelization triggered race conditions more easily as it 
> widened the race windows massively. Whatever came out of it remained a Xenomai 
> or I-pipe bug that could theoretically occur on real hardware as well.
>>> Currently trying to emulate that as it changes timing.
>> Just retried with latest qemu (v3.1.0-2421-g9b748c5e061b), same problem.
> Yeah, I suspect the kernel config. Didn't have time to try defconfig so far.
>>>> Is this plain ipipe? Just figured that you need to prepare the kernel
>>>> with Xenomai to trigger the problem.
>>>> Xenomai is 3.0.8.
>>> I have Xenomai stable/v3.0.x running as well.
>> What kernel config are you using and what is your qemu command line?
> Currently used config attached, command line:
> qemu-system-x86_64 -drive file=/path/disk.img,discard=unmap,if=none,id=disk 
> -device ide-hd,drive=disk -snapshot -m 1G -serial mon:stdio -s -smp 4 -machine 
> q35,pit=off -fsdev local,path=/path/shared,security_model=none,id=vfs -device 
> virtio-9p-pci,addr=1f.7,mount_tag=host,fsdev=vfs

FWIW, I've just seen this issue as well, with QEMU in KVM mode: I ran into that 
lockup when my host was under full load while Xenomai booted in the VM. And it 
seems reproducible. Debugging...


Siemens AG, Corporate Technology, CT RDA IOT SES-DE
Corporate Competence Center Embedded Linux

More information about the Xenomai mailing list