RE: [PATCH] Calculate correct instruction length fordata-fault VM exits on VT-x systems

RE: [PATCH] Calculate correct instruction length fordata-fault VM exits on VT-x systems

[Ian Pratt]

 
> We could do a similar thing for I/O operations. Basically, 
> generate an upcall into qemu-dm on an MMIO or PIO exit and 
> let qemu-dm deal with it.
> It can do the same trick and emulate a number of instructions 
> (1000?) before returning to the HVM partition. This will 
> eliminate expensive VMCS/VMCB exits on subsequent I/O 
> operations (just consider doing a block write on an IDE 
> device in PIO mode, this is common behavior). It will also 
> eliminate the need for the MMIO instruction emulator in the 
> hypervisor.

Having a full emulator available certainly enables lots of cool tricks
(e.g. the taint tracking example in the paper). You wouldn't want to use
it for all MMIO operations (they're often singletons), but for handling
batches is would be good. It's certainly a good way of handling the 16b
issue on Intel.

I think Alex/Michael/Andrew/Chris would be first to admit that the
curent V2E code isn't a thing of beauty. However, if the emulator was
running in a 'miniguest' this would clean things up substantially. 

It would be cool to see a project that was originally considered to be
firmly a research-only thing make it into mainline Xen.

Here's the paper:
http://www.cs.kuleuven.ac.be/conference/EuroSys2006/papers/p29-ho.pdf

Practical Taint-Based Protection using Demand Emulation
Alex Ho, Michael Fetterman, Christopher Clark,
Andrew Warfield, and Steven Hand
University of Cambridge Computer Laboratory
15 JJ Thomson Avenue
Cambridge CB3 0FD


Ian

RE: [PATCH] Calculate correct instruction length fordata-fault VM exits on VT-x systems

[Leendert van Doorn]

On Sat, 2006-04-29 at 16:48 +0100, Ian Pratt wrote:

> Having a full emulator available certainly enables lots of cool tricks
> (e.g. the taint tracking example in the paper). You wouldn't want to use
> it for all MMIO operations (they're often singletons), but for handling
> batches is would be good. It's certainly a good way of handling the 16b
> issue on Intel.

Why wouldn't you do it on each mmio operation that is not implemented in
the hypervisor? As soon as you have to do the upcall the cost of going
to qemu-dm, or even a miniguest partition, dwarfs the cost of invoking
the emulator.

	Leendert