[Adeos-main] Reworking ipipe timer subsystem,

[Adeos-main] Reworking ipipe timer subsystem,

[Gilles Chanteperdrix]

Hi,

restarting the ipipe-core is the good opportunity to look a bit at our
current state and think about what we could improve. On ARM, at least,
the thing we could improve is the timer subsystem. A long time ago,
linux has switched to a system allowing to select at run-time which
timer to use, and we do not really benefit from this, what timer we use
is selected at compile time, resulting in a massive ifdefery on arm, and
even on x86, we have to select at compile time whether using the 8254 or
APIC, whereas we could decide to use whatever linux is using, even say
HPET, without any compilation option. That is assuming we want to move
the x86 timer-specific code from xenomai to I-pipe.

The idea to reach this goal would be to add some ipipe specific members
to the struct clock_event_device, the way we do for the interrupt
controller:
- a CLOCK_EVT_FEAT_IPIPE would signal that the clockevent device is
ipipe capable, meaning that it implements the following callback
- ipipe_steal would be called when stealing the timer, we could decide
to call this callback either as part of ipipe_request_timer, or with a
specific ipipe_steal_timer call, currently we simply set
__ipipe_mach_timerstolen to 1, but it is pure luck that we never needed
something more complicated, besides, we may want to start a timer that
was not started by linux so, we would put its initialization here;
- ipipe_stolen would record whether the timer is stolen
- ipipe_min_delta_ticks, ipipe_max_delta_ticks would be used by the
ipipe_set_next_event callback
- ipipe_ack would be called to ack the timer interrupt the way we
currently do it currently on arm with __ipipe_mach_acktimer
- ipipe_set_next_event would program the next timer shot, the way it is
currently done in __ipipe_mach_set_dec.

All this is pretty straightforward, but there is still a question: how
does ipipe_request_timer select a timer. The idea is that on platform
without PIC muting, it is probably more efficient to use the same timer
for linux and xenomai. But on platforms with PIC muting, we could want
to select a different timer for linux and xenomai, but how do we find
it, what if linux has not selected a timer because it is unusable on
that platform?

Please feel free to comment these sketchy ideas.

-- 
                                                                Gilles.

Re: [Adeos-main] Reworking ipipe timer subsystem,

[Philippe Gerum]

On 02/19/2012 08:43 PM, Gilles Chanteperdrix wrote:
>
> Hi,
>
> restarting the ipipe-core is the good opportunity to look a bit at our
> current state and think about what we could improve. On ARM, at least,
> the thing we could improve is the timer subsystem. A long time ago,
> linux has switched to a system allowing to select at run-time which
> timer to use, and we do not really benefit from this, what timer we use
> is selected at compile time, resulting in a massive ifdefery on arm, and
> even on x86, we have to select at compile time whether using the 8254 or
> APIC, whereas we could decide to use whatever linux is using, even say
> HPET, without any compilation option. That is assuming we want to move
> the x86 timer-specific code from xenomai to I-pipe.
>
> The idea to reach this goal would be to add some ipipe specific members
> to the struct clock_event_device, the way we do for the interrupt
> controller:
> - a CLOCK_EVT_FEAT_IPIPE would signal that the clockevent device is
> ipipe capable, meaning that it implements the following callback
> - ipipe_steal would be called when stealing the timer, we could decide
> to call this callback either as part of ipipe_request_timer, or with a
> specific ipipe_steal_timer call, currently we simply set
> __ipipe_mach_timerstolen to 1, but it is pure luck that we never needed
> something more complicated, besides, we may want to start a timer that
> was not started by linux so, we would put its initialization here;
> - ipipe_stolen would record whether the timer is stolen
> - ipipe_min_delta_ticks, ipipe_max_delta_ticks would be used by the
> ipipe_set_next_event callback
> - ipipe_ack would be called to ack the timer interrupt the way we
> currently do it currently on arm with __ipipe_mach_acktimer
> - ipipe_set_next_event would program the next timer shot, the way it is
> currently done in __ipipe_mach_set_dec.
>
> All this is pretty straightforward, but there is still a question: how
> does ipipe_request_timer select a timer. The idea is that on platform
> without PIC muting, it is probably more efficient to use the same timer
> for linux and xenomai. But on platforms with PIC muting, we could want
> to select a different timer for linux and xenomai, but how do we find
> it, what if linux has not selected a timer because it is unusable on
> that platform?

Checking the clock device mode for CLOCK_EVT_MODE_SHUTDOWN, and falling 
back to sharing the active kernel tick device + disabling PIC muting?

>
> Please feel free to comment these sketchy ideas.
>


-- 
Philippe.

Re: [Adeos-main] Reworking ipipe timer subsystem,

[Gilles Chanteperdrix]

On 02/20/2012 05:46 PM, Philippe Gerum wrote:
> On 02/19/2012 08:43 PM, Gilles Chanteperdrix wrote:
>>
>> Hi,
>>
>> restarting the ipipe-core is the good opportunity to look a bit at our
>> current state and think about what we could improve. On ARM, at least,
>> the thing we could improve is the timer subsystem. A long time ago,
>> linux has switched to a system allowing to select at run-time which
>> timer to use, and we do not really benefit from this, what timer we use
>> is selected at compile time, resulting in a massive ifdefery on arm, and
>> even on x86, we have to select at compile time whether using the 8254 or
>> APIC, whereas we could decide to use whatever linux is using, even say
>> HPET, without any compilation option. That is assuming we want to move
>> the x86 timer-specific code from xenomai to I-pipe.
>>
>> The idea to reach this goal would be to add some ipipe specific members
>> to the struct clock_event_device, the way we do for the interrupt
>> controller:
>> - a CLOCK_EVT_FEAT_IPIPE would signal that the clockevent device is
>> ipipe capable, meaning that it implements the following callback
>> - ipipe_steal would be called when stealing the timer, we could decide
>> to call this callback either as part of ipipe_request_timer, or with a
>> specific ipipe_steal_timer call, currently we simply set
>> __ipipe_mach_timerstolen to 1, but it is pure luck that we never needed
>> something more complicated, besides, we may want to start a timer that
>> was not started by linux so, we would put its initialization here;
>> - ipipe_stolen would record whether the timer is stolen
>> - ipipe_min_delta_ticks, ipipe_max_delta_ticks would be used by the
>> ipipe_set_next_event callback
>> - ipipe_ack would be called to ack the timer interrupt the way we
>> currently do it currently on arm with __ipipe_mach_acktimer
>> - ipipe_set_next_event would program the next timer shot, the way it is
>> currently done in __ipipe_mach_set_dec.
>>
>> All this is pretty straightforward, but there is still a question: how
>> does ipipe_request_timer select a timer. The idea is that on platform
>> without PIC muting, it is probably more efficient to use the same timer
>> for linux and xenomai. But on platforms with PIC muting, we could want
>> to select a different timer for linux and xenomai, but how do we find
>> it, what if linux has not selected a timer because it is unusable on
>> that platform?
> 
> Checking the clock device mode for CLOCK_EVT_MODE_SHUTDOWN, and falling 
> back to sharing the active kernel tick device + disabling PIC muting?

OK. Another question is: do we want to move x86 timer handling from
xenomai to ipipe. If not, we have to find a way to support the two
possible configurations. What we could do is using the timer name in
ipipe_request_tickdev: if a timer name is supplied, we keep the old
implementation, if no timer name is supplied, we use the new
implementation which looks for the best candidate with the
CLOCK_EVT_FEAT_IPIPE bit.


-- 
                                                                Gilles.

Re: [Adeos-main] Reworking ipipe timer subsystem,

[Philippe Gerum]

On 02/24/2012 01:28 PM, Gilles Chanteperdrix wrote:
> On 02/20/2012 05:46 PM, Philippe Gerum wrote:
>> On 02/19/2012 08:43 PM, Gilles Chanteperdrix wrote:
>>>
>>> Hi,
>>>
>>> restarting the ipipe-core is the good opportunity to look a bit at our
>>> current state and think about what we could improve. On ARM, at least,
>>> the thing we could improve is the timer subsystem. A long time ago,
>>> linux has switched to a system allowing to select at run-time which
>>> timer to use, and we do not really benefit from this, what timer we use
>>> is selected at compile time, resulting in a massive ifdefery on arm, and
>>> even on x86, we have to select at compile time whether using the 8254 or
>>> APIC, whereas we could decide to use whatever linux is using, even say
>>> HPET, without any compilation option. That is assuming we want to move
>>> the x86 timer-specific code from xenomai to I-pipe.
>>>
>>> The idea to reach this goal would be to add some ipipe specific members
>>> to the struct clock_event_device, the way we do for the interrupt
>>> controller:
>>> - a CLOCK_EVT_FEAT_IPIPE would signal that the clockevent device is
>>> ipipe capable, meaning that it implements the following callback
>>> - ipipe_steal would be called when stealing the timer, we could decide
>>> to call this callback either as part of ipipe_request_timer, or with a
>>> specific ipipe_steal_timer call, currently we simply set
>>> __ipipe_mach_timerstolen to 1, but it is pure luck that we never needed
>>> something more complicated, besides, we may want to start a timer that
>>> was not started by linux so, we would put its initialization here;
>>> - ipipe_stolen would record whether the timer is stolen
>>> - ipipe_min_delta_ticks, ipipe_max_delta_ticks would be used by the
>>> ipipe_set_next_event callback
>>> - ipipe_ack would be called to ack the timer interrupt the way we
>>> currently do it currently on arm with __ipipe_mach_acktimer
>>> - ipipe_set_next_event would program the next timer shot, the way it is
>>> currently done in __ipipe_mach_set_dec.
>>>
>>> All this is pretty straightforward, but there is still a question: how
>>> does ipipe_request_timer select a timer. The idea is that on platform
>>> without PIC muting, it is probably more efficient to use the same timer
>>> for linux and xenomai. But on platforms with PIC muting, we could want
>>> to select a different timer for linux and xenomai, but how do we find
>>> it, what if linux has not selected a timer because it is unusable on
>>> that platform?
>>
>> Checking the clock device mode for CLOCK_EVT_MODE_SHUTDOWN, and falling
>> back to sharing the active kernel tick device + disabling PIC muting?
>
> OK. Another question is: do we want to move x86 timer handling from
> xenomai to ipipe. If not, we have to find a way to support the two
> possible configurations. What we could do is using the timer name in
> ipipe_request_tickdev: if a timer name is supplied, we keep the old
> implementation, if no timer name is supplied, we use the new
> implementation which looks for the best candidate with the
> CLOCK_EVT_FEAT_IPIPE bit.
>
>

Yes, makes sense. At any rate, handling the real-time timer the way we 
want for Xenomai directly from the pipeline is the only sane option. We 
only have to be careful about backward compatibility of the newest core 
pipelines with 2.6.x, until we stop maintaining this branch in favor of 
3.x. We may also move ipipe_request_tckdev() to the compat module fully, 
removing it from the current API if that makes sense.

-- 
Philippe.

Re: [Adeos-main] Reworking ipipe timer subsystem,

[Gilles Chanteperdrix]

On 02/24/2012 03:40 PM, Philippe Gerum wrote:
> On 02/24/2012 01:28 PM, Gilles Chanteperdrix wrote:
>> On 02/20/2012 05:46 PM, Philippe Gerum wrote:
>>> On 02/19/2012 08:43 PM, Gilles Chanteperdrix wrote:
>>>>
>>>> Hi,
>>>>
>>>> restarting the ipipe-core is the good opportunity to look a bit at our
>>>> current state and think about what we could improve. On ARM, at least,
>>>> the thing we could improve is the timer subsystem. A long time ago,
>>>> linux has switched to a system allowing to select at run-time which
>>>> timer to use, and we do not really benefit from this, what timer we use
>>>> is selected at compile time, resulting in a massive ifdefery on arm, and
>>>> even on x86, we have to select at compile time whether using the 8254 or
>>>> APIC, whereas we could decide to use whatever linux is using, even say
>>>> HPET, without any compilation option. That is assuming we want to move
>>>> the x86 timer-specific code from xenomai to I-pipe.
>>>>
>>>> The idea to reach this goal would be to add some ipipe specific members
>>>> to the struct clock_event_device, the way we do for the interrupt
>>>> controller:
>>>> - a CLOCK_EVT_FEAT_IPIPE would signal that the clockevent device is
>>>> ipipe capable, meaning that it implements the following callback
>>>> - ipipe_steal would be called when stealing the timer, we could decide
>>>> to call this callback either as part of ipipe_request_timer, or with a
>>>> specific ipipe_steal_timer call, currently we simply set
>>>> __ipipe_mach_timerstolen to 1, but it is pure luck that we never needed
>>>> something more complicated, besides, we may want to start a timer that
>>>> was not started by linux so, we would put its initialization here;
>>>> - ipipe_stolen would record whether the timer is stolen
>>>> - ipipe_min_delta_ticks, ipipe_max_delta_ticks would be used by the
>>>> ipipe_set_next_event callback
>>>> - ipipe_ack would be called to ack the timer interrupt the way we
>>>> currently do it currently on arm with __ipipe_mach_acktimer
>>>> - ipipe_set_next_event would program the next timer shot, the way it is
>>>> currently done in __ipipe_mach_set_dec.
>>>>
>>>> All this is pretty straightforward, but there is still a question: how
>>>> does ipipe_request_timer select a timer. The idea is that on platform
>>>> without PIC muting, it is probably more efficient to use the same timer
>>>> for linux and xenomai. But on platforms with PIC muting, we could want
>>>> to select a different timer for linux and xenomai, but how do we find
>>>> it, what if linux has not selected a timer because it is unusable on
>>>> that platform?
>>>
>>> Checking the clock device mode for CLOCK_EVT_MODE_SHUTDOWN, and falling
>>> back to sharing the active kernel tick device + disabling PIC muting?
>>
>> OK. Another question is: do we want to move x86 timer handling from
>> xenomai to ipipe. If not, we have to find a way to support the two
>> possible configurations. What we could do is using the timer name in
>> ipipe_request_tickdev: if a timer name is supplied, we keep the old
>> implementation, if no timer name is supplied, we use the newho
>> implementation which looks for the best candidate with the
>> CLOCK_EVT_FEAT_IPIPE bit.
>>
>>
> 
> Yes, makes sense. At any rate, handling the real-time timer the way we 
> want for Xenomai directly from the pipeline is the only sane option. We 
> only have to be careful about backward compatibility of the newest core 
> pipelines with 2.6.x, until we stop maintaining this branch in favor of 
> 3.x. We may also move ipipe_request_tckdev() to the compat module fully, 
> removing it from the current API if that makes sense.
> 

For those who would like to follow, the result, a bit different from what
was originally planned is the interface implemented by this file:
http://git.xenomai.org/?p=ipipe-gch.git;a=blob;f=kernel/ipipe/timer.c;h=b9936469652d8fe998157d155fda77df81f0425a;hb=52d36aa86d5c5d463d86d384ad717f26ec96ef8c

And ARM and x86 architectures were re-factored over this interface. As 
an example, the implementation of x86 timers is in this patch:
http://git.xenomai.org/?p=ipipe-gch.git;a=commitdiff;h=52d36aa86d5c5d463d86d384ad717f26ec96ef8c;hp=675a8ed4365eb1f23b098f913caf40e4dc792b80

8254, local APIC and HPET in legacy mode were tested, even selected 
at run-time. Only per-cpu HPET remains to be tested (the hardware 
I have does not support it).

-- 
					    Gilles.

Re: [Adeos-main] Reworking ipipe timer subsystem,

[Jan Kiszka]

On 2012-04-02 17:39, Gilles Chanteperdrix wrote:
> On 02/24/2012 03:40 PM, Philippe Gerum wrote:
>> On 02/24/2012 01:28 PM, Gilles Chanteperdrix wrote:
>>> On 02/20/2012 05:46 PM, Philippe Gerum wrote:
>>>> On 02/19/2012 08:43 PM, Gilles Chanteperdrix wrote:
>>>>>
>>>>> Hi,
>>>>>
>>>>> restarting the ipipe-core is the good opportunity to look a bit at our
>>>>> current state and think about what we could improve. On ARM, at least,
>>>>> the thing we could improve is the timer subsystem. A long time ago,
>>>>> linux has switched to a system allowing to select at run-time which
>>>>> timer to use, and we do not really benefit from this, what timer we use
>>>>> is selected at compile time, resulting in a massive ifdefery on arm, and
>>>>> even on x86, we have to select at compile time whether using the 8254 or
>>>>> APIC, whereas we could decide to use whatever linux is using, even say
>>>>> HPET, without any compilation option. That is assuming we want to move
>>>>> the x86 timer-specific code from xenomai to I-pipe.
>>>>>
>>>>> The idea to reach this goal would be to add some ipipe specific members
>>>>> to the struct clock_event_device, the way we do for the interrupt
>>>>> controller:
>>>>> - a CLOCK_EVT_FEAT_IPIPE would signal that the clockevent device is
>>>>> ipipe capable, meaning that it implements the following callback
>>>>> - ipipe_steal would be called when stealing the timer, we could decide
>>>>> to call this callback either as part of ipipe_request_timer, or with a
>>>>> specific ipipe_steal_timer call, currently we simply set
>>>>> __ipipe_mach_timerstolen to 1, but it is pure luck that we never needed
>>>>> something more complicated, besides, we may want to start a timer that
>>>>> was not started by linux so, we would put its initialization here;
>>>>> - ipipe_stolen would record whether the timer is stolen
>>>>> - ipipe_min_delta_ticks, ipipe_max_delta_ticks would be used by the
>>>>> ipipe_set_next_event callback
>>>>> - ipipe_ack would be called to ack the timer interrupt the way we
>>>>> currently do it currently on arm with __ipipe_mach_acktimer
>>>>> - ipipe_set_next_event would program the next timer shot, the way it is
>>>>> currently done in __ipipe_mach_set_dec.
>>>>>
>>>>> All this is pretty straightforward, but there is still a question: how
>>>>> does ipipe_request_timer select a timer. The idea is that on platform
>>>>> without PIC muting, it is probably more efficient to use the same timer
>>>>> for linux and xenomai. But on platforms with PIC muting, we could want
>>>>> to select a different timer for linux and xenomai, but how do we find
>>>>> it, what if linux has not selected a timer because it is unusable on
>>>>> that platform?
>>>>
>>>> Checking the clock device mode for CLOCK_EVT_MODE_SHUTDOWN, and falling
>>>> back to sharing the active kernel tick device + disabling PIC muting?
>>>
>>> OK. Another question is: do we want to move x86 timer handling from
>>> xenomai to ipipe. If not, we have to find a way to support the two
>>> possible configurations. What we could do is using the timer name in
>>> ipipe_request_tickdev: if a timer name is supplied, we keep the old
>>> implementation, if no timer name is supplied, we use the newho
>>> implementation which looks for the best candidate with the
>>> CLOCK_EVT_FEAT_IPIPE bit.
>>>
>>>
>>
>> Yes, makes sense. At any rate, handling the real-time timer the way we 
>> want for Xenomai directly from the pipeline is the only sane option. We 
>> only have to be careful about backward compatibility of the newest core 
>> pipelines with 2.6.x, until we stop maintaining this branch in favor of 
>> 3.x. We may also move ipipe_request_tckdev() to the compat module fully, 
>> removing it from the current API if that makes sense.
>>
> 
> For those who would like to follow, the result, a bit different from what
> was originally planned is the interface implemented by this file:
> http://git.xenomai.org/?p=ipipe-gch.git;a=blob;f=kernel/ipipe/timer.c;h=b9936469652d8fe998157d155fda77df81f0425a;hb=52d36aa86d5c5d463d86d384ad717f26ec96ef8c
> 
> And ARM and x86 architectures were re-factored over this interface. As 
> an example, the implementation of x86 timers is in this patch:
> http://git.xenomai.org/?p=ipipe-gch.git;a=commitdiff;h=52d36aa86d5c5d463d86d384ad717f26ec96ef8c;hp=675a8ed4365eb1f23b098f913caf40e4dc792b80
> 
> 8254, local APIC and HPET in legacy mode were tested, even selected 
> at run-time. Only per-cpu HPET remains to be tested (the hardware 
> I have does not support it).

FWI, QEMU (w/ or w/o KVM) can emulated enough HPET timers, also with MSI
support, but that was broken in I-pipe last time I checked. Use -global
hpet.timers=4 (or more for more CPUs) and -global hpet.msi=on.

Jan

-- 
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux

Re: [Adeos-main] Reworking ipipe timer subsystem,

[Gilles Chanteperdrix]

On 04/02/2012 05:54 PM, Jan Kiszka wrote:
> On 2012-04-02 17:39, Gilles Chanteperdrix wrote:
>> On 02/24/2012 03:40 PM, Philippe Gerum wrote:
>>> On 02/24/2012 01:28 PM, Gilles Chanteperdrix wrote:
>>>> On 02/20/2012 05:46 PM, Philippe Gerum wrote:
>>>>> On 02/19/2012 08:43 PM, Gilles Chanteperdrix wrote:
>>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> restarting the ipipe-core is the good opportunity to look a bit at our
>>>>>> current state and think about what we could improve. On ARM, at least,
>>>>>> the thing we could improve is the timer subsystem. A long time ago,
>>>>>> linux has switched to a system allowing to select at run-time which
>>>>>> timer to use, and we do not really benefit from this, what timer we use
>>>>>> is selected at compile time, resulting in a massive ifdefery on arm, and
>>>>>> even on x86, we have to select at compile time whether using the 8254 or
>>>>>> APIC, whereas we could decide to use whatever linux is using, even say
>>>>>> HPET, without any compilation option. That is assuming we want to move
>>>>>> the x86 timer-specific code from xenomai to I-pipe.
>>>>>>
>>>>>> The idea to reach this goal would be to add some ipipe specific members
>>>>>> to the struct clock_event_device, the way we do for the interrupt
>>>>>> controller:
>>>>>> - a CLOCK_EVT_FEAT_IPIPE would signal that the clockevent device is
>>>>>> ipipe capable, meaning that it implements the following callback
>>>>>> - ipipe_steal would be called when stealing the timer, we could decide
>>>>>> to call this callback either as part of ipipe_request_timer, or with a
>>>>>> specific ipipe_steal_timer call, currently we simply set
>>>>>> __ipipe_mach_timerstolen to 1, but it is pure luck that we never needed
>>>>>> something more complicated, besides, we may want to start a timer that
>>>>>> was not started by linux so, we would put its initialization here;
>>>>>> - ipipe_stolen would record whether the timer is stolen
>>>>>> - ipipe_min_delta_ticks, ipipe_max_delta_ticks would be used by the
>>>>>> ipipe_set_next_event callback
>>>>>> - ipipe_ack would be called to ack the timer interrupt the way we
>>>>>> currently do it currently on arm with __ipipe_mach_acktimer
>>>>>> - ipipe_set_next_event would program the next timer shot, the way it is
>>>>>> currently done in __ipipe_mach_set_dec.
>>>>>>
>>>>>> All this is pretty straightforward, but there is still a question: how
>>>>>> does ipipe_request_timer select a timer. The idea is that on platform
>>>>>> without PIC muting, it is probably more efficient to use the same timer
>>>>>> for linux and xenomai. But on platforms with PIC muting, we could want
>>>>>> to select a different timer for linux and xenomai, but how do we find
>>>>>> it, what if linux has not selected a timer because it is unusable on
>>>>>> that platform?
>>>>>
>>>>> Checking the clock device mode for CLOCK_EVT_MODE_SHUTDOWN, and falling
>>>>> back to sharing the active kernel tick device + disabling PIC muting?
>>>>
>>>> OK. Another question is: do we want to move x86 timer handling from
>>>> xenomai to ipipe. If not, we have to find a way to support the two
>>>> possible configurations. What we could do is using the timer name in
>>>> ipipe_request_tickdev: if a timer name is supplied, we keep the old
>>>> implementation, if no timer name is supplied, we use the newho
>>>> implementation which looks for the best candidate with the
>>>> CLOCK_EVT_FEAT_IPIPE bit.
>>>>
>>>>
>>>
>>> Yes, makes sense. At any rate, handling the real-time timer the way we 
>>> want for Xenomai directly from the pipeline is the only sane option. We 
>>> only have to be careful about backward compatibility of the newest core 
>>> pipelines with 2.6.x, until we stop maintaining this branch in favor of 
>>> 3.x. We may also move ipipe_request_tckdev() to the compat module fully, 
>>> removing it from the current API if that makes sense.
>>>
>>
>> For those who would like to follow, the result, a bit different from what
>> was originally planned is the interface implemented by this file:
>> http://git.xenomai.org/?p=ipipe-gch.git;a=blob;f=kernel/ipipe/timer.c;h=b9936469652d8fe998157d155fda77df81f0425a;hb=52d36aa86d5c5d463d86d384ad717f26ec96ef8c
>>
>> And ARM and x86 architectures were re-factored over this interface. As 
>> an example, the implementation of x86 timers is in this patch:
>> http://git.xenomai.org/?p=ipipe-gch.git;a=commitdiff;h=52d36aa86d5c5d463d86d384ad717f26ec96ef8c;hp=675a8ed4365eb1f23b098f913caf40e4dc792b80
>>
>> 8254, local APIC and HPET in legacy mode were tested, even selected 
>> at run-time. Only per-cpu HPET remains to be tested (the hardware 
>> I have does not support it).
> 
> FWI, QEMU (w/ or w/o KVM) can emulated enough HPET timers, also with MSI
> support, but that was broken in I-pipe last time I checked. Use -global
> hpet.timers=4 (or more for more CPUs) and -global hpet.msi=on.

Ah thanks. How was it broken? MSI were broken? As far as I understood
MSI support for HPET are required for linux to select per-cpu HPET.

-- 
					    Gilles.

Re: [Adeos-main] Reworking ipipe timer subsystem,

[Jan Kiszka]

