Re: [Adeos-main] Reworking ipipe timer subsystem,
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. ___ Adeos-main mailing list Adeos-main@gna.org https://mail.gna.org/listinfo/adeos-main
Re: [Adeos-main] Reworking ipipe timer subsystem,
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 ___ Adeos-main mailing list Adeos-main@gna.org https://mail.gna.org/listinfo/adeos-main
Re: [Adeos-main] Reworking ipipe timer subsystem,
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. ___ Adeos-main mailing list Adeos-main@gna.org https://mail.gna.org/listinfo/adeos-main
Re: [Adeos-main] Reworking ipipe timer subsystem,
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 ___ Adeos-main mailing list Adeos-main@gna.org https://mail.gna.org/listinfo/adeos-main
Re: [Adeos-main] Reworking ipipe timer subsystem,
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. ___ Adeos-main mailing list Adeos-main@gna.org https://mail.gna.org/listinfo/adeos-main
Re: [Adeos-main] Reworking ipipe timer subsystem,
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 ___ Adeos-main mailing list Adeos-main@gna.org https://mail.gna.org/listinfo/adeos-main
Re: [Adeos-main] Reworking ipipe timer subsystem,
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. ___ Adeos-main mailing list Adeos-main@gna.org https://mail.gna.org/listinfo/adeos-main
Re: [Adeos-main] Reworking ipipe timer subsystem,
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 signature.asc Description: OpenPGP digital signature ___ Adeos-main mailing list Adeos-main@gna.org https://mail.gna.org/listinfo/adeos-main
Re: [Adeos-main] Reworking ipipe timer subsystem,
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. ___ Adeos-main mailing list Adeos-main@gna.org https://mail.gna.org/listinfo/adeos-main
Re: [Adeos-main] Reworking ipipe timer subsystem,
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: 0466 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:798828 Rescheduling interrupts > CAL: 1168 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 CPU0CPU1 >40: 44976 0 [timer0] >41: 07828 [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 signature.asc Description: OpenPGP digital signature ___ Adeos-main mailing list Adeos-main@gna.org https://mail.gna.org/listinfo/adeos-main
Re: [Adeos-main] Reworking ipipe timer subsystem,
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: 0466 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:798828 Rescheduling interrupts CAL: 1168 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 CPU0CPU1 40: 44976 0 [timer0] 41: 07828 [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. ___ Adeos-main mailing list Adeos-main@gna.org https://mail.gna.org/listinfo/adeos-main
Re: [Adeos-main] Reworking ipipe timer subsystem,
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 signature.asc Description: OpenPGP digital signature ___ Adeos-main mailing list Adeos-main@gna.org https://mail.gna.org/listinfo/adeos-main
Re: [Adeos-main] Reworking ipipe timer subsystem,
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.m
Re: [Adeos-main] Reworking ipipe timer subsystem,
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 wa
Re: [Adeos-main] Reworking ipipe timer subsystem,
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, als
Re: [Adeos-main] Reworking ipipe timer subsystem,
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.m
Re: [Adeos-main] Reworking ipipe timer subsystem,
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
Re: [Adeos-main] Reworking ipipe timer subsystem,
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 ___ Adeos-main mailing list Adeos-main@gna.org https://mail.gna.org/listinfo/adeos-main
Re: [Adeos-main] Reworking ipipe timer subsystem,
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. ___ Adeos-main mailing list Adeos-main@gna.org https://mail.gna.org/listinfo/adeos-main
Re: [Adeos-main] Reworking ipipe timer subsystem,
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. ___ Adeos-main mailing list Adeos-main@gna.org https://mail.gna.org/listinfo/adeos-main
Re: [Adeos-main] Reworking ipipe timer subsystem,
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. ___ Adeos-main mailing list Adeos-main@gna.org https://mail.gna.org/listinfo/adeos-main
Re: [Adeos-main] Reworking ipipe timer subsystem,
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. ___ Adeos-main mailing list Adeos-main@gna.org https://mail.gna.org/listinfo/adeos-main
