[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [RFC v2 13/15] Update Posted-Interrupts Descriptor during vCPU scheduling
>>> On 17.06.15 at 08:54, <feng.wu@xxxxxxxxx> wrote: >> From: Jan Beulich [mailto:JBeulich@xxxxxxxx] >> Sent: Wednesday, June 10, 2015 2:44 PM >> >>> On 08.05.15 at 11:07, <feng.wu@xxxxxxxxx> wrote: >> > + switch ( v->runstate.state ) >> > + { >> > + case RUNSTATE_runnable: >> > + case RUNSTATE_offline: >> > + /* >> > + * We don't need to send notification event to a non-running >> > + * vcpu, the interrupt information will be delivered to it before >> > + * VM-ENTRY when the vcpu is scheduled to run next time. >> > + */ >> > + pi_desc->sn = 1; >> > + >> > + /* >> > + * If the state is transferred from RUNSTATE_blocked, >> > + * we should set 'NV' feild back to posted_intr_vector, >> > + * so the Posted-Interrupts can be delivered to the vCPU >> > + * by VT-d HW after it is scheduled to run. >> > + */ >> > + if ( old_state == RUNSTATE_blocked ) >> > + { >> > + do >> > + { >> > + old.control = new.control = pi_desc->control; >> > + new.nv = posted_intr_vector; >> > + } >> > + while ( cmpxchg(&pi_desc->control, old.control, new.control) >> > + != old.control ); >> >> So why is it okay to do the SN update non-atomically when the >> vector update is done atomically? >> >> Also the curly braces do _not_ go on separate lines for do/while >> constructs. >> >> And then do you really need to atomically update the whole 64 bits >> here, rather than just the nv field? By not making it a bit field >> you could perhaps just write_atomic() it? >> > > Thinking more about this, maybe write_atomic() is not good for this, we need > use > the LOCK prefix when updating the posted-interrupt descriptor. The LOCK prefix can't be applied to simple loads and stores; they're implicitly atomic. Also - please remember to trim your replies. Jan _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |