[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4E3913CC.7010907@cn.fujitsu.com>
Date: Wed, 03 Aug 2011 17:24:28 +0800
From: Xiao Guangrong <xiaoguangrong@...fujitsu.com>
To: Avi Kivity <avi@...hat.com>
CC: Marcelo Tosatti <mtosatti@...hat.com>,
LKML <linux-kernel@...r.kernel.org>, KVM <kvm@...r.kernel.org>
Subject: Re: [PATCH v2 02/12] KVM: x86: tag the instructions which are used
to write page table
Hi Avi,
On 08/03/2011 04:09 PM, Avi Kivity wrote:
> On 08/03/2011 09:02 AM, Xiao Guangrong wrote:
>> > Note we don't need to actually emulate, just decode, since page_fault can tell us whether a write failed due to page tables or mmio.
>> >
>>
>> This is a interesting feature. If it happens, i will just drop the shadow pages
>> and retry these instructions directly.
>
> Note it's a little dangerous. If the guest uses a non-page-table modifying instruction on the PDE that points to the instruction, then we will unmap the instruction and go to an infinite loop.
>
Yes, it is.
> Maybe it's better to emulate if we can't find a fix for that.
>
> One way would be to emulate every 20 instructions; this breaks us out of the loop but reduces costly emulations to 5%.
>
After much thought about this, may be this optimization is not good since:
- it is little complex
- this optimization is only applied to the instruction emulation caused by #PF
- it does not improve too much:
if we emulate the instruction, we need to do:
- decode instruction
- emulate it
- zap shadow pages
And do this, it can return to the guest, the guest can run the next instruction
if we retry the instruction, we need to do:
- decode instruction
- zap shadow pages
then return to the guest and retry the instruction, however, we will get page fault
again(since the mapping is still read-only), so we will get another VM-exit and need
to do:
# trigger page fault
- handle the page fault and change the mapping to writable
- retry the instruction
until now, the guest can run the next instruction
So, i do not think the new way is better, your opinion?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists