icache sync private rump component
Hi, I'd like to commit a private rump component that adds a hypercall for synching icache. This will help us to test bpfjit and npf on arm and mips platforms. I already sent a couple of emails to Antti but because he hasn't replied yet and the branching date is fast approaching, I thought I'd give a heads up to the community. I'll commit my changes if I don't hear any objections in the next few days. Basically, this component resides in librumpkern_sljit and it exposes one function: int rumpcomp_sync_icache(void *, uint64_t); This declaration doesn't go to any public header file because it's only being used inside librumpkern_sljit. On arm, rumpcomp_sync_icache() makes ARM_SYNC_ICACHE sysarch syscall while on mips it calls _cacheflush() which is defined in libc. On the kernel side, both arm and mips use a global object with a bunch of function pointers to various cpu-related routines. Those objects are defined in cpufunc.c and cache.c, respectively. For the rump kernel, I add barebone versions of those objects with only one non-NULL function pointer for icache_rync_range routine. To compile mips/cache.h in rump kernel, I needed to add -DMIPS3=1 to Makefile.rump for mips platforms. This is the only change outside of sljit scope. Alex
Re: icache sync private rump component
On Jul 19, 2014 10:01 AM, Alexander Nasonov al...@yandex.ru wrote: To compile mips/cache.h in rump kernel, I needed to add -DMIPS3=1 to Makefile.rump for mips platforms. This is the only change outside of sljit scope. You surely can't do that, people may be trying to compile on non mips3 hardware? Justin
Re: icache sync private rump component
Justin Cormack wrote: On Jul 19, 2014 10:01 AM, Alexander Nasonov al...@yandex.ru wrote: To compile mips/cache.h in rump kernel, I needed to add -DMIPS3=1 to Makefile.rump for mips platforms. This is the only change outside of sljit scope. You surely can't do that, people may be trying to compile on non mips3 hardware? Pre mips3 or post mips3? Or even completely different port like amd64? If rump kernel worked without setting any of these variables, chances are, it will work with -DMIPS3. I can actually change it to -DMIPS1. Alex
Re: icache sync private rump component
Alexander Nasonov wrote: Justin Cormack wrote: On Jul 19, 2014 10:01 AM, Alexander Nasonov al...@yandex.ru wrote: To compile mips/cache.h in rump kernel, I needed to add -DMIPS3=1 to Makefile.rump for mips platforms. This is the only change outside of sljit scope. You surely can't do that, people may be trying to compile on non mips3 hardware? Pre mips3 or post mips3? Or even completely different port like amd64? If rump kernel worked without setting any of these variables, chances are, it will work with -DMIPS3. I can actually change it to -DMIPS1. Wikipedia (https://en.wikipedia.org/wiki/MIPS_architecture) states that Each revision is a superset of its predecessors. So, I can use MIPS I as a base and set -DMIPS1=1 for rump. Does it sound good? Alex
Re: icache sync private rump component
Alexander Nasonov wrote: Wikipedia (https://en.wikipedia.org/wiki/MIPS_architecture) states that Each revision is a superset of its predecessors. This is strictly true for MIPS I to MIPS V but we also have MIPS 32 and MIPS 64. MIPS 32 is based on MIPS II (with some features from MIPS III, IV and V) while MIPS 64 is based on MIPS V. So, -DMIPS1=1 should be fine for all ports. Alex
Re: icache sync private rump component
Alexander Nasonov al...@yandex.ru writes: I'd like to commit a private rump component that adds a hypercall for synching icache. This will help us to test bpfjit and npf on arm and mips platforms. Why is this private? If it's generally necessary, it should become part of the standard interface.Is it just that sljit is the only place that is currently creating code that is later executed? pgpoRg1DG39Ja.pgp Description: PGP signature
Re: icache sync private rump component
Greg Troxel wrote: Why is this private? If it's generally necessary, it should become part of the standard interface.Is it just that sljit is the only place that is currently creating code that is later executed? I made a change to the standard place about a month ago but Antti objected and I rolled it back. We discussed it on source-changes-d. If my understaning is correct, Antti would like to see a generic interface that handles other related things like W^X protection. In the end we agreed on creating a private component. Yes, sljit is the only place that generate code on the fly. Other executable code is handled by rt-linker. Alex pgpnhjA0K1EsT.pgp Description: PGP signature
Re: icache sync private rump component
Alexander Nasonov al...@yandex.ru writes: Greg Troxel wrote: Why is this private? If it's generally necessary, it should become part of the standard interface.Is it just that sljit is the only place that is currently creating code that is later executed? I made a change to the standard place about a month ago but Antti objected and I rolled it back. We discussed it on source-changes-d. If my understaning is correct, Antti would like to see a generic interface that handles other related things like W^X protection. In the end we agreed on creating a private component. Yes, sljit is the only place that generate code on the fly. Other executable code is handled by rt-linker. (My comments should not be read as objecting or approving.) That makes sense. Before, it seemed natural to need a rump hypercall for cache syncing.But then I realized that this still seems odd, as I would expect callers that need this to be calling some kernel interface, which would be implemented for both hardware and hypervisor situations, and then in the hypervisor code probably calling a new system call to have the underlying system do it. Are you saying that's the evenntual goal and this is just a temporary hack to make sjlit work on rump? pgpb7e_Ik5n7T.pgp Description: PGP signature
Re: icache sync private rump component
19.07.2014, 19:57, Greg Troxel g...@ir.bbn.com: Are you saying that's the evenntual goal and this is just a temporary hack to make sjlit work on rump? Committed code will have a comment stating that it's temporary but because I don't know what exactly should be in the new interface I can't promise that I can undertake that work. Alex PS sorry for the formatting, I'm replying from a tablet. -- Alex
Re: troubles with an USB touch screen
thanks for your reply; On Fri, Jul 18, 2014 at 11:50:39PM +0200, Yorick Hardy wrote: Which X mouse driver are you using? I was using mouse, I now switched to ws What does xinput list output? (And also xinput list Mouse0 for Mouse0, change to whatever your mouse is called in xinput list.) # xinput list Virtual core pointer id=2[XPointer] Virtual core keyboard id=3[XKeyboard] Virtual core XTEST pointerid=4[XExtensionPointer] Virtual core XTEST keyboard id=5[XExtensionKeyboard] Mouse0id=6[XExtensionPointer] Keyboard0 id=7[XExtensionKeyboard] # xinput list Mouse0 Mouse0id=6[XExtensionPointer] Type is TOUCHSCREEN Num_buttons is 5 Num_axes is 2 Mode is Absolute Motion_buffer is 256 Axis 0 : Min_value is 0 Max_value is 1279 Resolution is 1 Axis 1 : Min_value is 0 Max_value is 799 Resolution is 1 I needed to use ws(4): $ cat /etc/X11/xorg.conf Section InputDevice Identifier WSMouse Driver ws Option AutoServerLayout true Option Device /dev/wsmouse EndSection If xinput list WSMouse (adjust as needed) includes Type is TOUCHSCREEN then you should be able to xinput --set-prop --type=int --format=32 WSMouse \ WS Pointer Axis Calibration 0 1279 0 799 or something like that. Here WSMouse is the identifier for the device in /etc/X11/xorg.conf. If I understood correctly, 1279 and 799 need to be set much higher for your device. If I remember correctly, the device needs to be attached before starting X. thanks, with this I've been able to get is working properly: xinput --set-prop --type=int --format=32 Mouse0 WS Pointer Axis Calibration 0 9540 0 7210 I hope this information is of some use. Indeed it was very usefull, thanks a lot ! -- Manuel Bouyer bou...@antioche.eu.org NetBSD: 26 ans d'experience feront toujours la difference --