On 2012-04-02 18:08, Gilles Chanteperdrix wrote:
> On 04/02/2012 05:54 PM, Jan Kiszka wrote:
>> On 2012-04-02 17:39, Gilles Chanteperdrix wrote:
>>> On 02/24/2012 03:40 PM, Philippe Gerum wrote:
>>>> On 02/24/2012 01:28 PM, Gilles Chanteperdrix wrote:
>>>>> On 02/20/2012 05:46 PM, Philippe Gerum wrote:
>>>>>> On 02/19/2012 08:43 PM, Gilles Chanteperdrix wrote:
>>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> restarting the ipipe-core is the good opportunity to look a bit at our
>>>>>>> current state and think about what we could improve. On ARM, at least,
>>>>>>> the thing we could improve is the timer subsystem. A long time ago,
>>>>>>> linux has switched to a system allowing to select at run-time which
>>>>>>> timer to use, and we do not really benefit from this, what timer we use
>>>>>>> is selected at compile time, resulting in a massive ifdefery on arm, and
>>>>>>> even on x86, we have to select at compile time whether using the 8254 or
>>>>>>> APIC, whereas we could decide to use whatever linux is using, even say
>>>>>>> HPET, without any compilation option. That is assuming we want to move
>>>>>>> the x86 timer-specific code from xenomai to I-pipe.
>>>>>>>
>>>>>>> The idea to reach this goal would be to add some ipipe specific members
>>>>>>> to the struct clock_event_device, the way we do for the interrupt
>>>>>>> controller:
>>>>>>> - a CLOCK_EVT_FEAT_IPIPE would signal that the clockevent device is
>>>>>>> ipipe capable, meaning that it implements the following callback
>>>>>>> - ipipe_steal would be called when stealing the timer, we could decide
>>>>>>> to call this callback either as part of ipipe_request_timer, or with a
>>>>>>> specific ipipe_steal_timer call, currently we simply set
>>>>>>> __ipipe_mach_timerstolen to 1, but it is pure luck that we never needed
>>>>>>> something more complicated, besides, we may want to start a timer that
>>>>>>> was not started by linux so, we would put its initialization here;
>>>>>>> - ipipe_stolen would record whether the timer is stolen
>>>>>>> - ipipe_min_delta_ticks, ipipe_max_delta_ticks would be used by the
>>>>>>> ipipe_set_next_event callback
>>>>>>> - ipipe_ack would be called to ack the timer interrupt the way we
>>>>>>> currently do it currently on arm with __ipipe_mach_acktimer
>>>>>>> - ipipe_set_next_event would program the next timer shot, the way it is
>>>>>>> currently done in __ipipe_mach_set_dec.
>>>>>>>
>>>>>>> All this is pretty straightforward, but there is still a question: how
>>>>>>> does ipipe_request_timer select a timer. The idea is that on platform
>>>>>>> without PIC muting, it is probably more efficient to use the same timer
>>>>>>> for linux and xenomai. But on platforms with PIC muting, we could want
>>>>>>> to select a different timer for linux and xenomai, but how do we find
>>>>>>> it, what if linux has not selected a timer because it is unusable on
>>>>>>> that platform?
>>>>>>
>>>>>> Checking the clock device mode for CLOCK_EVT_MODE_SHUTDOWN, and falling
>>>>>> back to sharing the active kernel tick device + disabling PIC muting?
>>>>>
>>>>> OK. Another question is: do we want to move x86 timer handling from
>>>>> xenomai to ipipe. If not, we have to find a way to support the two
>>>>> possible configurations. What we could do is using the timer name in
>>>>> ipipe_request_tickdev: if a timer name is supplied, we keep the old
>>>>> implementation, if no timer name is supplied, we use the newho
>>>>> implementation which looks for the best candidate with the
>>>>> CLOCK_EVT_FEAT_IPIPE bit.
>>>>>
>>>>>
>>>>
>>>> Yes, makes sense. At any rate, handling the real-time timer the way we 
>>>> want for Xenomai directly from the pipeline is the only sane option. We 
>>>> only have to be careful about backward compatibility of the newest core 
>>>> pipelines with 2.6.x, until we stop maintaining this branch in favor of 
>>>> 3.x. We may also move ipipe_request_tckdev() to the compat module fully, 
>>>> removing it from the current API if that makes sense.
>>>>
>>>
>>> For those who would like to follow, the result, a bit different from what
>>> was originally planned is the interface implemented by this file:
>>> http://git.xenomai.org/?p=ipipe-gch.git;a=blob;f=kernel/ipipe/timer.c;h=b9936469652d8fe998157d155fda77df81f0425a;hb=52d36aa86d5c5d463d86d384ad717f26ec96ef8c
>>>
>>> And ARM and x86 architectures were re-factored over this interface. As 
>>> an example, the implementation of x86 timers is in this patch:
>>> http://git.xenomai.org/?p=ipipe-gch.git;a=commitdiff;h=52d36aa86d5c5d463d86d384ad717f26ec96ef8c;hp=675a8ed4365eb1f23b098f913caf40e4dc792b80
>>>
>>> 8254, local APIC and HPET in legacy mode were tested, even selected 
>>> at run-time. Only per-cpu HPET remains to be tested (the hardware 
>>> I have does not support it).
>>
>> FWI, QEMU (w/ or w/o KVM) can emulated enough HPET timers, also with MSI
>> support, but that was broken in I-pipe last time I checked. Use -global
>> hpet.timers=4 (or more for more CPUs) and -global hpet.msi=on.
> 
> Ah thanks. How was it broken? MSI were broken? As far as I understood
> MSI support for HPET are required for linux to select per-cpu HPET.

I-pipe was not aware of Linux using the HPET as per-CPU timersource. So
things fell apart once Linux switched. And, yes, there must be MSI
support to make Linux use them as per-CPU timers.

Jan

-- 
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux

Re: [Adeos-main] Reworking ipipe timer subsystem,

[Gilles Chanteperdrix]

On 04/02/2012 06:18 PM, Jan Kiszka wrote:
> On 2012-04-02 18:08, Gilles Chanteperdrix wrote:
>> On 04/02/2012 05:54 PM, Jan Kiszka wrote:
>>> On 2012-04-02 17:39, Gilles Chanteperdrix wrote:
>>>> On 02/24/2012 03:40 PM, Philippe Gerum wrote:
>>>>> On 02/24/2012 01:28 PM, Gilles Chanteperdrix wrote:
>>>>>> On 02/20/2012 05:46 PM, Philippe Gerum wrote:
>>>>>>> On 02/19/2012 08:43 PM, Gilles Chanteperdrix wrote:
>>>>>>>>
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> restarting the ipipe-core is the good opportunity to look a bit at our
>>>>>>>> current state and think about what we could improve. On ARM, at least,
>>>>>>>> the thing we could improve is the timer subsystem. A long time ago,
>>>>>>>> linux has switched to a system allowing to select at run-time which
>>>>>>>> timer to use, and we do not really benefit from this, what timer we use
>>>>>>>> is selected at compile time, resulting in a massive ifdefery on arm, and
>>>>>>>> even on x86, we have to select at compile time whether using the 8254 or
>>>>>>>> APIC, whereas we could decide to use whatever linux is using, even say
>>>>>>>> HPET, without any compilation option. That is assuming we want to move
>>>>>>>> the x86 timer-specific code from xenomai to I-pipe.
>>>>>>>>
>>>>>>>> The idea to reach this goal would be to add some ipipe specific members
>>>>>>>> to the struct clock_event_device, the way we do for the interrupt
>>>>>>>> controller:
>>>>>>>> - a CLOCK_EVT_FEAT_IPIPE would signal that the clockevent device is
>>>>>>>> ipipe capable, meaning that it implements the following callback
>>>>>>>> - ipipe_steal would be called when stealing the timer, we could decide
>>>>>>>> to call this callback either as part of ipipe_request_timer, or with a
>>>>>>>> specific ipipe_steal_timer call, currently we simply set
>>>>>>>> __ipipe_mach_timerstolen to 1, but it is pure luck that we never needed
>>>>>>>> something more complicated, besides, we may want to start a timer that
>>>>>>>> was not started by linux so, we would put its initialization here;
>>>>>>>> - ipipe_stolen would record whether the timer is stolen
>>>>>>>> - ipipe_min_delta_ticks, ipipe_max_delta_ticks would be used by the
>>>>>>>> ipipe_set_next_event callback
>>>>>>>> - ipipe_ack would be called to ack the timer interrupt the way we
>>>>>>>> currently do it currently on arm with __ipipe_mach_acktimer
>>>>>>>> - ipipe_set_next_event would program the next timer shot, the way it is
>>>>>>>> currently done in __ipipe_mach_set_dec.
>>>>>>>>
>>>>>>>> All this is pretty straightforward, but there is still a question: how
>>>>>>>> does ipipe_request_timer select a timer. The idea is that on platform
>>>>>>>> without PIC muting, it is probably more efficient to use the same timer
>>>>>>>> for linux and xenomai. But on platforms with PIC muting, we could want
>>>>>>>> to select a different timer for linux and xenomai, but how do we find
>>>>>>>> it, what if linux has not selected a timer because it is unusable on
>>>>>>>> that platform?
>>>>>>>
>>>>>>> Checking the clock device mode for CLOCK_EVT_MODE_SHUTDOWN, and falling
>>>>>>> back to sharing the active kernel tick device + disabling PIC muting?
>>>>>>
>>>>>> OK. Another question is: do we want to move x86 timer handling from
>>>>>> xenomai to ipipe. If not, we have to find a way to support the two
>>>>>> possible configurations. What we could do is using the timer name in
>>>>>> ipipe_request_tickdev: if a timer name is supplied, we keep the old
>>>>>> implementation, if no timer name is supplied, we use the newho
>>>>>> implementation which looks for the best candidate with the
>>>>>> CLOCK_EVT_FEAT_IPIPE bit.
>>>>>>
>>>>>>
>>>>>
>>>>> Yes, makes sense. At any rate, handling the real-time timer the way we 
>>>>> want for Xenomai directly from the pipeline is the only sane option. We 
>>>>> only have to be careful about backward compatibility of the newest core 
>>>>> pipelines with 2.6.x, until we stop maintaining this branch in favor of 
>>>>> 3.x. We may also move ipipe_request_tckdev() to the compat module fully, 
>>>>> removing it from the current API if that makes sense.
>>>>>
>>>>
>>>> For those who would like to follow, the result, a bit different from what
>>>> was originally planned is the interface implemented by this file:
>>>> http://git.xenomai.org/?p=ipipe-gch.git;a=blob;f=kernel/ipipe/timer.c;h=b9936469652d8fe998157d155fda77df81f0425a;hb=52d36aa86d5c5d463d86d384ad717f26ec96ef8c
>>>>
>>>> And ARM and x86 architectures were re-factored over this interface. As 
>>>> an example, the implementation of x86 timers is in this patch:
>>>> http://git.xenomai.org/?p=ipipe-gch.git;a=commitdiff;h=52d36aa86d5c5d463d86d384ad717f26ec96ef8c;hp=675a8ed4365eb1f23b098f913caf40e4dc792b80
>>>>
>>>> 8254, local APIC and HPET in legacy mode were tested, even selected 
>>>> at run-time. Only per-cpu HPET remains to be tested (the hardware 
>>>> I have does not support it).
>>>
>>> FWI, QEMU (w/ or w/o KVM) can emulated enough HPET timers, also with MSI
>>> support, but that was broken in I-pipe last time I checked. Use -global
>>> hpet.timers=4 (or more for more CPUs) and -global hpet.msi=on.
>>
>> Ah thanks. How was it broken? MSI were broken? As far as I understood
>> MSI support for HPET are required for linux to select per-cpu HPET.
> 
> I-pipe was not aware of Linux using the HPET as per-CPU timersource. So
> things fell apart once Linux switched. And, yes, there must be MSI
> support to make Linux use them as per-CPU timers.

