On 12/09/18 10:17, Jan Beulich wrote:
>>>> On 12.09.18 at 11:12, <andrew.coop...@citrix.com> wrote:
>> On 12/09/18 09:29, Sergey Dyasli wrote:
>>> On Tue, 2018-09-11 at 19:56 +0100, Andrew Cooper wrote:
>>>> @@ -822,13 +818,13 @@ int wrmsr_hypervisor_regs(uint32_t idx, uint64_t val)
>>>> if ( p2m_is_paging(t) )
>>>> {
>>>> p2m_mem_paging_populate(d, gmfn);
>>>> - return -ERESTART;
>>>> + return X86EMUL_RETRY;
>>> Previously -ERESTART would've been converted to X86EMUL_EXCEPTION. But
>>> with this patch, X86EMUL_RETRY will actually be returned. I don't think
>>> that callers can handle this situation.
>>>
>>> E.g. the code from vmx_vmexit_handler():
>>>
>>> case EXIT_REASON_MSR_WRITE:
>>> switch ( hvm_msr_write_intercept(regs->ecx, msr_fold(regs), 1) )
>>> {
>>> case X86EMUL_OKAY:
>>> update_guest_eip(); /* Safe: WRMSR */
>>> break;
>>>
>>> case X86EMUL_EXCEPTION:
>>> hvm_inject_hw_exception(TRAP_gp_fault, 0);
>>> break;
>>> }
>>> break;
>> Hmm lovely, so it was broken before, but should be correct now.
>>
>> RETRY has caused an entry to go onto the paging ring, which will pause
>> the vcpu until a reply occurs, after which we will re-enter the guest
>> without having moved RIP forwards, re-execute the wrmsr instruction, and
>> this time succeed because the frame has been paged in.
> But then perhaps split out the actual bugfix into a prereq patch,
> especially as that one may want backporting?
Sorry, but I'm not sure you can't have that. It will depend on the
internals of the hooks, but I suspect you'd need the entire rest of my
MSR cleanup work if you wanted to cleanly backport this bugfix.
~Andrew
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
