On Fri, Jun 22, 2012 at 3:28 AM, 陳韋任 (Wei-Ren Chen)
wrote:
> 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 availab
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 operati
Hi Xin Tong,
On Fri, Jan 20, 2012 at 08:54:12AM -0500, Xin Tong wrote:
> On Fri, Jan 20, 2012 at 3:23 AM, 陳韋任 wrote:
> >> 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
On Fri, Jan 20, 2012 at 08:54:12AM -0500, Xin Tong wrote:
> On Fri, Jan 20, 2012 at 3:23 AM, 陳韋任 wrote:
> >> 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
> 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.
Why the control of gCR3 needs kernel access? Isn't gCR3 just a field of the
CPUX86State? QEMU
On Fri, Jan 20, 2012 at 3:23 AM, 陳韋任 wrote:
>> 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.
>
> Why the control of gCR3 needs kernel access
