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

Re: [Xen-devel] [PATCH v3 25/25] x86/shadow: fold sh_x86_emulate_{write, cmpxchg}() into their only callers



>>> On 02.02.18 at 17:52, <andrew.cooper3@xxxxxxxxxx> wrote:
> On 07/12/17 14:19, Jan Beulich wrote:
>> @@ -298,14 +332,43 @@ hvm_emulate_cmpxchg(enum x86_segment seg
>>      if ( rc )
>>          return rc;
>>  
>> +    /* Unaligned writes are only acceptable on HVM */
>> +    if ( (addr & (bytes - 1)) && !is_hvm_vcpu(v)  )
>> +        return X86EMUL_UNHANDLEABLE;
>> +
>> +    ptr = sh_emulate_map_dest(v, addr, bytes, sh_ctxt);
>> +    if ( IS_ERR(ptr) )
>> +        return ~PTR_ERR(ptr);
>> +
>>      old = new = 0;
>>      memcpy(&old, p_old, bytes);
>>      memcpy(&new, p_new, bytes);
>>  
>> -    rc = v->arch.paging.mode->shadow.x86_emulate_cmpxchg(
>> -             v, addr, &old, new, bytes, sh_ctxt);
>> +    paging_lock(v->domain);
>> +    switch ( bytes )
>> +    {
>> +    case 1: prev = cmpxchg((uint8_t  *)ptr, old, new); break;
>> +    case 2: prev = cmpxchg((uint16_t *)ptr, old, new); break;
>> +    case 4: prev = cmpxchg((uint32_t *)ptr, old, new); break;
>> +    case 8: prev = cmpxchg((uint64_t *)ptr, old, new); break;
>> +    default:
>> +        SHADOW_PRINTK("cmpxchg size %u is not supported\n", bytes);
> 
> Given the earlier patches in the series, is it worth introducing case 16
> here?

In a follow-up patch this could be an option (unless Tim knows a
reason why this might be a bad idea), but I certainly wouldn't want
to do so here.

> Irrespective, this doesn't interfere with the purpose of the patch, so
> Reviewed-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>

Thanks, 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®.