[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH v2 1/4] x86/EPT: force re-evaluation of memory type as necessary
>>> On 03.04.14 at 12:18, <tim@xxxxxxx> wrote: > Hi, > > This version looks correct to me, but this tristate: > > At 13:17 +0000 on 28 Mar (1396009028), Jan Beulich wrote: >> + p2m_lock(p2m); >> + >> + okay = -curr->arch.hvm_vmx.ept_spurious_misconfig; > > [...] > >> + if ( okay > 0 ) >> + { >> + struct vcpu *v; >> + >> + for_each_vcpu ( curr->domain, v ) >> + v->arch.hvm_vmx.ept_spurious_misconfig = 1; >> + } >> + curr->arch.hvm_vmx.ept_spurious_misconfig = 0; >> + ept_sync_domain(p2m); >> + p2m_unlock(p2m); >> + >> + return !!okay; > > seems a bit baroque. Can we go for 'bool_t okay = 0' at the top and then > > if ( okay ) > { > struct vcpu *v; > > for_each_vcpu ( curr->domain, v ) > v->arch.hvm_vmx.ept_spurious_misconfig = 1; > } > else > okay = curr->arch.hvm_vmx.ept_spurious_misconfig; > curr->arch.hvm_vmx.ept_spurious_misconfig = 0; > ept_sync_domain(p2m); > p2m_unlock(p2m); > > return okay; > > instead? With that change, > > Reviewed-by: Tim Deegan <tim@xxxxxxx> Will do, even though another patch (not posted yet, removing the recursion in ept_change_entry_type_global()) converts this to a more conventional "rc" anyway, as I'm re-using the bulk of this function then to flush out pending changes first thing in ept_set_entry(). Jan _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |