[MODERATED] Re: [RFC PATCH 4/6] kvm: handle host mode irqs 4

[Nicolai Stange <nstange@suse.de>]

speck for Paolo Bonzini  <speck@linutronix.de> writes:

> On 27/07/2018 11:17, speck for Nicolai Stange wrote:
>> speck for Peter Zijlstra  <speck@linutronix.de> writes:
>> 
>>> On Wed, Jul 25, 2018 at 01:45:32PM +0200, speck for Nicolai Stange wrote:
>>>> So if nobody objects, I'll go with what Paolo proposed at [1]: replace
>>>> the 'kernel_mode_irq_gen' counter with a latch flag and set that for any
>>>> irq (but NMIs for a start).
>>>
>>> Well, the reason I suggested the other counters, is to avoid adding yet
>>> another dirty cacheline to IRQs. Since we're already touching those
>>> fields for most interrupts anyway.. might as well extend them to cover
>>> what we need instead of adding more dirty lines.
>>>
>> 
>> Ah I see, that makes sense of course.
>> 
>> I think there are two possible ways forward:
>> 
>> 1.) Squeeze that new "kvm_cpu_l1tf_flush_l1d" latch flag into
>>     irq_cpustat_t. irq_cpustat_t is arch-specific and there
>>     is some room in its first cacheline, for example inserting
>>     up to four bytes right after ->irq_tlb_count wouldn't move
>>     anything critical out.
>> 
>> 2.) Make the non-do_IRQ() irqs, i.e. smp_apic_timer_interrupt() & Co,
>>     call kstat_incr_irqs_this_cpu() and adapt arch_irq_stat_cpu()
>>     accordingly. Let vmx use struct kernel_stat ->irqs_sum as a
>>     irq generation counter as before.
>> 
>> Pros 1.)
>> - Easy to implement.
>> - Doesn't rely on irq_domain drivers.
>> 
>> Cons 1.)
>> - Extra store from do_IRQ() irqs in comparison to 2.)
>> - That "kvm_cpu_l1tf_flush_l1d" flag doesn't really qualify
>>   as an "IRQ stat" and it might be surprising to have it there.
>
> There's precedent for this, for example __softirq_pending.  In fact you
> could reduce __softirq_pending to an u16 and not increase the size of
> irq_cpustat_t, since there are <16 softirqs.

Perfect, thanks!

Nicolai