All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Huang, Kai" <kai.huang@intel.com>
To: "seanjc@google.com" <seanjc@google.com>
Cc: "pbonzini@redhat.com" <pbonzini@redhat.com>,
	"Wang, Zhong" <wangzhong.c0ss4ck@bytedance.com>,
	"zhanghy@sangfor.com" <zhanghy@sangfor.com>,
	"shixuanqing.11@bytedance.com" <shixuanqing.11@bytedance.com>,
	"bestswngs@gmail.com" <bestswngs@gmail.com>,
	"kvm@vger.kernel.org" <kvm@vger.kernel.org>,
	"stable@vger.kernel.org" <stable@vger.kernel.org>,
	"jasowang@redhat.com" <jasowang@redhat.com>
Subject: Re: [PATCH v2] KVM: x86: Destroy the PIC and IOAPIC before destroying vCPUs
Date: Mon, 6 Jul 2026 22:33:06 +0000	[thread overview]
Message-ID: <82a5be971c5fbc90133f394fba9c7dd5c19fed91.camel@intel.com> (raw)
In-Reply-To: <akwnx1ovr-Rkl6q7@google.com>

On Mon, 2026-07-06 at 15:10 -0700, Sean Christopherson wrote:
> On Mon, Jul 06, 2026, Kai Huang wrote:
> > 
> > >     Alternatively, KVM could simply destroy the I/O APIC during the "pre" phase
> > >     of VM destruction, but that gets more than a bit sketchy as KVM expects the
> > >     I/O APIC to exist if ioapic_in_kernel() is true, and nested virtualization
> > >     in particular has a bad habit of touching VM-scope state during vCPU
> > >     destruction.  E.g. attempting to free the PIC during the pre phase would
> > >     lead to a NULL pointer dereference in kvm_cpu_has_extint(), and it's not
> > >     hard to imagine the I/O APIC having a similar flaw.
> > 
> > Hmm seems vmx_vcpu_free() can eventually call into kvm_cpu_has_extint() via
> > nested_vmx_vmexit().  Thanks for pointing out.
> 
> Yeah, I found out the hard way :-)

:-)

Btw, I don't think the order of kvm_free_irq_routine() and destroying IOAPIC/PIC
is a concern here?  As you mentioned, once kvm_destroy_vm() starts, VM is not
touchable from userspace, therefore it should not be possible to have code path
which can reference vIOAPIC/vPIC after they got destroyed but before
kvm_free_irq_routine() through IRQ routine table?

  reply	other threads:[~2026-07-06 22:33 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20260705045450.1325048-2-bestswngs@gmail.com>
2026-07-06 18:00 ` [PATCH v2] KVM: x86: Destroy the PIC and IOAPIC before destroying vCPUs Weiming Shi
2026-07-06 18:20   ` Sean Christopherson
2026-07-06 22:06     ` Huang, Kai
2026-07-06 22:10       ` Sean Christopherson
2026-07-06 22:33         ` Huang, Kai [this message]
2026-07-06 18:20   ` sashiko-bot
2026-07-07  6:32   ` [syzbot ci] " syzbot ci

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=82a5be971c5fbc90133f394fba9c7dd5c19fed91.camel@intel.com \
    --to=kai.huang@intel.com \
    --cc=bestswngs@gmail.com \
    --cc=jasowang@redhat.com \
    --cc=kvm@vger.kernel.org \
    --cc=pbonzini@redhat.com \
    --cc=seanjc@google.com \
    --cc=shixuanqing.11@bytedance.com \
    --cc=stable@vger.kernel.org \
    --cc=wangzhong.c0ss4ck@bytedance.com \
    --cc=zhanghy@sangfor.com \
    /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.