Re: [Qemu-ppc] [PATCH] spapr: Don't use the "dual" interrupt controller mode with an old hypervisor

[Cédric Le Goater]

On 07/06/2019 02:19, David Gibson wrote:
> On Thu, Jun 06, 2019 at 07:08:59PM +0200, Greg Kurz wrote:
>> If KVM is too old to support XIVE native exploitation mode, we might end
>> up using the emulated XIVE after CAS. This is sub-optimal if KVM in-kernel
>> XICS is available, which is the case most of the time.
> 
> This is intentional.  A predictable guest environment trumps performance.

I don't agree. 

If the user does not specify any specific interrupt mode, we should favor 
the faster one. 

Here is the current matrix (with this patch) for guests running on an 
old KVM, that is without KVM XIVE support. Let's discuss on what we
want. 

                        kernel_irqchip

           (default) 
ic-mode     allowed           off            on 

dual        XICS KVM       XICS emul.(3)   XICS KVM         (default mode)
xics        XICS KVM       XICS emul.      XICS KVM    
xive        XIVE emul.(1)  XIVE emul.     QEMU failure (2)


(1) QEMU warns with "warning: kernel_irqchip requested but unavailable: 
    IRQ_XIVE capability must be present for KVM" 
(2) QEMU fails with "kernel_irqchip requested but unavailable: 
    IRQ_XIVE capability must be present for KVM" 
(3) That is wrong I think, we should get XIVE emulated.


what you would want is XIVE emulation when ic-mode=dual and 
kernel_irqchip=allowed, which is the behavior with this patch (but there
are reboot bugs)

 
>> Also, an old KVM may not allow to destroy and re-create the KVM XICS, which
>> is precisely what "dual" does during machine reset. This causes QEMU to try
>> to switch to emulated XICS and to crash because RTAS call de-registration
>> isn't handled correctly. We could possibly fix that, but again we would
>> still end up with an emulated XICS or XIVE.
> 
> Ugh, that's a problem.

Yes. It's another problem around the way we cleanup the allocated resources.
It should be another patch.

> 
>> "dual" is definitely not a good choice with older KVMs. Internally force
>> XICS when we detect this.
> 
> But this is not an acceptable solution.  Silently changing the guest
> visible environment based on host capabilities is never ok. 

If the host (KVM) doesn't have a capability, what is the point of trying 
to use it if we can do better. I know you are considering KVM/QEMU as a
whole but who would run with kernel_irqchip=off ?

> We must
> either give the guest environment that the user has requested, or fail
> outright.

'dual' mode means both and the user is not requesting XIVE. We are changing 
the priority of choices from :

 1. KVM XIVE
 2. QEMU XIVE
 3. KVM XICS
 4. QEMU XICS

to:

 1. KVM XIVE
 2. KVM XICS
 3. QEMU XIVE
 4. QEMU XICS

which is better I think.

C.


> 
>>
>> Signed-off-by: Greg Kurz <address@hidden>
>> ---
>>  hw/ppc/spapr_irq.c |   10 ++++++++++
>>  1 file changed, 10 insertions(+)
>>
>> diff --git a/hw/ppc/spapr_irq.c b/hw/ppc/spapr_irq.c
>> index 3156daf09381..d788bd662a7a 100644
>> --- a/hw/ppc/spapr_irq.c
>> +++ b/hw/ppc/spapr_irq.c
>> @@ -18,6 +18,7 @@
>>  #include "hw/ppc/xics_spapr.h"
>>  #include "cpu-models.h"
>>  #include "sysemu/kvm.h"
>> +#include "kvm_ppc.h"
>>  
>>  #include "trace.h"
>>  
>> @@ -668,6 +669,15 @@ static void spapr_irq_check(SpaprMachineState *spapr, 
>> Error **errp)
>>              return;
>>          }
>>      }
>> +
>> +    /*
>> +     * KVM may be too old to support XIVE, in which case we'd rather try
>> +     * to use the in-kernel XICS instead of the emulated XIVE.
>> +     */
>> +    if (kvm_enabled() && !kvmppc_has_cap_xive() &&
>> +        spapr->irq == &spapr_irq_dual) {
>> +        spapr->irq = &spapr_irq_xics;
>> +    }
>>  }
>>  
>>  /*
>>
>