All of lore.kernel.org
 help / color / mirror / Atom feed
From: Christoph Egger <Christoph.Egger@amd.com>
To: "Dong, Eddie" <eddie.dong@intel.com>
Cc: Tim,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Deegan <Tim.Deegan@citrix.com>
Subject: Re: [PATCH 04/12] Nested Virtualization: core
Date: Fri, 7 Jan 2011 17:31:03 +0100	[thread overview]
Message-ID: <201101071731.05094.Christoph.Egger@amd.com> (raw)
In-Reply-To: <1A42CE6F5F474C41B63392A5F80372B231D84EA2@shsmsx501.ccr.corp.intel.com>

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

I think, I need to excuse. Now that I did the change in my local tree
I have to mention that did not realize that I can remove the put function
completely. This in fact is a simplification.

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

  parent reply	other threads:[~2011-01-07 16:31 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-12-20 16:05 [PATCH 04/12] Nested Virtualization: core Christoph Egger
2010-12-27  7:54 ` Dong, Eddie
2011-01-03 15:58   ` Christoph Egger
2011-01-06 17:33     ` Dong, Eddie
2011-01-07 10:24       ` Christoph Egger
2011-01-07 20:39         ` Dong, Eddie
2011-01-07 16:31       ` Christoph Egger [this message]
2011-01-07 14:12     ` Tim Deegan
2011-01-07 15:56       ` Christoph Egger
  -- strict thread matches above, loose matches on Subject: below --
2011-03-09 14:23 Christoph Egger
2011-03-29  6:44 ` Dong, Eddie

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=201101071731.05094.Christoph.Egger@amd.com \
    --to=christoph.egger@amd.com \
    --cc=Tim.Deegan@citrix.com \
    --cc=eddie.dong@intel.com \
    --cc=xen-devel@lists.xensource.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.