Ok. It is supposed to work with the refactoring then.

-- 
					    Gilles.

Re: [Adeos-main] Reworking ipipe timer subsystem,

[Gilles Chanteperdrix]

On 04/02/2012 05:54 PM, Jan Kiszka wrote:
> On 2012-04-02 17:39, Gilles Chanteperdrix wrote:
>> On 02/24/2012 03:40 PM, Philippe Gerum wrote:
>>> On 02/24/2012 01:28 PM, Gilles Chanteperdrix wrote:
>>>> On 02/20/2012 05:46 PM, Philippe Gerum wrote:
>>>>> On 02/19/2012 08:43 PM, Gilles Chanteperdrix wrote:
>>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> restarting the ipipe-core is the good opportunity to look a bit at our
>>>>>> current state and think about what we could improve. On ARM, at least,
>>>>>> the thing we could improve is the timer subsystem. A long time ago,
>>>>>> linux has switched to a system allowing to select at run-time which
>>>>>> timer to use, and we do not really benefit from this, what timer we use
>>>>>> is selected at compile time, resulting in a massive ifdefery on arm, and
>>>>>> even on x86, we have to select at compile time whether using the 8254 or
>>>>>> APIC, whereas we could decide to use whatever linux is using, even say
>>>>>> HPET, without any compilation option. That is assuming we want to move
>>>>>> the x86 timer-specific code from xenomai to I-pipe.
>>>>>>
>>>>>> The idea to reach this goal would be to add some ipipe specific members
>>>>>> to the struct clock_event_device, the way we do for the interrupt
>>>>>> controller:
>>>>>> - a CLOCK_EVT_FEAT_IPIPE would signal that the clockevent device is
>>>>>> ipipe capable, meaning that it implements the following callback
>>>>>> - ipipe_steal would be called when stealing the timer, we could decide
>>>>>> to call this callback either as part of ipipe_request_timer, or with a
>>>>>> specific ipipe_steal_timer call, currently we simply set
>>>>>> __ipipe_mach_timerstolen to 1, but it is pure luck that we never needed
>>>>>> something more complicated, besides, we may want to start a timer that
>>>>>> was not started by linux so, we would put its initialization here;
>>>>>> - ipipe_stolen would record whether the timer is stolen
>>>>>> - ipipe_min_delta_ticks, ipipe_max_delta_ticks would be used by the
>>>>>> ipipe_set_next_event callback
>>>>>> - ipipe_ack would be called to ack the timer interrupt the way we
>>>>>> currently do it currently on arm with __ipipe_mach_acktimer
>>>>>> - ipipe_set_next_event would program the next timer shot, the way it is
>>>>>> currently done in __ipipe_mach_set_dec.
>>>>>>
>>>>>> All this is pretty straightforward, but there is still a question: how
>>>>>> does ipipe_request_timer select a timer. The idea is that on platform
>>>>>> without PIC muting, it is probably more efficient to use the same timer
>>>>>> for linux and xenomai. But on platforms with PIC muting, we could want
>>>>>> to select a different timer for linux and xenomai, but how do we find
>>>>>> it, what if linux has not selected a timer because it is unusable on
>>>>>> that platform?
>>>>>
>>>>> Checking the clock device mode for CLOCK_EVT_MODE_SHUTDOWN, and falling
>>>>> back to sharing the active kernel tick device + disabling PIC muting?
>>>>
>>>> OK. Another question is: do we want to move x86 timer handling from
>>>> xenomai to ipipe. If not, we have to find a way to support the two
>>>> possible configurations. What we could do is using the timer name in
>>>> ipipe_request_tickdev: if a timer name is supplied, we keep the old
>>>> implementation, if no timer name is supplied, we use the newho
>>>> implementation which looks for the best candidate with the
>>>> CLOCK_EVT_FEAT_IPIPE bit.
>>>>
>>>>
>>>
>>> Yes, makes sense. At any rate, handling the real-time timer the way we 
>>> want for Xenomai directly from the pipeline is the only sane option. We 
>>> only have to be careful about backward compatibility of the newest core 
>>> pipelines with 2.6.x, until we stop maintaining this branch in favor of 
>>> 3.x. We may also move ipipe_request_tckdev() to the compat module fully, 
>>> removing it from the current API if that makes sense.
>>>
>>
>> For those who would like to follow, the result, a bit different from what
>> was originally planned is the interface implemented by this file:
>> http://git.xenomai.org/?p=ipipe-gch.git;a=blob;f=kernel/ipipe/timer.c;h=b9936469652d8fe998157d155fda77df81f0425a;hb=52d36aa86d5c5d463d86d384ad717f26ec96ef8c
>>
>> And ARM and x86 architectures were re-factored over this interface. As 
>> an example, the implementation of x86 timers is in this patch:
>> http://git.xenomai.org/?p=ipipe-gch.git;a=commitdiff;h=52d36aa86d5c5d463d86d384ad717f26ec96ef8c;hp=675a8ed4365eb1f23b098f913caf40e4dc792b80
>>
>> 8254, local APIC and HPET in legacy mode were tested, even selected 
>> at run-time. Only per-cpu HPET remains to be tested (the hardware 
>> I have does not support it).
> 
> FWI, QEMU (w/ or w/o KVM) can emulated enough HPET timers, also with MSI
> support, but that was broken in I-pipe last time I checked. Use -global
> hpet.timers=4 (or more for more CPUs) and -global hpet.msi=on.

No luck, I am using qemu 0.12.5, there is no -global option documented,
and these two values have no effect. Is there any way to have both the
kernel console directly in the terminal where qemu is launched, and a
way to stop qemu by hitting ctrl-C ?

-serial stdio is what I want, but having -monitor stdio as well seems
impossible.


-- 
                                                                Gilles.

Re: [Adeos-main] Reworking ipipe timer subsystem,

[Jan Kiszka]

[-- Attachment #1: Type: text/plain, Size: 5818 bytes --]

On 2012-04-02 22:41, Gilles Chanteperdrix wrote:
> On 04/02/2012 05:54 PM, Jan Kiszka wrote:
>> On 2012-04-02 17:39, Gilles Chanteperdrix wrote:
>>> On 02/24/2012 03:40 PM, Philippe Gerum wrote:
>>>> On 02/24/2012 01:28 PM, Gilles Chanteperdrix wrote:
>>>>> On 02/20/2012 05:46 PM, Philippe Gerum wrote:
>>>>>> On 02/19/2012 08:43 PM, Gilles Chanteperdrix wrote:
>>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> restarting the ipipe-core is the good opportunity to look a bit at our
>>>>>>> current state and think about what we could improve. On ARM, at least,
>>>>>>> the thing we could improve is the timer subsystem. A long time ago,
>>>>>>> linux has switched to a system allowing to select at run-time which
>>>>>>> timer to use, and we do not really benefit from this, what timer we use
>>>>>>> is selected at compile time, resulting in a massive ifdefery on arm, and
>>>>>>> even on x86, we have to select at compile time whether using the 8254 or
>>>>>>> APIC, whereas we could decide to use whatever linux is using, even say
>>>>>>> HPET, without any compilation option. That is assuming we want to move
>>>>>>> the x86 timer-specific code from xenomai to I-pipe.
>>>>>>>
>>>>>>> The idea to reach this goal would be to add some ipipe specific members
>>>>>>> to the struct clock_event_device, the way we do for the interrupt
>>>>>>> controller:
>>>>>>> - a CLOCK_EVT_FEAT_IPIPE would signal that the clockevent device is
>>>>>>> ipipe capable, meaning that it implements the following callback
>>>>>>> - ipipe_steal would be called when stealing the timer, we could decide
>>>>>>> to call this callback either as part of ipipe_request_timer, or with a
>>>>>>> specific ipipe_steal_timer call, currently we simply set
>>>>>>> __ipipe_mach_timerstolen to 1, but it is pure luck that we never needed
>>>>>>> something more complicated, besides, we may want to start a timer that
>>>>>>> was not started by linux so, we would put its initialization here;
>>>>>>> - ipipe_stolen would record whether the timer is stolen
>>>>>>> - ipipe_min_delta_ticks, ipipe_max_delta_ticks would be used by the
>>>>>>> ipipe_set_next_event callback
>>>>>>> - ipipe_ack would be called to ack the timer interrupt the way we
>>>>>>> currently do it currently on arm with __ipipe_mach_acktimer
>>>>>>> - ipipe_set_next_event would program the next timer shot, the way it is
>>>>>>> currently done in __ipipe_mach_set_dec.
>>>>>>>
>>>>>>> All this is pretty straightforward, but there is still a question: how
>>>>>>> does ipipe_request_timer select a timer. The idea is that on platform
>>>>>>> without PIC muting, it is probably more efficient to use the same timer
>>>>>>> for linux and xenomai. But on platforms with PIC muting, we could want
>>>>>>> to select a different timer for linux and xenomai, but how do we find
>>>>>>> it, what if linux has not selected a timer because it is unusable on
>>>>>>> that platform?
>>>>>>
>>>>>> Checking the clock device mode for CLOCK_EVT_MODE_SHUTDOWN, and falling
>>>>>> back to sharing the active kernel tick device + disabling PIC muting?
>>>>>
>>>>> OK. Another question is: do we want to move x86 timer handling from
>>>>> xenomai to ipipe. If not, we have to find a way to support the two
>>>>> possible configurations. What we could do is using the timer name in
>>>>> ipipe_request_tickdev: if a timer name is supplied, we keep the old
>>>>> implementation, if no timer name is supplied, we use the newho
>>>>> implementation which looks for the best candidate with the
>>>>> CLOCK_EVT_FEAT_IPIPE bit.
>>>>>
>>>>>
>>>>
>>>> Yes, makes sense. At any rate, handling the real-time timer the way we 
>>>> want for Xenomai directly from the pipeline is the only sane option. We 
>>>> only have to be careful about backward compatibility of the newest core 
>>>> pipelines with 2.6.x, until we stop maintaining this branch in favor of 
>>>> 3.x. We may also move ipipe_request_tckdev() to the compat module fully, 
>>>> removing it from the current API if that makes sense.
>>>>
>>>
>>> For those who would like to follow, the result, a bit different from what
>>> was originally planned is the interface implemented by this file:
>>> http://git.xenomai.org/?p=ipipe-gch.git;a=blob;f=kernel/ipipe/timer.c;h=b9936469652d8fe998157d155fda77df81f0425a;hb=52d36aa86d5c5d463d86d384ad717f26ec96ef8c
>>>
>>> And ARM and x86 architectures were re-factored over this interface. As 
>>> an example, the implementation of x86 timers is in this patch:
>>> http://git.xenomai.org/?p=ipipe-gch.git;a=commitdiff;h=52d36aa86d5c5d463d86d384ad717f26ec96ef8c;hp=675a8ed4365eb1f23b098f913caf40e4dc792b80
>>>
>>> 8254, local APIC and HPET in legacy mode were tested, even selected 
>>> at run-time. Only per-cpu HPET remains to be tested (the hardware 
>>> I have does not support it).
>>
>> FWI, QEMU (w/ or w/o KVM) can emulated enough HPET timers, also with MSI
>> support, but that was broken in I-pipe last time I checked. Use -global
>> hpet.timers=4 (or more for more CPUs) and -global hpet.msi=on.
> 
> No luck, I am using qemu 0.12.5, there is no -global option documented,

Err, that's prehistoric. Use stable 1.0.x at least to receive proper
HPET support.

> and these two values have no effect. Is there any way to have both the
> kernel console directly in the terminal where qemu is launched, and a
> way to stop qemu by hitting ctrl-C ?
> 
> -serial stdio is what I want, but having -monitor stdio as well seems
> impossible.

-serial mon:stdio will establish a multiplexer between monitor and
serial port on stdio. Switch between both via CTRL-A. Monitor commands
stop & cont will control the guest execution.

Also, if you want to debug your guest, use -s and gdb vmlinux / tar rem
:1234.

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 262 bytes --]

Re: [Adeos-main] Reworking ipipe timer subsystem,

[Jan Kiszka]

[-- Attachment #1: Type: text/plain, Size: 431 bytes --]

On 2012-04-02 22:56, Jan Kiszka wrote:
>> No luck, I am using qemu 0.12.5, there is no -global option documented,
> 
> Err, that's prehistoric. Use stable 1.0.x at least to receive proper
> HPET support.

Oh, and there is one further pitfall: You need to provide
-no-kvm-irqchip to use the HPET with MSI support because qemu-kvm does
not forward those MSIs to the kernel irqchip model. I'm sitting on
patches...

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 262 bytes --]

Re: [Adeos-main] Reworking ipipe timer subsystem,

[Gilles Chanteperdrix]

On 04/02/2012 10:59 PM, Jan Kiszka wrote:
> On 2012-04-02 22:56, Jan Kiszka wrote:
>>> No luck, I am using qemu 0.12.5, there is no -global option documented,
>>
>> Err, that's prehistoric. Use stable 1.0.x at least to receive proper
>> HPET support.
> 
> Oh, and there is one further pitfall: You need to provide
> -no-kvm-irqchip to use the HPET with MSI support because qemu-kvm does
> not forward those MSIs to the kernel irqchip model. I'm sitting on
> patches...

Yes, I needed that. It works now, except that I could not find how to
use an NFS root filesystem. But with an ext3 file-backed filesystem, I
could get that:

# cat /proc/interrupts
           CPU0       CPU1
  0:       2235          0   IO-APIC-edge      timer
  1:          8          0   IO-APIC-edge      i8042
  4:        983          0   IO-APIC-edge      serial
  8:          1          0   IO-APIC-edge      rtc0
  9:          0          0   IO-APIC-fasteoi   acpi
 12:        111          0   IO-APIC-edge      i8042
 14:        146          0   IO-APIC-edge      ata_piix
 15:          9          0   IO-APIC-edge      ata_piix
 40:        996          0  HPET_MSI-edge      hpet2
 41:          0        466  HPET_MSI-edge      hpet3
NMI:          0          0   Non-maskable interrupts
LOC:         38         14   Local timer interrupts
SPU:          0          0   Spurious interrupts
PMI:          0          0   Performance monitoring interrupts
IWI:          0          0   IRQ work interrupts
RES:        798        828   Rescheduling interrupts
CAL:          1        168   Function call interrupts
TLB:         11         19   TLB shootdowns
TRM:          0          0   Thermal event interrupts
THR:          0          0   Threshold APIC interrupts
MCE:          0          0   Machine check exceptions
MCP:          1          1   Machine check polls
ERR:          0
MIS:          0
# cat /proc/xenomai/timer
status=on+watchdog:setup=10630:clock=771280539422:timerdev=hpet2:clockdev=tsc
# cat /proc/xenomai/irq
  IRQ         CPU0        CPU1
   40:       44976           0         [timer0]
   41:           0        7828         [timer1]
 4355:           6           3         [reschedule]
 4356:           0           1         [timer-ipi]
 4357:           0           0         [sync]
 4419:         118           2         [virtual]

And the latency test runs on both processor (albeit with "simulated"
latencies).

So, this also allows verifying that Xenomai now support different timer
irqs on different cpus.

-- 
                                                                Gilles.

Re: [Adeos-main] Reworking ipipe timer subsystem,

[Jan Kiszka]

[-- Attachment #1: Type: text/plain, Size: 3047 bytes --]

On 2012-04-02 23:55, Gilles Chanteperdrix wrote:
> On 04/02/2012 10:59 PM, Jan Kiszka wrote:
>> On 2012-04-02 22:56, Jan Kiszka wrote:
>>>> No luck, I am using qemu 0.12.5, there is no -global option documented,
>>>
>>> Err, that's prehistoric. Use stable 1.0.x at least to receive proper
>>> HPET support.
>>
>> Oh, and there is one further pitfall: You need to provide
>> -no-kvm-irqchip to use the HPET with MSI support because qemu-kvm does
>> not forward those MSIs to the kernel irqchip model. I'm sitting on
>> patches...
> 
> Yes, I needed that. It works now, except that I could not find how to
> use an NFS root filesystem. But with an ext3 file-backed filesystem, I
> could get that:

If your NFS server runs on the host and you use userspace networking
(default without additional parameters), the guest should be able to
reach the server under 10.0.2.2 and use an IP like 10.0.2.15 (or dhcp).
However, I recently failed to get this working as well but didn't dig
deeper.

> 
> # cat /proc/interrupts
>            CPU0       CPU1
>   0:       2235          0   IO-APIC-edge      timer
>   1:          8          0   IO-APIC-edge      i8042
>   4:        983          0   IO-APIC-edge      serial
>   8:          1          0   IO-APIC-edge      rtc0
>   9:          0          0   IO-APIC-fasteoi   acpi
>  12:        111          0   IO-APIC-edge      i8042
>  14:        146          0   IO-APIC-edge      ata_piix
>  15:          9          0   IO-APIC-edge      ata_piix
>  40:        996          0  HPET_MSI-edge      hpet2
>  41:          0        466  HPET_MSI-edge      hpet3
> NMI:          0          0   Non-maskable interrupts
> LOC:         38         14   Local timer interrupts
> SPU:          0          0   Spurious interrupts
> PMI:          0          0   Performance monitoring interrupts
> IWI:          0          0   IRQ work interrupts
> RES:        798        828   Rescheduling interrupts
> CAL:          1        168   Function call interrupts
> TLB:         11         19   TLB shootdowns
> TRM:          0          0   Thermal event interrupts
> THR:          0          0   Threshold APIC interrupts
> MCE:          0          0   Machine check exceptions
> MCP:          1          1   Machine check polls
> ERR:          0
> MIS:          0
> # cat /proc/xenomai/timer
> status=on+watchdog:setup=10630:clock=771280539422:timerdev=hpet2:clockdev=tsc
> # cat /proc/xenomai/irq
>   IRQ         CPU0        CPU1
>    40:       44976           0         [timer0]
>    41:           0        7828         [timer1]
>  4355:           6           3         [reschedule]
>  4356:           0           1         [timer-ipi]
>  4357:           0           0         [sync]
>  4419:         118           2         [virtual]
> 
> And the latency test runs on both processor (albeit with "simulated"
> latencies).
> 
> So, this also allows verifying that Xenomai now support different timer
> irqs on different cpus.
> 

Great to hear!

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 262 bytes --]

Re: [Adeos-main] Reworking ipipe timer subsystem,

[Gilles Chanteperdrix]

On 04/02/2012 11:58 PM, Jan Kiszka wrote:
> On 2012-04-02 23:55, Gilles Chanteperdrix wrote:
>> On 04/02/2012 10:59 PM, Jan Kiszka wrote:
>>> On 2012-04-02 22:56, Jan Kiszka wrote:
>>>>> No luck, I am using qemu 0.12.5, there is no -global option documented,
>>>>
>>>> Err, that's prehistoric. Use stable 1.0.x at least to receive proper
>>>> HPET support.
>>>
>>> Oh, and there is one further pitfall: You need to provide
>>> -no-kvm-irqchip to use the HPET with MSI support because qemu-kvm does
>>> not forward those MSIs to the kernel irqchip model. I'm sitting on
>>> patches...
>>
>> Yes, I needed that. It works now, except that I could not find how to
>> use an NFS root filesystem. But with an ext3 file-backed filesystem, I
>> could get that:
> 
> If your NFS server runs on the host and you use userspace networking
> (default without additional parameters), the guest should be able to
> reach the server under 10.0.2.2 and use an IP like 10.0.2.15 (or dhcp).
> However, I recently failed to get this working as well but didn't dig
> deeper.

Well, with -net user, I do not get any network interface on the
simulated kernel. Maybe there a special network driver to enable in the
kernel? The documentation does not say which network card is simulated,
and I do not see any with lspci.

Something else, is it possible to run kvm using SCHED_FIFO policy? I
tried that and I almost got a lockup, was probably saved by throttling.

-- 
                                                                Gilles.

Re: [Adeos-main] Reworking ipipe timer subsystem,

[Jan Kiszka]

[-- Attachment #1: Type: text/plain, Size: 2058 bytes --]

On 2012-04-03 09:54, Gilles Chanteperdrix wrote:
> On 04/02/2012 11:58 PM, Jan Kiszka wrote:
>> On 2012-04-02 23:55, Gilles Chanteperdrix wrote:
>>> On 04/02/2012 10:59 PM, Jan Kiszka wrote:
>>>> On 2012-04-02 22:56, Jan Kiszka wrote:
>>>>>> No luck, I am using qemu 0.12.5, there is no -global option documented,
>>>>>
>>>>> Err, that's prehistoric. Use stable 1.0.x at least to receive proper
>>>>> HPET support.
>>>>
>>>> Oh, and there is one further pitfall: You need to provide
>>>> -no-kvm-irqchip to use the HPET with MSI support because qemu-kvm does
>>>> not forward those MSIs to the kernel irqchip model. I'm sitting on
>>>> patches...
>>>
>>> Yes, I needed that. It works now, except that I could not find how to
>>> use an NFS root filesystem. But with an ext3 file-backed filesystem, I
>>> could get that:
>>
>> If your NFS server runs on the host and you use userspace networking
>> (default without additional parameters), the guest should be able to
>> reach the server under 10.0.2.2 and use an IP like 10.0.2.15 (or dhcp).
>> However, I recently failed to get this working as well but didn't dig
>> deeper.
> 
> Well, with -net user, I do not get any network interface on the
> simulated kernel. Maybe there a special network driver to enable in the
> kernel? The documentation does not say which network card is simulated,
> and I do not see any with lspci.

qemu-kvm emulates a rtl8139 by default. But, by just specifying -net
user, you disable any network adapter. Just leave it out, -net user -net
nic,model=rtl8139 is default.

> 
> Something else, is it possible to run kvm using SCHED_FIFO policy? I
> tried that and I almost got a lockup, was probably saved by throttling.

Yes, but not without some patches and a lot of tuning on both guest and
host side. A standard Linux kernel touches too many device models that
will take a long time to make RT compatible. A simple access to a
virtual graphic adapter will be like accessing a screwed up physical GPU
with horrible latency.

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 262 bytes --]

Re: [Adeos-main] Reworking ipipe timer subsystem,

[Gilles Chanteperdrix]

On 04/03/2012 09:59 AM, Jan Kiszka wrote:
> On 2012-04-03 09:54, Gilles Chanteperdrix wrote:
>> On 04/02/2012 11:58 PM, Jan Kiszka wrote:
>>> On 2012-04-02 23:55, Gilles Chanteperdrix wrote:
>>>> On 04/02/2012 10:59 PM, Jan Kiszka wrote:
>>>>> On 2012-04-02 22:56, Jan Kiszka wrote:
>>>>>>> No luck, I am using qemu 0.12.5, there is no -global option documented,
>>>>>>
>>>>>> Err, that's prehistoric. Use stable 1.0.x at least to receive proper
>>>>>> HPET support.
>>>>>
>>>>> Oh, and there is one further pitfall: You need to provide
>>>>> -no-kvm-irqchip to use the HPET with MSI support because qemu-kvm does
>>>>> not forward those MSIs to the kernel irqchip model. I'm sitting on
>>>>> patches...
>>>>
>>>> Yes, I needed that. It works now, except that I could not find how to
>>>> use an NFS root filesystem. But with an ext3 file-backed filesystem, I
>>>> could get that:
>>>
>>> If your NFS server runs on the host and you use userspace networking
>>> (default without additional parameters), the guest should be able to
>>> reach the server under 10.0.2.2 and use an IP like 10.0.2.15 (or dhcp).
>>> However, I recently failed to get this working as well but didn't dig
>>> deeper.
>>
>> Well, with -net user, I do not get any network interface on the
>> simulated kernel. Maybe there a special network driver to enable in the
>> kernel? The documentation does not say which network card is simulated,
>> and I do not see any with lspci.
> 
> qemu-kvm emulates a rtl8139 by default. But, by just specifying -net
> user, you disable any network adapter. Just leave it out, -net user -net
> nic,model=rtl8139 is default.

How is -net user supposed to work if there is no emulated nic on the
board. I tried -net nic first, but it did not work either, it seems to
use vlans, but I do not have vlans configured on my host nor any desire
to configure them. Is there not a way to simply share the host network
interface with the guest, the way virtualbox does it?

> 
>>
>> Something else, is it possible to run kvm using SCHED_FIFO policy? I
>> tried that and I almost got a lockup, was probably saved by throttling.
> 
> Yes, but not without some patches and a lot of tuning on both guest and
> host side. A standard Linux kernel touches too many device models that
> will take a long time to make RT compatible. A simple access to a
> virtual graphic adapter will be like accessing a screwed up physical GPU
> with horrible latency.

Yes, ok, but my main interest was the timer interrupt. Besides this does
not explain why I get a lockup.

> 
> Jan
> 


-- 
                                                                Gilles.

Re: [Adeos-main] Reworking ipipe timer subsystem,

[Jan Kiszka]

On 2012-04-03 13:06, Gilles Chanteperdrix wrote:
> On 04/03/2012 09:59 AM, Jan Kiszka wrote:
>> On 2012-04-03 09:54, Gilles Chanteperdrix wrote:
>>> On 04/02/2012 11:58 PM, Jan Kiszka wrote:
>>>> On 2012-04-02 23:55, Gilles Chanteperdrix wrote:
>>>>> On 04/02/2012 10:59 PM, Jan Kiszka wrote:
>>>>>> On 2012-04-02 22:56, Jan Kiszka wrote:
>>>>>>>> No luck, I am using qemu 0.12.5, there is no -global option documented,
>>>>>>>
>>>>>>> Err, that's prehistoric. Use stable 1.0.x at least to receive proper
>>>>>>> HPET support.
>>>>>>
>>>>>> Oh, and there is one further pitfall: You need to provide
>>>>>> -no-kvm-irqchip to use the HPET with MSI support because qemu-kvm does
>>>>>> not forward those MSIs to the kernel irqchip model. I'm sitting on
>>>>>> patches...
>>>>>
>>>>> Yes, I needed that. It works now, except that I could not find how to
>>>>> use an NFS root filesystem. But with an ext3 file-backed filesystem, I
>>>>> could get that:
>>>>
>>>> If your NFS server runs on the host and you use userspace networking
>>>> (default without additional parameters), the guest should be able to
>>>> reach the server under 10.0.2.2 and use an IP like 10.0.2.15 (or dhcp).
>>>> However, I recently failed to get this working as well but didn't dig
>>>> deeper.
>>>
>>> Well, with -net user, I do not get any network interface on the
>>> simulated kernel. Maybe there a special network driver to enable in the
>>> kernel? The documentation does not say which network card is simulated,
>>> and I do not see any with lspci.
>>
>> qemu-kvm emulates a rtl8139 by default. But, by just specifying -net
>> user, you disable any network adapter. Just leave it out, -net user -net
>> nic,model=rtl8139 is default.
> 
> How is -net user supposed to work if there is no emulated nic on the
> board. I tried -net nic first, but it did not work either, it seems to
> use vlans, but I do not have vlans configured on my host nor any desire
> to configure them. Is there not a way to simply share the host network
> interface with the guest, the way virtualbox does it?

