Received-SPF: pass (google.com: domain of linux-kernel+bounces-179387-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.199.223 as permitted sender) client-ip=147.75.199.223;
Date: Wed, 15 May 2024 12:03:33 +0800 (CST)
Message-ID: <20240515120333724v7bc656U_mnZJaYDZd3vt@zte.com.cn>
In-Reply-To: <ZkPfB2VpGkRmMLsi@google.com>
References: Zj4qEG5QfbX4mo48@google.com,202405111034432081zGPU1OUESImLVeboZ0zQ@zte.com.cn,ZkPfB2VpGkRmMLsi@google.com
Precedence: bulk
Mime-Version: 1.0
From: <cheng.lin130@zte.com.cn>
To: <seanjc@google.com>
Cc: <pbonzini@redhat.com>, <kvm@vger.kernel.org>,
        <linux-kernel@vger.kernel.org>, <jiang.yong5@zte.com.cn>,
        <wang.liang82@zte.com.cn>, <jiang.xuexin@zte.com.cn>
Subject: =?UTF-8?B?UmU6IFtQQVRDSF0gS1ZNOiBpbnRyb2R1Y2Ugdm0ncyBtYXhfaGFsdF9wb2xsX25zIHRvIGRlYnVnZnM=?=
Content-Type: text/plain;
	charset="UTF-8"

> > > Yes, but _why_?  I know _what_ a debugs knob allows, but you have yet to explain
> > > why this
> > I think that if such an interface is provided, it can be used to check the source of
> > vm's max_halt_poll_ns, general module parameter or per-vm configuration.
> > When configured through per-vm, such an interface can be used to monitor this
> > configuration. If there is an error in the setting through KVMCAP_HALL_POLL, such
> > an interface can be used to fix or reset it dynamicly.
> But again, that argument can be made for myriad settings in KVM.  And unlike many
> settings, a "bad" max_halt_poll_ns can be fixed simply by redoing KVM_CAP_HALL_POLL.
Yes, Whether it is convenient to redo it will depend on the userspace.
> It's not KVM's responsibility to police userspace for bugs/errors, and IMO a
> backdoor into max_halt_poll_ns isn't justified.
Yes, It's not KVM's responsibility to police userspace. In addition to depend on userspace
redo, it can be seen as a planB to ensure that the VM works as expected.