On 9 December 2020 13:26:55 GMT, Joao Martins <joao.m.mart...@oracle.com> 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.mart...@oracle.com/
>>
>> 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.
