[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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |