Re: [Xen-devel] [PATCH 04/12] Nested Virtualization: core

[Christoph Egger <Christoph.Egger@xxxxxxx>]

On Thursday 06 January 2011 18:33:56 Dong, Eddie wrote:
> >> 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.

It is intended that the api behaves like a pool from the caller site
while it is implemented as a singleton.
The refcnt (or should I call it usagecnt) is needed by the singleton design 
pattern.

When I remove the refcnt then I have to implement the api as a real pool
which will result in allocating an io bitmap for each vcpu for each l1 guest
at runtime.

>
> 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.

That will work fine with 4kb pages but I guess it won't be very
efficient with 2MB and 1GB pages. Most time will be spent with emulating write 
accesses to the address ranges outside of the io bitmaps with large pages.

> At least for both Xen & KVM, the io bitmap is not modified at runtime once
> it is initialized. 

Yep, that's why we only need to deal with four possible patterns of
shadow io bitmaps in Xen. We can't assume the l1 guest is not modifying it.

> 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.

hmm... I think, I need to move that part of common logic into SVM to reach
consensus... pity.

Christoph


-- 
---to satisfy European Law for business letters:
Advanced Micro Devices GmbH
Einsteinring 24, 85609 Dornach b. Muenchen
Geschaeftsfuehrer: Alberto Bozzo, Andrew Bowd
Sitz: Dornach, Gemeinde Aschheim, Landkreis Muenchen
Registergericht Muenchen, HRB Nr. 43632


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel