Re: [Qemu-devel] nested page table translation for non-x86 operating system

[Wei-Ren Chen]

Hi Xin Tong,

  O.K., after studying KVM a little bit, I just give you my 2 cents. :)

On Fri, Jan 20, 2012 at 12:12:00AM -0500, Xin Tong wrote:
> I am wondering the possibilities of using the nested page table
> mechanism available on the x86 processors to do page translation for
> non-x86 operating system emulation.

  Orit mentioned there was a project called QuickTransit which runs
Solaris/SPARC on Linux/x86, it seems to use shadow page table rather
than NPT/EPT to help the guest memory translation [1]. Maybe you have
targets in mind which might have similar page table structures to x86
, so that NPT/EPT can be used?

> So, when nested page is enabled, you can control the gCR3 and hCR3.
> The gCR3 can be used to point to the page table of the running process
> in the guest operating system and the hCR3 can be used to point to the
> page table of the QEMU process. Assuming the page table layouts of
> both operating systems are exactly the same.  I think this can be
> done. However there are a few problems I see here. I would like to
> hear some suggestions or corrections.
> 
> 1.  The control of gCR3 and hCR3 needs kernel access. While they can
> be set with a device module as what is done in kvm. Trapping into the
> kernel every time gCR3 is reseted might be too expensive.

  How can you set gCR3/hCR3 through the device module (sorry, I am not
a KVM expert)? Do you think making QEMU into kernel mode can mitigate
the overhead?
 
> 2. After setting the gCR3 and hCR3. whatever memory references fall
> within the guest memory will be done correctly. However, memory
> references done by the host will be broken. Therefore, when we load
> the from the CPUstates, call to helpers for exits from the code cache,
> we need to change the paging mechanism back to non-nested. can this be
> done ? how expensive will this be ?

  What in my mind is, maybe we can lauch a KVM_RUN in the TCG prologue,
that way we can run the translated host binary with two level memory
translation. If we run into helper function, we do VMExit, fall back to
the original (one level) memory translation. Is that what you mean?

  How about make the address mapping of helper functions be identical,
i.e., make the spte actually do nothing?
 
> 3. Lastly and most importantly,  the code cache is based on a host
> address, what about fetching instructions from the code cache, this
> has to happen in non-nested mode ?

  When guest VM (with KVM enabled) fetch instructions from its memory,
does it also have the same issue?

Regards,
chenwj

[1] http://www.mail-archive.com/address@hidden/msg117254.html

-- 
Wei-Ren Chen (陳韋任)
Computer Systems Lab, Institute of Information Science,
Academia Sinica, Taiwan (R.O.C.)
Tel:886-2-2788-3799 #1667
Homepage: http://people.cs.nctu.edu.tw/~chenwj