On 05/08/2013 10:20 AM, Konrad Rzeszutek Wilk wrote:
>
> If I am reading you right the #1 issue is that you don't know whether
> a certain paravirt instruction has any side-effects and as such you don't
> feel that you can treat it like an equivalent instruction that is defined
> in the Intel SDM?
>
> And that means that any development work you have in the pipeline is
> affected because you don't have the documentation on hand and are unsure
> whether you will break something?
>
That is, indeed, the #1 issue (and you and I have discussed it at
length, obviously.)
There are a few other issues:
2. some of the paravirt_ops are plain wrong. Most of the really big
problems are in the MMU-related ones, but as an easily-explained example
that I ran into the other day:
read_cr4_safe() assumes that there is no useful distinction between "cr4
is zero" and "cr4 doesn't exist". Unfortunately, this is an invalid
assumption. It would be a five-minute fix in the normal case, but since
it is paravirtualized, fixing it involves grokking the semantics of each
PV layer, including any of the hypercalls that may be involved.
In this particular example I think the answer is actually reasonable
simple, because I don't think any of the hypervisors support running on
pre-cr4 hardware (basically 486 at this point.)
3. "Let's add another hook" becomes a far too easy solution to new problems.
4. Performance and maintainability impact of having to support multiple
code flows with different semantics. The semantics of the Xen MMU, in
particular, is actually quite different from the x86 MMU.
5. Performance and maintainability impact of a maze of twisty little
functions, all different. For example, in the case of some of the MSR
functions, we actually end up telling the compiler to combine and break
up the two 32-bit halves into a 64-bit register multiple times, because
the functions don't actually match up. I still don't understand why we
don't just patch out the rdmsr/wrmsr instructions, using those registers.
-hpa
_______________________________________________
Lguest mailing list
Lguest@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/lguest
