Re: [Xen-devel] [PATCH v3 3/3] x86: Clean up the Xen MSR infrastructure

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 12.09.18 at 11:12, <andrew.cooper3@xxxxxxxxxx> 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?

Jan



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel