From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from gate001.proxmox.com (gate001.proxmox.com [45.144.208.40]) by lore.proxmox.com (Postfix) with ESMTPS id 7B1141FF0B4 for ; Tue, 08 Sep 2026 13:06:03 +0200 (CEST) Received: from gate001.proxmox.com (localhost.localdomain [127.0.0.1]) by gate001.proxmox.com (Proxmox) with ESMTP id 0D38F21575; Tue, 08 Sep 2026 13:05:59 +0200 (CEST) Message-ID: <999579f8-ece5-4b52-8850-dd41f2bdca77@proxmox.com> Date: Tue, 8 Sep 2026 13:05:43 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Beta Subject: Re: [PATCH qemu-server 1/3] qemuserver: add pvpanic device To: Kaiyang Wu , pve-devel@lists.proxmox.com References: <20260827103529.393388-1-wukaiyang@loongfans.cn> <20260827103529.393388-2-wukaiyang@loongfans.cn> <80d7911d-77d5-40aa-af27-a0bac993858c@proxmox.com> Content-Language: en-US From: Dominik Csapak In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Bm-Milter-Handled: 55990f41-d878-4baa-be0a-ee34c49e34d2 X-Bm-Transport-Timestamp: 1788865547509 X-SPAM-LEVEL: Spam detection results: 0 AWL 0.518 Adjusted score from AWL reputation of From: address DMARC_MISSING 0.1 Missing DMARC policy KAM_DMARC_STATUS 0.01 Test Rule for DKIM or SPF Failure with Strict Alignment (newer systems) RCVD_IN_DNSWL_MED -2.3 Sender listed at https://www.dnswl.org/, medium trust SPF_HELO_NONE 0.001 SPF: HELO does not publish an SPF Record SPF_PASS -0.001 SPF: sender matches SPF record Message-ID-Hash: 7RDPSAJPNRNWBK4M5QRBHYNIGQWV3I4P X-Message-ID-Hash: 7RDPSAJPNRNWBK4M5QRBHYNIGQWV3I4P X-MailFrom: d.csapak@proxmox.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; loop; banned-address; emergency; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: Kaiyang Wu X-Mailman-Version: 3.3.10 Precedence: list List-Id: Proxmox VE development discussion List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: On 9/8/26 12:09 PM, Kaiyang Wu wrote: > On 2026-09-04 16:30, Dominik Csapak wrote: >>> +        optional => 1, >>> +        type => 'string', >>> +        description => "Configure a pvpanic device to monitor guest >>> panics", >>> +        enum => [qw(pvpanic pvpanic-pci)], >> >> is it really useful to have two variants? couldn't we always >> use the PCI variant or is there some specific usecase for the ISA one? >> >> It could even be simply an option somewhere else (e.g. on the machine >> maybe?) >> >> if we just have single option, this might simplify the code below... >> > > An use case for this is deploying the ISA variant on Linux VMs with > kernel version >=3.1 and <5.2. The PCI variant is not supported until > Linux 5.2. > > We could not use the ISA variant by default either, since QEMU does not > support ISA devices at all on ARM64. since we didn't have any requests for this device at all, and i hope that nobody uses a linux kernel that old often anymore for modern vms, i guess we could get away with restricting this to the pci device. this works everywhere, and should make the code much simpler. If there is some request for this in the future for old kernels, we can still add a 'type' property to it, but i'd keep it simple right now.