[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 & 
>          /* 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.


Xen-devel mailing list



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