[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH v9 11/20] x86/VPMU: Interface for setting PMU mode and flags
>>> On 12.08.14 at 18:25, <boris.ostrovsky@xxxxxxxxxx> wrote: > On 08/12/2014 11:35 AM, Jan Beulich wrote: >>>>> On 12.08.14 at 17:12, <boris.ostrovsky@xxxxxxxxxx> wrote: >>> How about an inline function? >> Yeah, that would perhaps do too. Albeit I'd still prefer all vPMU >> logic to be handle in the called vPMU functions. > > I was thinking about an inline in vpmu.h. Something like > > inline void vpmu_next(struct vcpu *prev, struct vcpu *next) > { > if ( is_hvm_vcpu(next) && (prev != next) && (vpmu_mode & > XENPMU_MODE_SELF) ) > /* Must be done with interrupts enabled */ > vpmu_load(next); > } > > (and similar for vpmu_save()) That doesn't change my opinion: Perhaps acceptable, but doing isolation in the Linux like way rather than true separation. >>> I think that's OK: one of these two competing requests will timeout in >>> the while loop of vpmu_force_context_switch(). It will, in fact, likely >>> be the first caller because the second one will get right into the while >>> loop, without setting up the waiting data. This is a little >>> counter-intuitive but trying to set mode simultaneously from two >>> different places is asking for trouble anyway. >> Sure it is, but we nevertheless want the hypervisor to be safe. So I >> consider what you currently have acceptable only if you can prove >> that nothing bad can happen no matter in what order multiple >> requests get issued - from looking over your code I wasn't able to >> convince myself of this. > > > Would a comment with what I said above (possibly a bit massaged) be > sufficient? Perhaps, as long as that comment supplies the requested proof. Jan _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |