On 9 December 2020 13:26:55 GMT, Joao Martins <joao.m.martins@xxxxxxxxxx> wrote: >On 12/9/20 11:39 AM, David Woodhouse wrote: >> On Wed, 2020-12-09 at 10:51 +0000, Joao Martins wrote: >>> Isn't this what the first half of this patch was doing initially >(minus the >>> irq routing) ? Looks really similar: >>> >>> >https://lore.kernel.org/kvm/20190220201609.28290-11-joao.m.martins@xxxxxxxxxx/ >> >> Absolutely! This thread is in reply to your original posting of >> precisely that patch, and I've had your tree open in gitk to crib >from >> for most of the last week. >> >I forgot about this patch given all the discussion so far and I had to >re-look given that >it resembled me from your snippet. But I ended up being a little >pedantic -- sorry about that. Nah, pedantry is good :) >> At most, we just need to make sure that kvm_xen_has_interrupt() >returns >> false if the per-vCPU LAPIC vector is configured. But I didn't do >that >> because I checked Xen and it doesn't do it either. >> >Oh! I have this strange recollection that it was, when we were looking >at the Xen >implementation. Hm, maybe I missed it. Will stare at it harder, although looking at Xen code tends to make my brain hurt :) >> As far as I can tell, Xen's hvm_vcpu_has_pending_irq() will still >> return the domain-wide vector in preference to the one in the LAPIC, >if >> it actually gets invoked. > >Only if the callback installed is HVMIRQ_callback_vector IIUC. > >Otherwise the vector would be pending like any other LAPIC vector. Ah, right. For some reason I had it in my head that you could only set the per-vCPU lapic vector if the domain was set to HVMIRQ_callback_vector. If the domain is set to HVMIRQ_callback_none, that clearly makes more sense. Still, my patch should do the same as Xen does in the case where a guest does set both, I think. Faithful compatibility with odd Xen behaviour FTW :) -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
