|
xen-devel
RE: [Xen-devel] [PATCH 07/14] Nested Virtualization: trap
>> It calls out to arch-specific code to do the intercept check and the
>> vmexit. It could be tidied up a bit and the interfaces could change
>> but this looks like about the least amount of sharing there could be
>> on this path. I can't see anything objectionable.
>
> Correct. The key to make this possible is the generic exitcode
> mechanism.
>
> Eddie: In an other mail you said, that the generic exitcode is
> overcomplicated. I have the impression that you do not
> realise that the unification of the exitcodes makes that much
> code shareable at all. No, I do not unified *all* exitcodes - I don't
> know if that is even possible.
> I only unified a subset that is actually used in the generic code.
Even with this partial unified generic code, we have to create 280+ new LOC.
I am not convinced these unified vmexit/entry handler save code, I had a rough
estimation:
patch4, hook API head definition: 159 Lines of patch, estimate 100 Line of new
code. Note this is not a must code, but as common API definition due to the
wrapping reason .
patch5, 837 lines of patch: 800 new lines for common code. Assume 20% overhead
due to wrapping (common<->arch crossing) and additional conversion (generic <->
arch), that means we saved 800*80%=640 Lines, but add 800*20%=160 Lines. We
saved 640-160=480 lines.
patch7, 50 lines of common, 20-30 lines are overhead due to wrapping (Line
14-41). The saving is very limited.
However at least patch 10 added 140 new lines for wrapper only to convert
between common & arch format (see my another mail), which means 140* 2=280 new
lines.
So the total saving at most is 480-280=200 lines. On the other hand, light
weight wrapper, i.e. arch specifc code goes to common only when it request some
common functionality (more primary APIs), like single layer virtualization
does. It could also save 200 lines or even more.
Is it worthy to bothering us so much for now?
Thx , eddie
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
Home