Xenomai fails to start when running in QEMU VM

Xenomai fails to start when running in QEMU VM

[Rob Miller]

Things were working well with my server but when I went to a VM, it fails
complaining about no high-res timers.

I figure it must be a CPU that I have chosen and am wondering what others
are using. I googled for quite a while but can't seem to find any info so I
thought I would post here for some advice.

Rob Miller
rob.miller@broadcom.com
(919)721-3339

Re: Xenomai fails to start when running in QEMU VM

[Jan Kiszka]

On 11.10.19 19:25, Rob Miller via Xenomai wrote:
> Things were working well with my server but when I went to a VM, it fails
> complaining about no high-res timers.
> 
> I figure it must be a CPU that I have chosen and am wondering what others
> are using. I googled for quite a while but can't seem to find any info so I
> thought I would post here for some advice.
> 

Have a look at https://gitlab.denx.de/Xenomai/xenomai-images for working 
configurations for x86, ARM and ARM64 as well as the related QEMU 
parameters - or use that image directly.

Jan

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

Re: Xenomai fails to start when running in QEMU VM

[Rob Miller]

Interestingly, I also get the exact same failure on the xenomai-images
pulled from the git repo.

the errors start right off the bat with:

tsc: Fast calibration failed
tsc: Unable to calibrate against PIT
tsc: No reference (HPET/PMTIMER) available
..
..
clocksource: hpet: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns:
19112604467 ns
hpet clock event registered
tsc: Fast calibration failed
tsc: Unable to calibrate against PIT
tsc: No reference (HPET/PMTIMER) available
tsc: Marking TSC unstable due to could not calculate TSC khz          <---
kiss of death I believe as Cobalt sees the flag and errors out
..
..
hpet0: at MMIO 0xfed00000, IRQs 2, 8, 0
hpet0: 3 comparators , 64-bit 100.000000 MHz counter
clocksource: Switched to clocksource hpet
..
..
[Xenomai] scheduling class idle registered
[Xenomai] scheduling class weak registered
[Xenomai] scheduling class tp registered
[Xenomai] scheduling class pss registered
[Xenomai] scheduling class quota registered
[Xenomai] scheduling class rt registered
I-pipe: high-resolution clock not working               <--- I believe this
looks at the TSC marked as being unstable flag set above and bails out
[Xenomai] init failed, code -19

I dug into the unstable issues on my VM (ie: non xenomai-images repo), and
found that tsc_read_refs(*ref, hpet) is where the problem lies in either
whether using using hpet or not, either the returned ref value is 0 (when
hpet == 1), or the amount of time is took to read from PM (hpet == 0) took
forever (ie: 100000+ cycles) which is at least 2x the SMI_THRESHOLD vlaue
that is allowed in the code. My guess is that even when using the stock
xenomai-images directly, I'll have the same situation.

I read about SMI issues, and given the cycle allowance for SMI
interruptions in the tsc_read_refs() functio, I focused on SMI. In my VM
(ie: non-stock images), I set the linux cmdline option
xenomai.smi=disabled, but no love there either.

Given that both my VM and the stock images fail, I'm now thinking QEMU
version, or underlying host CPU issues, or TBD, is the issue, and thought
I'd first ask the community for guidance as to how to proceed.

Thoughts ideas will be greatly appreciated.


Rob Miller
rob.miller@broadcom.com
(919)721-3339


On Fri, Oct 11, 2019 at 1:32 PM Jan Kiszka <jan.kiszka@siemens.com> wrote:

> On 11.10.19 19:25, Rob Miller via Xenomai wrote:
> > Things were working well with my server but when I went to a VM, it fails
> > complaining about no high-res timers.
> >
> > I figure it must be a CPU that I have chosen and am wondering what others
> > are using. I googled for quite a while but can't seem to find any info
> so I
> > thought I would post here for some advice.
> >
>
> Have a look at https://gitlab.denx.de/Xenomai/xenomai-images for working
> configurations for x86, ARM and ARM64 as well as the related QEMU
> parameters - or use that image directly.
>
> Jan
>
> --
> Siemens AG, Corporate Technology, CT RDA IOT SES-DE
> Corporate Competence Center Embedded Linux
>

Re: Xenomai fails to start when running in QEMU VM

[Gylstorff Quirin]

On 10/23/19 2:48 PM, Rob Miller via Xenomai wrote:
> Interestingly, I also get the exact same failure on the xenomai-images
> pulled from the git repo.
> 
> the errors start right off the bat with:
> 
> tsc: Fast calibration failed
> tsc: Unable to calibrate against PIT
> tsc: No reference (HPET/PMTIMER) available
> ..
> ..
> clocksource: hpet: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns:
> 19112604467 ns
> hpet clock event registered
> tsc: Fast calibration failed
> tsc: Unable to calibrate against PIT
> tsc: No reference (HPET/PMTIMER) available
> tsc: Marking TSC unstable due to could not calculate TSC khz          <---
> kiss of death I believe as Cobalt sees the flag and errors out
> ..
> ..
> hpet0: at MMIO 0xfed00000, IRQs 2, 8, 0
> hpet0: 3 comparators , 64-bit 100.000000 MHz counter
> clocksource: Switched to clocksource hpet
> ..
> ..
> [Xenomai] scheduling class idle registered
> [Xenomai] scheduling class weak registered
> [Xenomai] scheduling class tp registered
> [Xenomai] scheduling class pss registered
> [Xenomai] scheduling class quota registered
> [Xenomai] scheduling class rt registered
> I-pipe: high-resolution clock not working               <--- I believe this
> looks at the TSC marked as being unstable flag set above and bails out
> [Xenomai] init failed, code -19
> 
> I dug into the unstable issues on my VM (ie: non xenomai-images repo), and
> found that tsc_read_refs(*ref, hpet) is where the problem lies in either
> whether using using hpet or not, either the returned ref value is 0 (when
> hpet == 1), or the amount of time is took to read from PM (hpet == 0) took
> forever (ie: 100000+ cycles) which is at least 2x the SMI_THRESHOLD vlaue
> that is allowed in the code. My guess is that even when using the stock
> xenomai-images directly, I'll have the same situation.
> 
> I read about SMI issues, and given the cycle allowance for SMI
> interruptions in the tsc_read_refs() functio, I focused on SMI. In my VM
> (ie: non-stock images), I set the linux cmdline option
> xenomai.smi=disabled, but no love there either.
> 
> Given that both my VM and the stock images fail, I'm now thinking QEMU
> version, or underlying host CPU issues, or TBD, is the issue, and thought
> I'd first ask the community for guidance as to how to proceed.
> 
> Thoughts ideas will be greatly appreciated.
> 
What qemu version do you use?

For our tests we use
QEMU emulator version 3.1.0 (Debian 1:3.1+dfsg-8+deb10u2).


Quirin

-- 
Siemens AG
Corporate Technology
CT RDA IOT SES-DE

Re: Xenomai fails to start when running in QEMU VM

[Rob Miller]

Mine a little newer

QEMU emulator version 4.0.50
Copyright (c) 2003-2019 Fabrice Bellard and the QEMU Project developers

Rob Miller
rob.miller@broadcom.com
(919)721-3339


On Wed, Oct 23, 2019 at 9:26 AM Gylstorff Quirin via Xenomai <
xenomai@xenomai.org> wrote:

