[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



>>> On 12.09.18 at 11:24, <andrew.cooper3@xxxxxxxxxx> wrote:
> On 12/09/18 10:17, Jan Beulich wrote:
>>>>> 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?
> 
> 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.

Ouch, well - then: No.

Jan



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

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.