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 <gr...@kaod.org>
>> ---
>> 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;
>> + }
>> }
>>
>> /*
>>
>