>
>
> On 10/23/19 2:48 PM, Rob Miller via Xenomai wrote:
> > Interestingly, I also get the exact same failure on the xenomai-images
> > pulled from the git repo.
> >
> > the errors start right off the bat with:
> >
> > tsc: Fast calibration failed
> > tsc: Unable to calibrate against PIT
> > tsc: No reference (HPET/PMTIMER) available
> > ..
> > ..
> > clocksource: hpet: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns:
> > 19112604467 ns
> > hpet clock event registered
> > tsc: Fast calibration failed
> > tsc: Unable to calibrate against PIT
> > tsc: No reference (HPET/PMTIMER) available
> > tsc: Marking TSC unstable due to could not calculate TSC khz
> <---
> > kiss of death I believe as Cobalt sees the flag and errors out
> > ..
> > ..
> > hpet0: at MMIO 0xfed00000, IRQs 2, 8, 0
> > hpet0: 3 comparators , 64-bit 100.000000 MHz counter
> > clocksource: Switched to clocksource hpet
> > ..
> > ..
> > [Xenomai] scheduling class idle registered
> > [Xenomai] scheduling class weak registered
> > [Xenomai] scheduling class tp registered
> > [Xenomai] scheduling class pss registered
> > [Xenomai] scheduling class quota registered
> > [Xenomai] scheduling class rt registered
> > I-pipe: high-resolution clock not working               <--- I believe
> this
> > looks at the TSC marked as being unstable flag set above and bails out
> > [Xenomai] init failed, code -19
> >
> > I dug into the unstable issues on my VM (ie: non xenomai-images repo),
> and
> > found that tsc_read_refs(*ref, hpet) is where the problem lies in either
> > whether using using hpet or not, either the returned ref value is 0 (when
> > hpet == 1), or the amount of time is took to read from PM (hpet == 0)
> took
> > forever (ie: 100000+ cycles) which is at least 2x the SMI_THRESHOLD vlaue
> > that is allowed in the code. My guess is that even when using the stock
> > xenomai-images directly, I'll have the same situation.
> >
> > I read about SMI issues, and given the cycle allowance for SMI
> > interruptions in the tsc_read_refs() functio, I focused on SMI. In my VM
> > (ie: non-stock images), I set the linux cmdline option
> > xenomai.smi=disabled, but no love there either.
> >
> > Given that both my VM and the stock images fail, I'm now thinking QEMU
> > version, or underlying host CPU issues, or TBD, is the issue, and thought
> > I'd first ask the community for guidance as to how to proceed.
> >
> > Thoughts ideas will be greatly appreciated.
> >
> What qemu version do you use?
>
> For our tests we use
> QEMU emulator version 3.1.0 (Debian 1:3.1+dfsg-8+deb10u2).
>
>
> Quirin
>
> --
> Siemens AG
> Corporate Technology
> CT RDA IOT SES-DE
>
>
>
>

Re: Xenomai fails to start when running in QEMU VM

[Rob Miller]

I found that if I remove the -enable-kvm and add -no-hpet, I'm able to get
Xenomi up-n-running on the stock xenomai-images. Adding -no-hpet alone
didn't help. Also, when the enable-kvm is disabled, the bootup time is
~10-20 slower, but does boot.

Further, just removing the enable-kvm flag, results in the stock image
never booting...or at least I gave up after 5 min's waiting.

I will try to downgrade QEMU to 3.1.0

Rob Miller
rob.miller@broadcom.com
(919)721-3339


On Wed, Oct 23, 2019 at 12:07 PM Rob Miller <rob.miller@broadcom.com> wrote:

> Mine a little newer
>
> QEMU emulator version 4.0.50
> Copyright (c) 2003-2019 Fabrice Bellard and the QEMU Project developers
>
> Rob Miller
> rob.miller@broadcom.com
> (919)721-3339
>
>
> On Wed, Oct 23, 2019 at 9:26 AM Gylstorff Quirin via Xenomai <
> xenomai@xenomai.org> wrote:
>
>>
>>
>> On 10/23/19 2:48 PM, Rob Miller via Xenomai wrote:
>> > Interestingly, I also get the exact same failure on the xenomai-images
>> > pulled from the git repo.
>> >
>> > the errors start right off the bat with:
>> >
>> > tsc: Fast calibration failed
>> > tsc: Unable to calibrate against PIT
>> > tsc: No reference (HPET/PMTIMER) available
>> > ..
>> > ..
>> > clocksource: hpet: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns:
>> > 19112604467 ns
>> > hpet clock event registered
>> > tsc: Fast calibration failed
>> > tsc: Unable to calibrate against PIT
>> > tsc: No reference (HPET/PMTIMER) available
>> > tsc: Marking TSC unstable due to could not calculate TSC khz
>> <---
>> > kiss of death I believe as Cobalt sees the flag and errors out
>> > ..
>> > ..
>> > hpet0: at MMIO 0xfed00000, IRQs 2, 8, 0
>> > hpet0: 3 comparators , 64-bit 100.000000 MHz counter
>> > clocksource: Switched to clocksource hpet
>> > ..
>> > ..
>> > [Xenomai] scheduling class idle registered
>> > [Xenomai] scheduling class weak registered
>> > [Xenomai] scheduling class tp registered
>> > [Xenomai] scheduling class pss registered
>> > [Xenomai] scheduling class quota registered
>> > [Xenomai] scheduling class rt registered
>> > I-pipe: high-resolution clock not working               <--- I believe
>> this
>> > looks at the TSC marked as being unstable flag set above and bails out
>> > [Xenomai] init failed, code -19
>> >
>> > I dug into the unstable issues on my VM (ie: non xenomai-images repo),
>> and
>> > found that tsc_read_refs(*ref, hpet) is where the problem lies in either
>> > whether using using hpet or not, either the returned ref value is 0
>> (when
>> > hpet == 1), or the amount of time is took to read from PM (hpet == 0)
>> took
>> > forever (ie: 100000+ cycles) which is at least 2x the SMI_THRESHOLD
>> vlaue
>> > that is allowed in the code. My guess is that even when using the stock
>> > xenomai-images directly, I'll have the same situation.
>> >
>> > I read about SMI issues, and given the cycle allowance for SMI
>> > interruptions in the tsc_read_refs() functio, I focused on SMI. In my VM
>> > (ie: non-stock images), I set the linux cmdline option
>> > xenomai.smi=disabled, but no love there either.
>> >
>> > Given that both my VM and the stock images fail, I'm now thinking QEMU
>> > version, or underlying host CPU issues, or TBD, is the issue, and
>> thought
>> > I'd first ask the community for guidance as to how to proceed.
>> >
>> > Thoughts ideas will be greatly appreciated.
>> >
>> What qemu version do you use?
>>
>> For our tests we use
>> QEMU emulator version 3.1.0 (Debian 1:3.1+dfsg-8+deb10u2).
>>
>>
>> Quirin
>>
>> --
>> Siemens AG
>> Corporate Technology
>> CT RDA IOT SES-DE
>>
>>
>>
>>

