search for: ioperm

Hi, I''m trying to port AMD VGA passthru patch to the latest XEN and vanila kernel and I got SIGSEGV in static void ati_hw_out(uint16_t hport, uint32_t data) { ioperm(gfx_info.host_pio_base, gfx_info.pio_size, 1); asm volatile ("out %1, %0"::"Nd"(hport),"a"(data)); ioperm(gfx_info.host_pio_base, gfx_info.pio_size, 0); } I tried old 2.6.32 XEN kernel and there is no such problem. It looks related to arch/x86/kernel/iopor...

Commit 111e7b15cf10f6 ("x86/ioperm: Extend IOPL config to control ioperm() as well") reworked the iopl syscall to use I/O bitmaps. Unfortunately this broke Xen PV domains using that syscall as there is currently no I/O bitmap support in PV domains. Add I/O bitmap support via a new paravirt function update_io_bitmap which Xen...

Commit 111e7b15cf10f6 ("x86/ioperm: Extend IOPL config to control ioperm() as well") reworked the iopl syscall to use I/O bitmaps. Unfortunately this broke Xen PV domains using that syscall as there is currently no I/O bitmap support in PV domains. Add I/O bitmap support via a new paravirt function update_io_bitmap which Xen...

On 18.02.20 22:03, Thomas Gleixner wrote: > Juergen Gross <jgross at suse.com> writes: >> Commit 111e7b15cf10f6 ("x86/ioperm: Extend IOPL config to control >> ioperm() as well") reworked the iopl syscall to use I/O bitmaps. >> >> Unfortunately this broke Xen PV domains using that syscall as there >> is currently no I/O bitmap support in PV domains. >> >> Add I/O bitmap support via...

On 18.02.20 22:03, Thomas Gleixner wrote: > Juergen Gross <jgross at suse.com> writes: >> Commit 111e7b15cf10f6 ("x86/ioperm: Extend IOPL config to control >> ioperm() as well") reworked the iopl syscall to use I/O bitmaps. >> >> Unfortunately this broke Xen PV domains using that syscall as there >> is currently no I/O bitmap support in PV domains. >> >> Add I/O bitmap support via...

Juergen Gross <jgross at suse.com> writes: > Commit 111e7b15cf10f6 ("x86/ioperm: Extend IOPL config to control > ioperm() as well") reworked the iopl syscall to use I/O bitmaps. > > Unfortunately this broke Xen PV domains using that syscall as there > is currently no I/O bitmap support in PV domains. > > Add I/O bitmap support via a new paravirt function...

On Sun, 2 Nov 2014 09:33:01 -0800 Josh Triplett <josh at joshtriplett.org> wrote: > On the vast majority of modern systems, no processes will use the > userspsace IO syscalls, iopl and ioperm. Add a new config option, > CONFIG_X86_IOPORT, to support configuring them out of the kernel > entirely. Most current systems do not run programs using these > syscalls, so X86_IOPORT does not depend on EXPERT, though it does still > default to y. This isn't unreasonable but ther...

On Sun, 2 Nov 2014 09:33:01 -0800 Josh Triplett <josh at joshtriplett.org> wrote: > On the vast majority of modern systems, no processes will use the > userspsace IO syscalls, iopl and ioperm. Add a new config option, > CONFIG_X86_IOPORT, to support configuring them out of the kernel > entirely. Most current systems do not run programs using these > syscalls, so X86_IOPORT does not depend on EXPERT, though it does still > default to y. This isn't unreasonable but ther...

On Mon, Nov 03, 2014 at 12:10:49PM +0000, One Thousand Gnomes wrote: > On Sun, 2 Nov 2014 09:33:01 -0800 > Josh Triplett <josh at joshtriplett.org> wrote: > > > On the vast majority of modern systems, no processes will use the > > userspsace IO syscalls, iopl and ioperm. Add a new config option, > > CONFIG_X86_IOPORT, to support configuring them out of the kernel > > entirely. Most current systems do not run programs using these > > syscalls, so X86_IOPORT does not depend on EXPERT, though it does still > > default to y. > > This i...

With this patch, x86 and x86-64 share ioport.c, fixing LTP iopl and ioperm testcase failures (on both). We found an iopl testcase failing even on x86 xenlinux. Now x86-64 xenlinux should have the same results regarding the LTP testcases (as far as we tested). Signed-off-by: Li B Xin <li.b.xin@intel.com> Signed-off-by: Jun Nakajima <jun.nakajima@intel.com> J...

> > This isn't unreasonable but there are drivers with userspace helpers that > > use iopl/ioperm type functionality where you should be doing a SELECT of > > X86_IOPORT. The one that comes to mind is the uvesa driver. From a quick > > scan it may these days be the only mainstream one that needs the select > > adding. > > Should kernel drivers really express dependencie...

> > This isn't unreasonable but there are drivers with userspace helpers that > > use iopl/ioperm type functionality where you should be doing a SELECT of > > X86_IOPORT. The one that comes to mind is the uvesa driver. From a quick > > scan it may these days be the only mainstream one that needs the select > > adding. > > Should kernel drivers really express dependencie...

On Mon, Nov 03, 2014 at 03:27:48PM +0000, One Thousand Gnomes wrote: > > > This isn't unreasonable but there are drivers with userspace helpers that > > > use iopl/ioperm type functionality where you should be doing a SELECT of > > > X86_IOPORT. The one that comes to mind is the uvesa driver. From a quick > > > scan it may these days be the only mainstream one that needs the select > > > adding. > > > > Should kernel drivers r...

On 11/03/2014 07:27 AM, One Thousand Gnomes wrote: >>> This isn't unreasonable but there are drivers with userspace helpers that >>> use iopl/ioperm type functionality where you should be doing a SELECT of >>> X86_IOPORT. The one that comes to mind is the uvesa driver. From a quick >>> scan it may these days be the only mainstream one that needs the select >>> adding. >> >> Should kernel drivers really exp...

Some time ago i already tried to get running a Digital Oszilloscope DSO-2100 at the parallel port LPT1. But i give up to get it running. Now i have another problem (http://forum.winehq.org/viewtopic.php?p=38741#38741) and so i have tested this again. This time i added the keys to the registry for direct parport access: Code: REGEDIT4 [HKEY_LOCAL_MACHINE\Software\Wine\VDM]

J?rgen Gro? <jgross at suse.com> writes: > On 18.02.20 22:03, Thomas Gleixner wrote: >> BTW, why isn't stuff like this not catched during next or at least >> before the final release? Is nothing running CI on upstream with all >> that XEN muck active? > > This problem showed up by not being able to start the X server (probably > not the freshest one) in dom0

...totypes, which to me seems more error-prone. If the > stub versions contained any code, rather than just becoming no-ops, I'd > definitely do that. > I concur with this style choice. >> Another nit may be that we should call this CONFIG_SYSCALL_IOPL or >> CONFIG_SYSCALL_IOPERM in keeping with the other CONFIG_SYSCALL_* >> naming thread? Again, I don't really care strongly beyond really >> wanting to use this new feature! :) > > I don't feel strongly about the naming. Ingo? It is sort of a special case here, as this reflects more than one sysc...

On Wed, 29 Oct 2014, Josh Triplett wrote: > v3: Eliminated several #ifdefs, and in particular almost all #ifdefs in > .c files, by adding a macro INIT_SET_IOPL_MASK to use in place of > the initializer for set_iopl_mask, and using __maybe_unused rather > than wrapping function definitions in #ifdef. Rebased on v3.18-rc1. > Recomputed bloat-o-meter. Can you please

On the vast majority of modern systems, no processes will use the userspsace IO syscalls, iopl and ioperm. Add a new config option, CONFIG_X86_IOPORT, to support configuring them out of the kernel entirely. Most current systems do not run programs using these syscalls, so X86_IOPORT does not depend on EXPERT, though it does still default to y. In addition to saving a significant amount of space, thi...

On the vast majority of modern systems, no processes will use the userspsace IO syscalls, iopl and ioperm. Add a new config option, CONFIG_X86_IOPORT, to support configuring them out of the kernel entirely. Most current systems do not run programs using these syscalls, so X86_IOPORT does not depend on EXPERT, though it does still default to y. In addition to saving a significant amount of space, thi...