From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id B8B79C6FA99 for ; Fri, 10 Mar 2023 13:50:12 +0000 (UTC) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pad7R-0007I7-85; Fri, 10 Mar 2023 08:49:13 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pad7P-0007Hn-RP; Fri, 10 Mar 2023 08:49:11 -0500 Received: from mail.csgraf.de ([85.25.223.15] helo=zulu616.server4you.de) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pad7N-00068h-G1; Fri, 10 Mar 2023 08:49:11 -0500 Received: from [0.0.0.0] (ec2-3-122-114-9.eu-central-1.compute.amazonaws.com [3.122.114.9]) by csgraf.de (Postfix) with ESMTPSA id 8CA486080292; Fri, 10 Mar 2023 14:48:57 +0100 (CET) Message-ID: <44c6459b-f17f-8cb7-ba2d-a9187f32cde0@csgraf.de> Date: Fri, 10 Mar 2023 14:48:56 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0) Gecko/20100101 Thunderbird/102.8.0 Subject: Re: [PATCH 0/2] hw/intc/arm_gicv3: Bump ITT entry size to 16 Content-Language: en-US To: Peter Maydell Cc: qemu-devel@nongnu.org, qemu-arm@nongnu.org, Yanan Wang , =?UTF-8?Q?Philippe_Mathieu-Daud=c3=a9?= , Marcel Apfelbaum , Eduardo Habkost , Shashi Mallela , Eric Auger , Neil Armstrong References: <20221223085047.94832-1-agraf@csgraf.de> From: Alexander Graf In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass client-ip=85.25.223.15; envelope-from=agraf@csgraf.de; helo=zulu616.server4you.de X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Sender: qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org On 03.01.23 18:41, Peter Maydell wrote: > On Fri, 23 Dec 2022 at 08:50, Alexander Graf wrote: >> While trying to make Windows work with GICv3 emulation, I stumbled over >> the fact that it only supports ITT entry sizes that are power of 2 sized. >> >> While the spec allows arbitrary sizes, in practice hardware will always >> expose power of 2 sizes and so this limitation is not really a problem >> in real world scenarios. However, we only expose a 12 byte ITT entry size >> which makes Windows blue screen on boot. >> >> The easy way to get around that problem is to bump the size to 16. That >> is a power of 2, basically is what hardware would expose given the amount >> of bits we need per entry and doesn't break any existing scenarios. To >> play it safe, this patch set only bumps them on newer machine types. > This is a Windows bug and should IMHO be fixed in that guest OS. > Changing the ITT entry size of QEMU's implementation introduces > an unnecessary incompatibility in migration and wastes memory > (we're already a bit unnecessarily profligate with ITT entries > compared to real hardware). Follow-up on this: Microsoft has fixed the issue in Windows. That won't make older versions work, but the current should be fine with GICv3: https://fosstodon.org/@itanium/109909281184181276 Alex