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 04/12] Nested Virtualization: core

To: Christoph Egger <Christoph.Egger@xxxxxxx>
Subject: RE: [Xen-devel] [PATCH 04/12] Nested Virtualization: core
From: "Dong, Eddie" <eddie.dong@xxxxxxxxx>
Date: Fri, 7 Jan 2011 01:33:56 +0800
Accept-language: en-US
Acceptlanguage: en-US
Cc: Tim, "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>, "Dong, Eddie" <eddie.dong@xxxxxxxxx>, Deegan <Tim.Deegan@xxxxxxxxxx>
Delivery-date: Thu, 06 Jan 2011 09:38:46 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <201101031658.57065.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: <201012201705.06356.Christoph.Egger@xxxxxxx> <1A42CE6F5F474C41B63392A5F80372B231C6D71F@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> <201101031658.57065.Christoph.Egger@xxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AcurXyoT4kJSTOWDSd6JYGgeGF5n8gCZzVog
Thread-topic: [Xen-devel] [PATCH 04/12] Nested Virtualization: core
>> This is overcomplicated. Static table should serve this much simple
>> and efficient.
> The logic to select the right static table will be still needed. I am
> not sure if removing the _xmalloc() call simplifies this part a lot.

It will be much simple. You don't need the nestedhvm_vcpu_iomap_get/put api, 
nor the refcnt.

The thing more important is policy: If you are in favoring of memory size or 
simplicity. If it is for memory size, then you should only allocate 2 io_bitmap 
pages for VMX.

> I appreciate opinions from other people on this.

Besides, ideally we should implement per guest io bitmap page, by reusing L1 
guest io_bitmap + write protection of the page table. At least for both Xen & 
KVM, the io bitmap is not modified at runtime once it is initialized. The 
readibility can be improved & the memory page can be saved. We only need 2 bits 
per L1 guest. 

But if we want simplicity, I am ok too, however the current patch doesn't fit 
for either of the goal.

thx, eddie

Xen-devel mailing list