[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [PATCH] x86 / viridian: remove the viridian_vcpu msg_pending bit mask
On Thu, Aug 13, 2020 at 10:57:23AM +0100, Paul Durrant wrote: > From: Paul Durrant <pdurrant@xxxxxxxxxx> > > The mask does not actually serve a useful purpose as we only use the SynIC > for timer messages. Oh, I see. I assume it doesn't make sense because there can only be a single message pending (a timer one), and hence there isn't much value in doing this SynIC pending tracking? > Dropping the mask means that the EOM MSR handler > essentially becomes a no-op. This means we can avoid setting 'message_pending' > for timer messages and hence avoid a VMEXIT for the EOM. > > Signed-off-by: Paul Durrant <pdurrant@xxxxxxxxxx> Reviewed-by: Roger Pau Monné <roger.pau@xxxxxxxxxx> I've got some question below and one nit. > --- > Cc: Wei Liu <wl@xxxxxxx> > Cc: Jan Beulich <jbeulich@xxxxxxxx> > Cc: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> > Cc: "Roger Pau Monné" <roger.pau@xxxxxxxxxx> > > This should hopefully simplify Roger's "x86/vlapic: implement EOI callbacks" > series a little. > --- > xen/arch/x86/hvm/viridian/synic.c | 24 +----------------------- > xen/arch/x86/hvm/vlapic.c | 2 -- > xen/include/asm-x86/hvm/viridian.h | 2 -- > 3 files changed, 1 insertion(+), 27 deletions(-) > > diff --git a/xen/arch/x86/hvm/viridian/synic.c > b/xen/arch/x86/hvm/viridian/synic.c > index 94a2b88733..22e2df27e5 100644 > --- a/xen/arch/x86/hvm/viridian/synic.c > +++ b/xen/arch/x86/hvm/viridian/synic.c > @@ -137,7 +137,6 @@ int viridian_synic_wrmsr(struct vcpu *v, uint32_t idx, > uint64_t val) > if ( !(viridian_feature_mask(d) & HVMPV_synic) ) > return X86EMUL_EXCEPTION; > > - vv->msg_pending = 0; > break; > > case HV_X64_MSR_SINT0 ... HV_X64_MSR_SINT15: > @@ -168,9 +167,6 @@ int viridian_synic_wrmsr(struct vcpu *v, uint32_t idx, > uint64_t val) > printk(XENLOG_G_INFO "%pv: VIRIDIAN SINT%u: vector: %x\n", v, sintx, > vector); > > - if ( new.polling ) > - __clear_bit(sintx, &vv->msg_pending); > - > *vs = new; > break; > } > @@ -334,9 +330,6 @@ bool viridian_synic_deliver_timer_msg(struct vcpu *v, > unsigned int sintx, > .DeliveryTime = delivery, > }; > > - if ( test_bit(sintx, &vv->msg_pending) ) > - return false; > - > /* > * To avoid using an atomic test-and-set, and barrier before calling > * vlapic_set_irq(), this function must be called in context of the > @@ -346,12 +339,9 @@ bool viridian_synic_deliver_timer_msg(struct vcpu *v, > unsigned int sintx, > > msg += sintx; > > + /* There is no need to set message_pending as we do not require an EOM */ > if ( msg->header.message_type != HVMSG_NONE ) I think it's fine to use HVMSG_NONE ATM because Xen only knows about timer messages, but long term wouldn't it be better to use HVMSG_TIMER_EXPIRED? > - { > - msg->header.message_flags.msg_pending = 1; > - __set_bit(sintx, &vv->msg_pending); > return false; > - } > > msg->header.message_type = HVMSG_TIMER_EXPIRED; > msg->header.message_flags.msg_pending = 0; > @@ -380,18 +370,6 @@ bool viridian_synic_is_auto_eoi_sint(const struct vcpu > *v, > return vs->auto_eoi; > } > > -void viridian_synic_ack_sint(const struct vcpu *v, unsigned int vector) > -{ > - struct viridian_vcpu *vv = v->arch.hvm.viridian; > - unsigned int sintx = vv->vector_to_sintx[vector]; > - > - ASSERT(v == current); > - > - if ( sintx < ARRAY_SIZE(vv->sint) ) > - __clear_bit(array_index_nospec(sintx, ARRAY_SIZE(vv->sint)), > - &vv->msg_pending); > -} > - > void viridian_synic_save_vcpu_ctxt(const struct vcpu *v, > struct hvm_viridian_vcpu_context *ctxt) > { > diff --git a/xen/arch/x86/hvm/vlapic.c b/xen/arch/x86/hvm/vlapic.c > index 7b5c633033..1aff4cf989 100644 > --- a/xen/arch/x86/hvm/vlapic.c > +++ b/xen/arch/x86/hvm/vlapic.c > @@ -466,8 +466,6 @@ void vlapic_handle_EOI(struct vlapic *vlapic, u8 vector) > > if ( vlapic_test_vector(vector, &vlapic->regs->data[APIC_TMR]) ) > vioapic_update_EOI(d, vector); > - else if ( has_viridian_synic(d) ) > - viridian_synic_ack_sint(v, vector); Please also clean the comment above about SynIC SINTx being edge triggered. Thanks, Roger.
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |