Andi Kleen wrote: > Isn't it needed always for any kind of port- or MM-IO? Replacing all > these accesses with para virtualized drivers may be too much. > Yes, but virtualized drivers are becoming more common, so technically it is possible. I'm not saying it needs to be done for the driver case, especially not for real I/O drivers. > I would prefer to not add hooks for everything in Linux, > but just emulate the non performance critical and simple stuff > that can be trapped. > I'm undecided on that one, and could be convinced either way. If there is some real benefit to having a non-instruction decoding hypervisor, we should probably make it possible. We actually rely on having paravirtualized translations for some operations that could be trapped, such as invlpg (for performance reasons), but also for lgdt (for reasons so scary I won't get into it). Course I could fix these "errata", but if the final spec we come up with says all privileged instructions must be para-virtualized, then I don't need to. > See the x86 instruction decoding as a weird, but very well specified, > way to encode a hypercall. > Yes, but you run into nasty problems with segmentation hardware (especially, 16-bit code segments) and SMP guests which can race against you modifying code, or changing PTE protection bits on instructions that cross page boundaries. Course, PV guests should not be doing this, but you still have to make sure the hypervisor doesn't somehow implicitly trust the guest leading to some type of subversion of the hypervisor (stringing redundant operand prefixes to read data across cross a segment boundary because the hypervisor assumed that the instruction stream was correct comes to mind). Zach
