Re: [patch] lazy TSS's I/O bitmap copy ...

[Davide Libenzi]

On Mon, 23 Aug 2004, Andi Kleen wrote:

> On Mon, 23 Aug 2004 14:23:35 -0700 (PDT)
> Davide Libenzi <davidel@xxxxxxxxxxxxxxx> wrote:
> 
> > 
> > The following patch implements a lazy I/O bitmap copy for the i386 
> > architecture. With I/O bitmaps now reaching considerable sizes, if the 
> > switched task does not perform any I/O operation, we can save the copy 
> > altogether. In my box X is working fine with the following patch, even if 
> > more test would be required.
> 
> IMHO this needs benchmarks first to prove that the additional 
> exception doesn't cause too much slow down.

Yes, of course.


> >  asmlinkage void do_general_protection(struct pt_regs * regs, long error_code)
> >  {
> > +	int cpu = smp_processor_id();
> > +	struct tss_struct *tss = init_tss + cpu;
> > +	struct task_struct *tsk = current;
> > +	struct thread_struct *tsk_th = &tsk->thread;
> > +
> > +	/*
> > +	 * Perform the lazy TSS's I/O bitmap copy. If the TSS has an
> > +	 * invalid offset set (the LAZY one) and the faulting thread has
> > +	 * a valid I/O bitmap pointer, we copy the I/O bitmap in the TSS
> > +	 * and we set the offset field correctly. Then we let the CPU to
> > +	 * restart the faulting instruction.
> > +	 */
> 
> I don't like it very much that most GPFs will be executed twice now
> when the process has ioperm enabled.
> This will confuse debuggers and could have other bad side effects.
> Checking the EIP would be better.

The eventually double GPF would happen only on TSS-IObmp-lazy tasks, ie 
tasks using the I/O bitmap. The check for the I/O opcode can certainly be 
done though, even if it'd make the code a little bit more complex.



- Davide

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/