Re: [PATCH] Add I/O hypercalls for i386 paravirt

[Andi Kleen <ak@suse.de>]

On Wed, Aug 22, 2007 at 10:07:47AM -0700, Zachary Amsden wrote:
> >Also I fail to see the fundamental speed difference between
> >
> >mov index,register
> >int 0x...
> >...
> >switch (register) 
> >case xxxx: do emulation
> >  
> 
> Int (on p4 == ~680 cycles).
> 
> >versus
> >
> >out ...
> >#gp
> >-> switch (*eip) {
> >case 0xee:  /* etc. */ 
> >	do emulation
> >  
> 
> GP = ~2000 cycles.

How is that measured? In a loop? In the same pipeline state?

It seems a little dubious to me.

> 
> >>to verify protection in the page tables mapping the page allows 
> >>execution (P, !NX, and U/S check).  This is a lot more expensive than a 
> >>    
> >
> >When the page is not executable or not present you get #PF not #GP. 
> >So the hardware already checks that.
> >
> >The only case where you would need to check yourself is if you emulate
> >NX on non NX capable hardware, but I can't see you doing that.
> >  
> 
> No, it doesn't.  Between the #GP and decode, you have an SMP race where 
> another processor can rewrite the instruction.

That can be ignored imho. If the page goes away you'll notice
when you handle the page fault on read. If it becomes NX then the execution
just happened to be logically a little earlier.

My other objection to this scheme is that you'll change a zillion
drivers you'll never emulate which seems just stupid. You could
just change the small handful that you emulate to use hypercalls.

Or easier to just write a backend for the lguest virtio drivers,
that will be likely faster in the end anyways than this gross
hack.

Really LinuxHAL^wparavirt ops is already so complicated that
any new hooks need an extremly good justification and that is
just not here for this.

We can add it if you find an equivalent number of hooks
to eliminate.

-Andi