All of lore.kernel.org
 help / color / mirror / Atom feed
From: zhu <vanbas.han@gmail.com>
To: "Robert S. Phillips" <rphillips@virtualiron.com>,
	Ben Thomas <bthomas@virtualiron.com>,
	sofsthun@virtualiron.com
Cc: Xen-devel@lists.xensource.com
Subject: Re: [PATCH - proposed] XI Shadow Page Table Mechanism]
Date: Sat, 01 Jul 2006 17:22:16 +0800	[thread overview]
Message-ID: <44A63EC8.3090708@gmail.com> (raw)
In-Reply-To: <44A52215.8050505@virtualiron.com>

Hi,
After taking some time to dig into your patch about XI Shadow page 
table, I have to say it's really a good design and implementation IMHO, 
especially the parts about the clear hierarchy for each smfn,decision 
table and how to support 32nopae in a rather elegant way. However, I 
have several questions to discuss with you.:-)
1) It seems XI shadow pgt reserve all of the possible resources at the 
early stage for HVM domain(the first time to create the asi). It could 
be quite proper to reserve the smfns and sptis. However, do we really 
need to reserve one snapshot page for each smfn at first and retain it 
until the HVM domain is destroyed? I guess a large number of gpts will 
not been modified frequently after them are totally set up. IMHO, it 
would be better to manage these snapshot pages dynamic. Of course, this 
will change the basic logistic of the code, e.g. you have to sync the 
shadow pgt when invoke spti_make_shadow instead of leaving it out of 
sync, you can't set up the total low level shadow pgt when invoke 
resync_spte  since it could cost a lot of time.
2) GP back link plays a very important role in XI shadow pgt. However, 
it will also cause high memory pressure for the domain(2 pages for each 
smfn). For these normal guest pages instead of GPT pages, I guess its 
usage is limited. Only when invoke xi_invld_mfn, divide_large_page or 
dirty logging, we will refer to the back link for these normal guest 
pages. Is it reasonable to implement the back link only for the GPT 
pages? Of course, this will increase the complexity of the code a little.
3) Can you show us the statistics between the current shadow pgt and XI 
pgt for some critical operations, such as shadow_resync_all, gva_to_gpa, 
shadow_fault and so on. I'm really curious about it.

I have to say I'm not very familiar with the current shadow pgt 
implementation so I could miss some important considerations when I post 
these questions. Please point it out.
Thanks for sharing your idea and code with us. :-)

_______________________________________________________
Best Regards,
hanzhu

      parent reply	other threads:[~2006-07-01  9:22 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <44A3CA74.4000206@virtualiron.com>
     [not found] ` <44A3D3CE.3040408@virtualiron.com>
     [not found]   ` <44A3E08B.9090103@gmail.com>
     [not found]     ` <44A3E98B.9040602@virtualiron.com>
     [not found]       ` <44A3F073.50305@virtualiron.com>
2006-06-30  2:37         ` [PATCH - proposed] XI Shadow Page Table Mechanism] zhu
2006-06-30 12:24           ` Robert Phillips
     [not found]             ` <44A51DE9.1020909@gmail.com>
2006-06-30 13:18               ` Robert Phillips
2006-06-30 13:33                 ` Steve Ofsthun
2006-06-30 13:47                 ` zhu
     [not found]               ` <44A52215.8050505@virtualiron.com>
2006-07-01  9:22                 ` zhu [this message]

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=44A63EC8.3090708@gmail.com \
    --to=vanbas.han@gmail.com \
    --cc=Xen-devel@lists.xensource.com \
    --cc=bthomas@virtualiron.com \
    --cc=rphillips@virtualiron.com \
    --cc=sofsthun@virtualiron.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.