Re: Xenomai fails to start when running in QEMU VM

[Rob Miller]

Downgrading to 3.1.0 doesn't help

so in summary, removing the enable-kvm cmdline option and adding -no-hpet
seems to allow Xenomai to startup at least. Will now start the latency
tests, ect...

Rob Miller
rob.miller@broadcom.com
(919)721-3339


On Wed, Oct 23, 2019 at 3:52 PM Rob Miller <rob.miller@broadcom.com> wrote:

> I found that if I remove the -enable-kvm and add -no-hpet, I'm able to get
> Xenomi up-n-running on the stock xenomai-images. Adding -no-hpet alone
> didn't help. Also, when the enable-kvm is disabled, the bootup time is
> ~10-20 slower, but does boot.
>
> Further, just removing the enable-kvm flag, results in the stock image
> never booting...or at least I gave up after 5 min's waiting.
>
> I will try to downgrade QEMU to 3.1.0
>
> Rob Miller
> rob.miller@broadcom.com
> (919)721-3339
>
>
> On Wed, Oct 23, 2019 at 12:07 PM Rob Miller <rob.miller@broadcom.com>
> wrote:
>
>> Mine a little newer
>>
>> QEMU emulator version 4.0.50
>> Copyright (c) 2003-2019 Fabrice Bellard and the QEMU Project developers
>>
>> Rob Miller
>> rob.miller@broadcom.com
>> (919)721-3339
>>
>>
>> On Wed, Oct 23, 2019 at 9:26 AM Gylstorff Quirin via Xenomai <
>> xenomai@xenomai.org> wrote:
>>
>>>
>>>
>>> On 10/23/19 2:48 PM, Rob Miller via Xenomai wrote:
>>> > Interestingly, I also get the exact same failure on the xenomai-images
>>> > pulled from the git repo.
>>> >
>>> > the errors start right off the bat with:
>>> >
>>> > tsc: Fast calibration failed
>>> > tsc: Unable to calibrate against PIT
>>> > tsc: No reference (HPET/PMTIMER) available
>>> > ..
>>> > ..
>>> > clocksource: hpet: mask: 0xffffffff max_cycles: 0xffffffff,
>>> max_idle_ns:
>>> > 19112604467 ns
>>> > hpet clock event registered
>>> > tsc: Fast calibration failed
>>> > tsc: Unable to calibrate against PIT
>>> > tsc: No reference (HPET/PMTIMER) available
>>> > tsc: Marking TSC unstable due to could not calculate TSC khz
>>> <---
>>> > kiss of death I believe as Cobalt sees the flag and errors out
>>> > ..
>>> > ..
>>> > hpet0: at MMIO 0xfed00000, IRQs 2, 8, 0
>>> > hpet0: 3 comparators , 64-bit 100.000000 MHz counter
>>> > clocksource: Switched to clocksource hpet
>>> > ..
>>> > ..
>>> > [Xenomai] scheduling class idle registered
>>> > [Xenomai] scheduling class weak registered
>>> > [Xenomai] scheduling class tp registered
>>> > [Xenomai] scheduling class pss registered
>>> > [Xenomai] scheduling class quota registered
>>> > [Xenomai] scheduling class rt registered
>>> > I-pipe: high-resolution clock not working               <--- I believe
>>> this
>>> > looks at the TSC marked as being unstable flag set above and bails out
>>> > [Xenomai] init failed, code -19
>>> >
>>> > I dug into the unstable issues on my VM (ie: non xenomai-images repo),
>>> and
>>> > found that tsc_read_refs(*ref, hpet) is where the problem lies in
>>> either
>>> > whether using using hpet or not, either the returned ref value is 0
>>> (when
>>> > hpet == 1), or the amount of time is took to read from PM (hpet == 0)
>>> took
>>> > forever (ie: 100000+ cycles) which is at least 2x the SMI_THRESHOLD
>>> vlaue
>>> > that is allowed in the code. My guess is that even when using the stock
>>> > xenomai-images directly, I'll have the same situation.
>>> >
>>> > I read about SMI issues, and given the cycle allowance for SMI
>>> > interruptions in the tsc_read_refs() functio, I focused on SMI. In my
>>> VM
>>> > (ie: non-stock images), I set the linux cmdline option
>>> > xenomai.smi=disabled, but no love there either.
>>> >
>>> > Given that both my VM and the stock images fail, I'm now thinking QEMU
>>> > version, or underlying host CPU issues, or TBD, is the issue, and
>>> thought
>>> > I'd first ask the community for guidance as to how to proceed.
>>> >
>>> > Thoughts ideas will be greatly appreciated.
>>> >
>>> What qemu version do you use?
>>>
>>> For our tests we use
>>> QEMU emulator version 3.1.0 (Debian 1:3.1+dfsg-8+deb10u2).
>>>
>>>
>>> Quirin
>>>
>>> --
>>> Siemens AG
>>> Corporate Technology
>>> CT RDA IOT SES-DE
>>>
>>>
>>>
>>>