QEMU vlans have nothing to do with vlan frames on the wire.

Just leave out any -net command line switch and you will get a 8139
attached to a userspace networking stack out of the box.

> 
>>
>>>
>>> Something else, is it possible to run kvm using SCHED_FIFO policy? I
>>> tried that and I almost got a lockup, was probably saved by throttling.
>>
>> Yes, but not without some patches and a lot of tuning on both guest and
>> host side. A standard Linux kernel touches too many device models that
>> will take a long time to make RT compatible. A simple access to a
>> virtual graphic adapter will be like accessing a screwed up physical GPU
>> with horrible latency.
> 
> Yes, ok, but my main interest was the timer interrupt. Besides this does
> not explain why I get a lockup.

E.g. because the guest may spin in its VCPU thread waiting for events
that the IO thread of QEMU cannot deliver as it gets no CPU time.

Jan

-- 
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux

Re: [Adeos-main] Reworking ipipe timer subsystem,

[Gilles Chanteperdrix]

On 04/03/2012 07:38 PM, Jan Kiszka wrote:
> On 2012-04-03 13:06, Gilles Chanteperdrix wrote:
>> On 04/03/2012 09:59 AM, Jan Kiszka wrote:
>>> On 2012-04-03 09:54, Gilles Chanteperdrix wrote:
>>>> On 04/02/2012 11:58 PM, Jan Kiszka wrote:
>>>>> On 2012-04-02 23:55, Gilles Chanteperdrix wrote:
>>>>>> On 04/02/2012 10:59 PM, Jan Kiszka wrote:
>>>>>>> On 2012-04-02 22:56, Jan Kiszka wrote:
>>>>>>>>> No luck, I am using qemu 0.12.5, there is no -global option documented,
>>>>>>>>
>>>>>>>> Err, that's prehistoric. Use stable 1.0.x at least to receive proper
>>>>>>>> HPET support.
>>>>>>>
>>>>>>> Oh, and there is one further pitfall: You need to provide
>>>>>>> -no-kvm-irqchip to use the HPET with MSI support because qemu-kvm does
>>>>>>> not forward those MSIs to the kernel irqchip model. I'm sitting on
>>>>>>> patches...
>>>>>>
>>>>>> Yes, I needed that. It works now, except that I could not find how to
>>>>>> use an NFS root filesystem. But with an ext3 file-backed filesystem, I
>>>>>> could get that:
>>>>>
>>>>> If your NFS server runs on the host and you use userspace networking
>>>>> (default without additional parameters), the guest should be able to
>>>>> reach the server under 10.0.2.2 and use an IP like 10.0.2.15 (or dhcp).
>>>>> However, I recently failed to get this working as well but didn't dig
>>>>> deeper.
>>>>
>>>> Well, with -net user, I do not get any network interface on the
>>>> simulated kernel. Maybe there a special network driver to enable in the
>>>> kernel? The documentation does not say which network card is simulated,
>>>> and I do not see any with lspci.
>>>
>>> qemu-kvm emulates a rtl8139 by default. But, by just specifying -net
>>> user, you disable any network adapter. Just leave it out, -net user -net
>>> nic,model=rtl8139 is default.
>>
>> How is -net user supposed to work if there is no emulated nic on the
>> board. I tried -net nic first, but it did not work either, it seems to
>> use vlans, but I do not have vlans configured on my host nor any desire
>> to configure them. Is there not a way to simply share the host network
>> interface with the guest, the way virtualbox does it?
> 
> QEMU vlans have nothing to do with vlan frames on the wire.
> 
> Just leave out any -net command line switch and you will get a 8139
> attached to a userspace networking stack out of the box.

Ok, I get it, I need -net nic -net user. The first is for the nic in the
guest, the second configures by what means the physical network will be
emulated. I would have liked the qemu guest to appear on my LAN, but
that will do.

-- 
					    Gilles.

Re: [Adeos-main] Reworking ipipe timer subsystem,

[Jan Kiszka]

On 2012-04-03 20:17, Gilles Chanteperdrix wrote:
> Ok, I get it, I need -net nic -net user. The first is for the nic in the
> guest, the second configures by what means the physical network will be
> emulated. I would have liked the qemu guest to appear on my LAN, but
> that will do.

That requires a bridge on the host and a tap device backend. Upcoming
qemu-1.1 will even have a helper daemon to create those tap devices with
raised privileges and allow unprivileged QEMU instances to use them.

In fact, the new style configuration is "-netdev user,id=mynet -device
e1000,netdev=mynet". That avoids the internal vlans and allows for more
efficient networking (virtio frontend + vhost backend).

Well, there is more, and you can easily get lost on the documentation of
old and new features...

Jan

-- 
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux

Re: [Adeos-main] Reworking ipipe timer subsystem,

[Gilles Chanteperdrix]

On 04/03/2012 08:26 PM, Jan Kiszka wrote:
> On 2012-04-03 20:17, Gilles Chanteperdrix wrote:
>> Ok, I get it, I need -net nic -net user. The first is for the nic in the
>> guest, the second configures by what means the physical network will be
>> emulated. I would have liked the qemu guest to appear on my LAN, but
>> that will do.
> 
> That requires a bridge on the host and a tap device backend. Upcoming
> qemu-1.1 will even have a helper daemon to create those tap devices with
> raised privileges and allow unprivileged QEMU instances to use them.

... Or you can put the interface in promiscuous mode and send raw
ethernet packets using the emulated NIC mac address. No bridge, no tap
device, no helper daemon required.

In any case with -net user, I can not use the virtual network to mount
the rootfs using NFS, so, it still does not work.


-- 
					    Gilles.

Re: [Adeos-main] Reworking ipipe timer subsystem,

[Jan Kiszka]

On 2012-04-03 20:34, Gilles Chanteperdrix wrote:
> On 04/03/2012 08:26 PM, Jan Kiszka wrote:
>> On 2012-04-03 20:17, Gilles Chanteperdrix wrote:
>>> Ok, I get it, I need -net nic -net user. The first is for the nic in the
>>> guest, the second configures by what means the physical network will be
>>> emulated. I would have liked the qemu guest to appear on my LAN, but
>>> that will do.
>>
>> That requires a bridge on the host and a tap device backend. Upcoming
>> qemu-1.1 will even have a helper daemon to create those tap devices with
>> raised privileges and allow unprivileged QEMU instances to use them.
> 
> ... Or you can put the interface in promiscuous mode and send raw
> ethernet packets using the emulated NIC mac address. No bridge, no tap
> device, no helper daemon required.

...but still root privileges, otherwise you are unable to send/receive
arbitrary frames over the interface.

> 
> In any case with -net user, I can not use the virtual network to mount
> the rootfs using NFS, so, it still does not work.

That could be a bug. You happen to talk to the maintainer of this ugly
subsystem (sigh...), and as such I would be glad if you could take a
dump with "-net user -net nic -net dump" of the failing interaction
between guest and host. Output will be in qemu-vlan0.pcap in your
working directory.

Jan

-- 
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux

Re: [Adeos-main] Reworking ipipe timer subsystem,

[Gilles Chanteperdrix]

On 04/03/2012 08:39 PM, Jan Kiszka wrote:
> On 2012-04-03 20:34, Gilles Chanteperdrix wrote:
>> On 04/03/2012 08:26 PM, Jan Kiszka wrote:
>>> On 2012-04-03 20:17, Gilles Chanteperdrix wrote:
>>>> Ok, I get it, I need -net nic -net user. The first is for the nic in the
>>>> guest, the second configures by what means the physical network will be
>>>> emulated. I would have liked the qemu guest to appear on my LAN, but
>>>> that will do.
>>>
>>> That requires a bridge on the host and a tap device backend. Upcoming
>>> qemu-1.1 will even have a helper daemon to create those tap devices with
>>> raised privileges and allow unprivileged QEMU instances to use them.
>>
>> ... Or you can put the interface in promiscuous mode and send raw
>> ethernet packets using the emulated NIC mac address. No bridge, no tap
>> device, no helper daemon required.
> 
> ...but still root privileges, otherwise you are unable to send/receive
> arbitrary frames over the interface.



> 
>>
>> In any case with -net user, I can not use the virtual network to mount
>> the rootfs using NFS, so, it still does not work.
> 
> That could be a bug. You happen to talk to the maintainer of this ugly
> subsystem (sigh...), and as such I would be glad if you could take a
> dump with "-net user -net nic -net dump" of the failing interaction
> between guest and host. Output will be in qemu-vlan0.pcap in your
> working directory.

No bug, it was a configuration issue (missing "insecure" in /etc/exports).


-- 
                                                                Gilles.