This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


RE: [Xen-devel] [PATCH 07/14] Nested Virtualization: trap

To: Christoph Egger <Christoph.Egger@xxxxxxx>, Tim Deegan <Tim.Deegan@xxxxxxxxxx>
Subject: RE: [Xen-devel] [PATCH 07/14] Nested Virtualization: trap
From: "Dong, Eddie" <eddie.dong@xxxxxxxxx>
Date: Thu, 19 Aug 2010 22:12:01 +0800
Accept-language: en-US
Acceptlanguage: en-US
Cc: "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>, "Dong, Eddie" <eddie.dong@xxxxxxxxx>
Delivery-date: Thu, 19 Aug 2010 07:18:34 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <201008191232.00338.Christoph.Egger@xxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <1A42CE6F5F474C41B63392A5F80372B22A3E5B97@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> <1A42CE6F5F474C41B63392A5F80372B22A3E5C06@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> <20100819083552.GF20252@xxxxxxxxxxxxxxxxxxxxxxx> <201008191232.00338.Christoph.Egger@xxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: Acs/iex0f+CDsSuVTtSJLVYpF1RMKAAHBDZw
Thread-topic: [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 

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 

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