Avi Kivity wrote:
> Laurent Vivier wrote:
>> Avi Kivity wrote:
>>  
>>> Laurent Vivier (Bull) wrote:
>>>    
>>>>> Not being able to emulate is sometimes legitimate.  In the case of
>>>>> writing to a write-protected guest page table, we simply
>>>>> un-write-protect it and go back to the guest (which should now execute
>>>>> the instruction natively).
>>>>>
>>>>> Perhaps the logic that deals with this (the call to
>>>>> kvm_mmu_unprotect_page_virt() in emulate_instruction()) was broken by
>>>>> your changes.
>>>>>
>>>>>         
>>>> In fact this case is managed in the error cases of
>>>> emulate_instruction(). My first patch removes this management for
>>>> instruction decoding because I supposed it cannot generate such errors.
>>>> So what I proposed in my last email seems to be the good solution :
>>>>
>>>> emulate_instruction()
>>>> ...
>>>>         r = x86_decode_insn(&vcpu->emulate_ctxt, &emulate_ops);
>>>>         if (r == 0)
>>>>                 r = x86_emulate_insn(&vcpu->emulate_ctxt,
>>>> &emulate_ops);
>>>> ...
>>>>         if (r) {
>>>>                 if (kvm_mmu_unprotect_page_virt(vcpu, cr2))
>>>>                         return EMULATE_DONE;
>>>>                 if (!vcpu->mmio_needed) {
>>>>                         kvm_report_emulation_failure(vcpu, "mmio");
>>>>                         return EMULATE_FAIL;
>>>>                 }
>>>>                 return EMULATE_DO_MMIO;
>>>>         }
>>>> ...
>>>>
>>>>       
>>> Yes.  But pushing the kvm_mmu_unprotect_page() to immediately after
>>> the decode stage may be better.
>>>
>>>     
>>
>> OK, but is this the only error case we can have in the decode stage ?
>>   
> 
> Decode can actually have fetch faults in smp (due to the instruction
> lengthening during decode, or due to the page tables changing with
> npt/ept).
> 
> I think these are the only two errors possible for decode: can't decode
> and can't fetch.
> 
>> Should we remove it from after the emulate stage ?
>>
>>   
> 
> Instruction execution shouldn't cause decode failures, so yes, that
> error shouldn't be emitted there.
> 
> But we can defer these fine tunings until later. Let's merge something
> that works first.

Agree, I think it is better to merge something close to the original behavior
before improving it.

I try to post patches today.

Laurent
-- 
------------- [EMAIL PROTECTED]  --------------
          "Software is hard" - Donald Knuth

Attachment: signature.asc
Description: OpenPGP digital signature

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel

Reply via email to