Re: Xenomai fails to start when running in QEMU VM

[Rob Miller]

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) ???


Rob Miller
rob.miller@broadcom.com
(919)721-3339


On Wed, Oct 23, 2019 at 5:02 PM Rob Miller <rob.miller@broadcom.com> wrote:

> Downgrading to 3.1.0 doesn't help
>
> so in summary, removing the enable-kvm cmdline option and adding -no-hpet
> seems to allow Xenomai to startup at least. Will now start the latency
> tests, ect...
>
> Rob Miller
> rob.miller@broadcom.com
> (919)721-3339
>
>
> On Wed, Oct 23, 2019 at 3:52 PM Rob Miller <rob.miller@broadcom.com>
> wrote:
>
>> I found that if I remove the -enable-kvm and add -no-hpet, I'm able to
>> get Xenomi up-n-running on the stock xenomai-images. Adding -no-hpet alone
>> didn't help. Also, when the enable-kvm is disabled, the bootup time is
>> ~10-20 slower, but does boot.
>>
>> Further, just removing the enable-kvm flag, results in the stock image
>> never booting...or at least I gave up after 5 min's waiting.
>>
>> I will try to downgrade QEMU to 3.1.0
>>
>> Rob Miller
>> rob.miller@broadcom.com
>> (919)721-3339
>>
>>
>> On Wed, Oct 23, 2019 at 12:07 PM Rob Miller <rob.miller@broadcom.com>
>> wrote:
>>
>>> Mine a little newer
>>>
>>> QEMU emulator version 4.0.50
>>> Copyright (c) 2003-2019 Fabrice Bellard and the QEMU Project developers
>>>
>>> Rob Miller
>>> rob.miller@broadcom.com
>>> (919)721-3339
>>>
>>>
>>> On Wed, Oct 23, 2019 at 9:26 AM Gylstorff Quirin via Xenomai <
>>> xenomai@xenomai.org> wrote:
>>>
>>>>
>>>>
>>>> On 10/23/19 2:48 PM, Rob Miller via Xenomai wrote:
>>>> > Interestingly, I also get the exact same failure on the xenomai-images
>>>> > pulled from the git repo.
>>>> >
>>>> > the errors start right off the bat with:
>>>> >
>>>> > tsc: Fast calibration failed
>>>> > tsc: Unable to calibrate against PIT
>>>> > tsc: No reference (HPET/PMTIMER) available
>>>> > ..
>>>> > ..
>>>> > clocksource: hpet: mask: 0xffffffff max_cycles: 0xffffffff,
>>>> max_idle_ns:
>>>> > 19112604467 ns
>>>> > hpet clock event registered
>>>> > tsc: Fast calibration failed
>>>> > tsc: Unable to calibrate against PIT
>>>> > tsc: No reference (HPET/PMTIMER) available
>>>> > tsc: Marking TSC unstable due to could not calculate TSC khz
>>>> <---
>>>> > kiss of death I believe as Cobalt sees the flag and errors out
>>>> > ..
>>>> > ..
>>>> > hpet0: at MMIO 0xfed00000, IRQs 2, 8, 0
>>>> > hpet0: 3 comparators , 64-bit 100.000000 MHz counter
>>>> > clocksource: Switched to clocksource hpet
>>>> > ..
>>>> > ..
>>>> > [Xenomai] scheduling class idle registered
>>>> > [Xenomai] scheduling class weak registered
>>>> > [Xenomai] scheduling class tp registered
>>>> > [Xenomai] scheduling class pss registered
>>>> > [Xenomai] scheduling class quota registered
>>>> > [Xenomai] scheduling class rt registered
>>>> > I-pipe: high-resolution clock not working               <--- I
>>>> believe this
>>>> > looks at the TSC marked as being unstable flag set above and bails out
>>>> > [Xenomai] init failed, code -19
>>>> >
>>>> > I dug into the unstable issues on my VM (ie: non xenomai-images
>>>> repo), and
>>>> > found that tsc_read_refs(*ref, hpet) is where the problem lies in
>>>> either
>>>> > whether using using hpet or not, either the returned ref value is 0
>>>> (when
>>>> > hpet == 1), or the amount of time is took to read from PM (hpet == 0)
>>>> took
>>>> > forever (ie: 100000+ cycles) which is at least 2x the SMI_THRESHOLD
>>>> vlaue
>>>> > that is allowed in the code. My guess is that even when using the
>>>> stock
>>>> > xenomai-images directly, I'll have the same situation.
>>>> >
>>>> > I read about SMI issues, and given the cycle allowance for SMI
>>>> > interruptions in the tsc_read_refs() functio, I focused on SMI. In my
>>>> VM
>>>> > (ie: non-stock images), I set the linux cmdline option
>>>> > xenomai.smi=disabled, but no love there either.
>>>> >
>>>> > Given that both my VM and the stock images fail, I'm now thinking QEMU
>>>> > version, or underlying host CPU issues, or TBD, is the issue, and
>>>> thought
>>>> > I'd first ask the community for guidance as to how to proceed.
>>>> >
>>>> > Thoughts ideas will be greatly appreciated.
>>>> >
>>>> What qemu version do you use?
>>>>
>>>> For our tests we use
>>>> QEMU emulator version 3.1.0 (Debian 1:3.1+dfsg-8+deb10u2).
>>>>
>>>>
>>>> Quirin
>>>>
>>>> --
>>>> Siemens AG
>>>> Corporate Technology
>>>> CT RDA IOT SES-DE
>>>>
>>>>
>>>>
>>>>

