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 A4FF31FF0E9 for ; Thu, 16 Jul 2026 11:32:53 +0200 (CEST) Received: from gate001.proxmox.com (localhost.localdomain [127.0.0.1]) by gate001.proxmox.com (Proxmox) with ESMTP id C8F0D21408; Thu, 16 Jul 2026 11:32:52 +0200 (CEST) Message-ID: Date: Thu, 16 Jul 2026 11:32:49 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Beta Subject: Re: [PATCH qemu-server v2 2/2] qemuserver: replace virtio-vga-gl with virtio-gpu-gl on aarch64 To: Kaiyang Wu , pve-devel@lists.proxmox.com References: <20260716073544.284241-1-wukaiyang@loongfans.cn> <20260716073544.284241-3-wukaiyang@loongfans.cn> Content-Language: en-US From: Dominik Csapak In-Reply-To: <20260716073544.284241-3-wukaiyang@loongfans.cn> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Bm-Milter-Handled: 55990f41-d878-4baa-be0a-ee34c49e34d2 X-Bm-Transport-Timestamp: 1784194350002 X-SPAM-LEVEL: Spam detection results: 0 AWL 0.301 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_LOW -0.7 Sender listed at https://www.dnswl.org/, low 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: 3UKPVQKRQTV42W4BQGU6XTXZGGFAEZWB X-Message-ID-Hash: 3UKPVQKRQTV42W4BQGU6XTXZGGFAEZWB 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: while this works, I'd probably prefer to expand our vga_map mechanism to include the arch too. e.g. having a 'sub map_vga_model($vga, $arch)' or something like this which internally has maybe a type->device map per arch? (or one per arch + a common fallback where the different architectures don't differ) On 7/16/26 9:36 AM, Kaiyang Wu wrote: > Fix the issue of virtio-gpu not being available on aarch64. > > QEMU only provides the non-VGA variant of virtio-gpu-gl on aarch64. > Replace VGA variant with non-VGA variant for 'virtio-vga-gl' device, > similar to how we replace 'virtio-vga' with 'virtio-gpu' on aarch64. > > Signed-off-by: Kaiyang Wu > --- > src/PVE/QemuServer.pm | 8 ++++++-- > 1 file changed, 6 insertions(+), 2 deletions(-) > > diff --git a/src/PVE/QemuServer.pm b/src/PVE/QemuServer.pm > index c11351bb..16922dd5 100644 > --- a/src/PVE/QemuServer.pm > +++ b/src/PVE/QemuServer.pm > @@ -1487,8 +1487,12 @@ sub print_vga_device { > my ($conf, $vga, $arch, $machine_version, $id, $qxlnum, $bridges) = @_; > > my $type = $vga_map->{ $vga->{type} }; > - if ($arch eq 'aarch64' && defined($type) && $type eq 'virtio-vga') { > - $type = 'virtio-gpu'; > + if ($arch eq 'aarch64' && defined($type)) { > + if ($type eq 'virtio-vga') { > + $type = 'virtio-gpu'; > + } elsif ($type eq 'virtio-vga-gl') { > + $type = 'virtio-gpu-gl'; > + } > } > my $vgamem_mb = $vga->{memory}; >