From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:43588) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SS6MR-0002dT-4R for qemu-devel@nongnu.org; Wed, 09 May 2012 08:51:28 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SS6MD-0007XE-9e for qemu-devel@nongnu.org; Wed, 09 May 2012 08:51:18 -0400 Received: from mx1.redhat.com ([209.132.183.28]:26060) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SS6MD-0007Ww-1l for qemu-devel@nongnu.org; Wed, 09 May 2012 08:51:05 -0400 Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q49Cp3co003777 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 9 May 2012 08:51:03 -0400 Message-ID: <4FAA6835.1010508@redhat.com> Date: Wed, 09 May 2012 14:51:01 +0200 From: Gerd Hoffmann MIME-Version: 1.0 References: <1336562766-25682-1-git-send-email-alevy@redhat.com> In-Reply-To: <1336562766-25682-1-git-send-email-alevy@redhat.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [post 1.1 PATCH] hw/qxl: disallow non sync io for revision >= 3 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Alon Levy Cc: qemu-devel@nongnu.org On 05/09/12 13:26, Alon Levy wrote: > The guest drivers should already know how to use async for revision 3. > But since it's still possible to have an older driver with revision 3 > that doesn't check for the revision, require a new parameter > "force_async", which we can later turn to 1 by default. Hmm. PCI revisions are supposed to be backward compatible, I don't think this is a good idea. We might want to log a warning or inform via 'info spice' in case we find a guest using the old, sync commands, so management can figure and warn, but I wouldn't do more. We can think about defining a qxl2 pci device, with a different pci id, where we can throw away old stuff. For such a new & incompatible device I'd like to change a few more things while being at it ... (1) go for a single 32bit mmio register set similar to real hardware. That should replace the rom bar (device info), the fields in the ram area (where interrupt mask etc live) and the io command bar. (2) consider virtio for the rings. Not sure this is worth it as that wouldn't make qxl bus-agnostic, for vga compatibility and device memory we'll still have a dependency on pci ... (3) renumber the remaining bars so we can make the vram bar 64bit, without a 32bit compatibility alias needed. (4) Drop QXL_IO_SET_MODE support and the mode list. Possibly more ... cheers, Gerd