Re: Xenomai fails to start when running in QEMU VM

[Jan Kiszka]

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.

For the xenomai-images check, did you use "start-qemu.sh x86" as-is?

Jan

Re: Xenomai fails to start when running in QEMU VM

[Rob Miller]

Pls see below

Rob Miller
rob.miller@broadcom.com
(919)721-3339


On Thu, Oct 24, 2019 at 6:25 AM Jan Kiszka <jan.kiszka@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.

>
> Jan
>

Re: Xenomai fails to start when running in QEMU VM

[Jan Kiszka]

On 24.10.19 13:46, Rob Miller wrote:
> Pls see below
>
> Rob Miller
> rob.miller@broadcom.com <mailto:rob.miller@broadcom.com>
> (919)721-3339
>
>
> On Thu, Oct 24, 2019 at 6:25 AM Jan Kiszka <jan.kiszka@web.de
> <mailto:jan.kiszka@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

Re: Xenomai fails to start when running in QEMU VM

[Rob Miller]

responses in-line...

Rob Miller
rob.miller@broadcom.com
(919)721-3339


On Thu, Oct 24, 2019 at 8:12 AM Jan Kiszka <jan.kiszka@web.de> wrote:

> On 24.10.19 13:46, Rob Miller wrote:
> > Pls see below
> >
> > Rob Miller
> > rob.miller@broadcom.com <mailto:rob.miller@broadcom.com>
> > (919)721-3339
> >
> >
> > On Thu, Oct 24, 2019 at 6:25 AM Jan Kiszka <jan.kiszka@web.de
> > <mailto:jan.kiszka@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.
>
RJM>] yup, host has 16 cores whilst guest has 4 (using the stock images).

>
> Oh, and don't expect any kind of determinism in these setups. KVM and
> QEMU are for functional testing only.
>
RJM>] Ah, good to know.

>
> Jan
>

Re: Xenomai fails to start when running in QEMU VM

[Henning Schild]

Can you provide some more detail on the host-machine? What hardware,
which kernel are you using, where is the kernel config coming from?

There must be something "unusual" in your setup.

Henning

Am Thu, 24 Oct 2019 09:38:23 -0400
schrieb Rob Miller via Xenomai <xenomai@xenomai.org>:

> responses in-line...
> 
> Rob Miller
> rob.miller@broadcom.com
> (919)721-3339
> 
> 
> On Thu, Oct 24, 2019 at 8:12 AM Jan Kiszka <jan.kiszka@web.de> wrote:
> 
> > On 24.10.19 13:46, Rob Miller wrote:  
> > > Pls see below
> > >
> > > Rob Miller
> > > rob.miller@broadcom.com <mailto:rob.miller@broadcom.com>
> > > (919)721-3339
> > >
> > >
> > > On Thu, Oct 24, 2019 at 6:25 AM Jan Kiszka <jan.kiszka@web.de
> > > <mailto:jan.kiszka@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
> > > RJM>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.
> >
> RJM>] yup, host has 16 cores whilst guest has 4 (using the stock
> RJM>images).  
> 
> >
> > Oh, and don't expect any kind of determinism in these setups. KVM
> > and QEMU are for functional testing only.
> >
> RJM>] Ah, good to know.  
> 
> >
> > Jan
> >  

Re: Xenomai fails to start when running in QEMU VM

[Jan Kiszka]

On 24.10.19 15:38, Rob Miller via Xenomai wrote:
> responses in-line...
> 
> Rob Miller
> rob.miller@broadcom.com
> (919)721-3339
> 
> 
> On Thu, Oct 24, 2019 at 8:12 AM Jan Kiszka <jan.kiszka@web.de> wrote:
> 
>> On 24.10.19 13:46, Rob Miller wrote:
>>> Pls see below
>>>
>>> Rob Miller
>>> rob.miller@broadcom.com <mailto:rob.miller@broadcom.com>
>>> (919)721-3339
>>>
>>>
>>> On Thu, Oct 24, 2019 at 6:25 AM Jan Kiszka <jan.kiszka@web.de
>>> <mailto:jan.kiszka@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.
>>
> RJM>] yup, host has 16 cores whilst guest has 4 (using the stock images).
> 
>>
>> Oh, and don't expect any kind of determinism in these setups. KVM and
>> QEMU are for functional testing only.
>>
> RJM>] Ah, good to know.
> 
>>
>> Jan
>>

Were you able to resolve the mystery? I've just retest a fresh build of
xenomai-images from master like this:

kas-docker --isar build kas.yml:opt-xenomai-next.yml:board-qemu-amd64.yml

And then I ran the result on my OpenSUSE 15.1 (qemu-3.1.1-lp151.7.3.3, 
kernel-default-5.3.7-6.1.g387f2bb), and it worked. TSC calibration
happened against PIT.

Jan

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