All of lore.kernel.org
 help / color / mirror / Atom feed
From: Igor Mammedov <imammedo@redhat.com>
To: Peter Xu <peterx@redhat.com>
Cc: qemu-devel@nongnu.org, Jason Wang <jasowang@redhat.com>,
	"Michael S . Tsirkin" <mst@redhat.com>,
	Paolo Bonzini <pbonzini@redhat.com>,
	David Woodhouse <dwmw2@infradead.org>,
	Claudio Fontana <cfontana@suse.de>
Subject: Re: [PATCH] Revert "intel_iommu: Fix irqchip / X2APIC configuration checks"
Date: Thu, 22 Sep 2022 15:46:17 +0200	[thread overview]
Message-ID: <20220922154617.57d1a1fb@redhat.com> (raw)
In-Reply-To: <20220921161227.57259-1-peterx@redhat.com>

On Wed, 21 Sep 2022 12:12:27 -0400
Peter Xu <peterx@redhat.com> wrote:

> It's true that when vcpus<=255 we don't require the length of 32bit APIC
> IDs.  However here since we already have EIM=ON it means the hypervisor
> will declare the VM as x2apic supported (e.g. VT-d ECAP register will have
> EIM bit 4 set), so the guest should assume the APIC IDs are 32bits width
> even if vcpus<=255.  In short, commit 77250171bdc breaks any simple cmdline
> that wants to boot a VM with >=9 but <=255 vcpus with:
> 
>   -device intel-iommu,intremap=on
> 
> For anyone who does not want to enable x2apic, we can use eim=off in the
> intel-iommu parameters to skip enabling KVM x2apic.
> 
> This partly reverts commit 77250171bdc02aee106083fd2a068147befa1a38, while
> keeping the valid bit on checking split irqchip, but revert the other change.
> 
> Cc: David Woodhouse <dwmw2@infradead.org>
> Cc: Claudio Fontana <cfontana@suse.de>
> Cc: Igor Mammedov <imammedo@redhat.com>
> Signed-off-by: Peter Xu <peterx@redhat.com>
> ---
>  hw/i386/intel_iommu.c | 5 +++++
>  1 file changed, 5 insertions(+)
> 
> diff --git a/hw/i386/intel_iommu.c b/hw/i386/intel_iommu.c
> index 05d53a1aa9..6524c2ee32 100644
> --- a/hw/i386/intel_iommu.c
> +++ b/hw/i386/intel_iommu.c
> @@ -3818,6 +3818,11 @@ static bool vtd_decide_config(IntelIOMMUState *s, Error **errp)
>              error_setg(errp, "eim=on requires accel=kvm,kernel-irqchip=split");
>              return false;
>          }
> +        if (!kvm_enable_x2apic()) {

above 'check' has side-effects
if it's supposed to be a check it would be better to use kvm_has_x2apic_api()
instead.

Also 77250171bdc says:
"
    The check on kvm_enable_x2apic() needs to happen *anyway* in order to
    allow CPUs above 254 even without an IOMMU, so allow that to happen
    elsewhere.
"

Looking for that elsewhere, it looks like commit dc89f32d92b was supposed
to take care of removed chunk, but that is not reachable because of > 255 vCPUs"

Likely 77250171bdc just exposed a bug in dc89f32d92b, where
the later removed kvm_enable_x2apic() always called (with split irqchip)
and made it called only when > 255 vCPUs.

So migration wise it looks like all version with it and less than 255 cpus
are broken.

Wait earlier c1bb5418e3, introduced that
   kvm_irqchip_is_split() && kvm_enable_x2apic()
'condition', also without any compat machinery to keep old behavior.

And before that kvm_enable_x2apic() was affecting only configuration
with intel_iommu (fb506e701e9b).

I'm not sure if anything could be salvaged here migration wise

PS:
I'd keep kvm_enable_x2apic() only in corrected x86_cpus_init()
and use kvm_has_x2apic_api() elsewhere for checks and bailing out.


> +            error_setg(errp, "eim=on requires support on the KVM side"
> +                             "(X2APIC_API, first shipped in v4.7)");
> +            return false;
> +        }



>      }
>  
>      /* Currently only address widths supported are 39 and 48 bits */



  parent reply	other threads:[~2022-09-22 14:29 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-09-21 16:12 [PATCH] Revert "intel_iommu: Fix irqchip / X2APIC configuration checks" Peter Xu
2022-09-22  1:32 ` Jason Wang
2022-09-22 16:49   ` Peter Xu
2022-09-22 13:46 ` Igor Mammedov [this message]
2022-09-22 16:40   ` Peter Xu
2022-09-23  8:20     ` Igor Mammedov
2022-09-23  8:41       ` Igor Mammedov
2022-09-23 22:03         ` Peter Xu
2022-09-24  1:27           ` Peter Xu
2022-09-26  9:33             ` Igor Mammedov
2022-09-26 15:17               ` Peter Xu

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20220922154617.57d1a1fb@redhat.com \
    --to=imammedo@redhat.com \
    --cc=cfontana@suse.de \
    --cc=dwmw2@infradead.org \
    --cc=jasowang@redhat.com \
    --cc=mst@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=peterx@redhat.com \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.