Received-SPF: pass (google.com: domain of linux-kernel+bounces-37566-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:40f1:3f00::1 as permitted sender) client-ip=2604:1380:40f1:3f00::1;
From: Brilliant Hanabi <moehanabichan@gmail.com>
To: seanjc@google.com
Cc: bp@alien8.de,
	dave.hansen@linux.intel.com,
	hpa@zytor.com,
	kvm@vger.kernel.org,
	linux-kernel@vger.kernel.org,
	mingo@redhat.com,
	moehanabichan@gmail.com,
	pbonzini@redhat.com,
	tglx@linutronix.de,
	x86@kernel.org
Subject: Re: Re: Re: [PATCH] KVM: x86: Check irqchip mode before create PIT
Date: Thu, 25 Jan 2024 03:01:58 +0800
Message-Id: <20240124190158.230-1-moehanabichan@outlook.com>
In-Reply-To: <ZbFMXtGmtIMavZKW@google.com>
References: <ZbFMXtGmtIMavZKW@google.com>
Precedence: bulk
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

> On Thu, Jan 25, 2024, moehanabi wrote:
> > > On Thu, Jan 25, 2024, Brilliant Hanabi wrote:
> > > > As the kvm api(https://docs.kernel.org/virt/kvm/api.html) reads,
> > > > KVM_CREATE_PIT2 call is only valid after enabling in-kernel irqchip
> > > > support via KVM_CREATE_IRQCHIP.
> > > > 
> > > > Without this check, I can create PIT first and enable irqchip-split
> > > > then, which may cause the PIT invalid because of lacking of in-kernel
> > > > PIC to inject the interrupt.
> > > 
> > > Does this cause actual problems beyond the PIT not working for the guest?  E.g.
> > > does it put the host kernel at risk?  If the only problem is that the PIT doesn't
> > > work as expected, I'm tempted to tweak the docs to say that KVM's PIT emulation
> > > won't work without an in-kernel I/O APIC.  Rejecting the ioctl could theoertically
> > > break misconfigured setups that happen to work, e.g. because the guest never uses
> > > the PIT.
> > 
> > I don't think it will put the host kernel at risk. But that's exactly what
> > kvmtool does: it creates in-kernel PIT first and set KVM_CREATE_IRQCHIP then.
> 
> Right.  My concern, which could be unfounded paranoia, is that rejecting an ioctl()
> that used to succeed could break existing setups.  E.g. if a userspace VMM creates
> a PIT and checks the ioctl() result, but its guest(s) never actually use the PIT
> and so don't care that the PIT is busted.

Thanks for your review. In my opinion, it is better to avoid
potential bugs which is difficult to detect, as long as you can
return errors to let developers know about them in advance, although
the kernel is not to blame for this bug.

> > I found this problem because I was working on implementing a userspace PIC
> > and PIT in kvmtool. As I planned, I'm going to commit a related patch to 
> > kvmtool if this patch will be applied.
> > 
> > > > Signed-off-by: Brilliant Hanabi <moehanabichan@gmail.com>
> > > > ---
> > > >  arch/x86/kvm/x86.c | 2 ++
> > > >  1 file changed, 2 insertions(+)
> > > > 
> > > > diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
> > > > index 27e23714e960..3edc8478310f 100644
> > > > --- a/arch/x86/kvm/x86.c
> > > > +++ b/arch/x86/kvm/x86.c
> > > > @@ -7016,6 +7016,8 @@ int kvm_arch_vm_ioctl(struct file *filp, unsigned int ioctl, unsigned long arg)
> > > >  		r = -EEXIST;
> > > >  		if (kvm->arch.vpit)
> > > >  			goto create_pit_unlock;
> > > > +		if (!pic_in_kernel(kvm))
> > > > +			goto create_pit_unlock;
> > > 
> > > -EEXIST is not an appropriate errno.
> > 
> > Which errno do you think is better?
> 
> Maybe ENOENT?
>

I'm glad to send a new version patch if you're willing to accept the
patch.