On 01/12/16 13:00, Jan Beulich wrote:
>>>> On 30.11.16 at 14:50, <andrew.coop...@citrix.com> wrote:
>> --- a/xen/arch/x86/mm/shadow/multi.c
>> +++ b/xen/arch/x86/mm/shadow/multi.c
>> @@ -3373,18 +3373,35 @@ static int sh_page_fault(struct vcpu *v,
>>
>> r = x86_emulate(&emul_ctxt.ctxt, emul_ops);
>>
>> - /*
>> - * The previous lack of inject_{sw,hw}*() hooks caused exceptions raised
>> - * by the emulator itself to become X86EMUL_UNHANDLEABLE. Such
>> exceptions
>> - * now set event_pending instead. Exceptions raised behind the back of
>> - * the emulator don't yet set event_pending.
>> - *
>> - * For now, cause such cases to return to the X86EMUL_UNHANDLEABLE path,
>> - * for no functional change from before. Future patches will fix this
>> - * properly.
>> - */
>> if ( r == X86EMUL_EXCEPTION && emul_ctxt.ctxt.event_pending )
>> - r = X86EMUL_UNHANDLEABLE;
>> + {
>> + /*
>> + * This emulation covers writes to shadow pagetables. We tolerate
>> #PF
>> + * (from hitting adjacent pages) and #GP/#SS (from segmentation
>> + * errors). Anything else is an emulation bug, or a guest playing
>> + * with the instruction stream under Xen's feet.
>> + */
> Same comment here regarding "adjacent".
In this case, the answer is different. A misaligned write across the
end of a shadow pagetable may legitimately trigger a #PF.
>
>> + if ( emul_ctxt.ctxt.event.type == X86_EVENTTYPE_HW_EXCEPTION &&
>> + (emul_ctxt.ctxt.event.vector < 32) &&
>> + ((1u << emul_ctxt.ctxt.event.vector) &
>> + ((1u << TRAP_stack_error) | (1u << TRAP_gp_fault) |
>> + (1u << TRAP_page_fault))) )
> May I suggest to also demand an error code of zero for #GP/#SS?
Ok.
>
>> + {
>> + if ( is_hvm_vcpu(v) )
> has_hvm_container_domain()?
Very good point. Will fix.
~Andrew
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
