[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH 2/3] x86/nvmx: clarify and fix usage of nvmx_update_apicv



On Tue, Mar 24, 2020 at 11:33:00AM +0000, Tian, Kevin wrote:
> > From: Roger Pau Monné <roger.pau@xxxxxxxxxx>
> > Sent: Tuesday, March 24, 2020 7:23 PM
> > 
> > On Tue, Mar 24, 2020 at 10:11:15AM +0000, Tian, Kevin wrote:
> > > > From: Roger Pau Monné <roger.pau@xxxxxxxxxx>
> > > > Sent: Tuesday, March 24, 2020 5:51 PM
> > > >
> > > > On Tue, Mar 24, 2020 at 06:03:28AM +0000, Tian, Kevin wrote:
> > > > > > From: Roger Pau Monne <roger.pau@xxxxxxxxxx>
> > > > > > Sent: Saturday, March 21, 2020 3:08 AM
> > > > > >
> > > > > > The current usage of nvmx_update_apicv is not clear: it is deeply
> > > > > > intertwined with the Ack interrupt on exit VMEXIT control.
> > > > > >
> > > > > > The code in nvmx_update_apicv should update the SVI (in service
> > > > interrupt)
> > > > > > field of the guest interrupt status only when the Ack interrupt on
> > > > > > exit is set, as it is used to record that the interrupt being
> > > > > > serviced is signaled in a vmcs field, and hence hasn't been injected
> > > > > > as on native. It's important to record the current in service
> > > > > > interrupt on the guest interrupt status field, or else further
> > > > > > interrupts won't respect the priority of the in service one.
> > > > > >
> > > > > > While clarifying the usage make sure that the SVI is only updated
> > when
> > > > > > Ack on exit is set and the nested vmcs interrupt info field is 
> > > > > > valid. Or
> > > > > > else a guest not using the Ack on exit feature would loose 
> > > > > > interrupts
> > as
> > > > > > they would be signaled as being in service on the guest interrupt
> > > > > > status field but won't actually be recorded on the interrupt info 
> > > > > > vmcs
> > > > > > field, neither injected in any other way.
> > > > >
> > > > > It is insufficient. You also need to update RVI to enable virtual 
> > > > > injection
> > > > > when Ack on exit is cleared.
> > > >
> > > > But RVI should be updated in vmx_intr_assist in that case, since
> > > > nvmx_intr_intercept shouldn't intercept the interrupt, as it should be
> > > > handled normally.
> > >
> > > As we discussed before, vmx_intr_assist is invoked before
> > nvmx_switch_guest.
> > >
> > > It is incorrectly to update RVI at that time since it might be still 
> > > vmcs02
> > being
> > > active (if no pending softirq to make it invoked again).
> > >
> > > Also nvmx_intr_intercept does intercept Ack-on-exit=0 case:
> > >
> > >         if ( intack.source == hvm_intsrc_pic ||
> > >                  intack.source == hvm_intsrc_lapic )

I've realized that nvmx_intr_intercept will return 1 for interrupts
originating from the lapic or the pic, while nvmx_update_apicv will
only update GUEST_INTR_STATUS for interrupts originating from the
lapic. Is this correct?

Shouldn't both be in sync and handle the same interrupt sources?

Thanks, Roger.



 


Rackspace

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