From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:41624) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Su10i-0003uR-5T for qemu-devel@nongnu.org; Wed, 25 Jul 2012 08:48:23 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Su10e-0006KF-3Y for qemu-devel@nongnu.org; Wed, 25 Jul 2012 08:48:16 -0400 Received: from mx1.redhat.com ([209.132.183.28]:52267) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Su10d-0006K8-Rk for qemu-devel@nongnu.org; Wed, 25 Jul 2012 08:48:12 -0400 Message-ID: <500FEB07.5010009@redhat.com> Date: Wed, 25 Jul 2012 15:48:07 +0300 From: Avi Kivity MIME-Version: 1.0 References: <1343188660.3715.41.camel@pasglop> <500FC9F8.6010002@redhat.com> <1343213618.3715.48.camel@pasglop> In-Reply-To: <1343213618.3715.48.camel@pasglop> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] vga-pci and MMIO BAR List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Benjamin Herrenschmidt Cc: qemu-devel@nongnu.org On 07/25/2012 01:53 PM, Benjamin Herrenschmidt wrote: > On Wed, 2012-07-25 at 13:27 +0300, Avi Kivity wrote: >> On 07/25/2012 06:57 AM, Benjamin Herrenschmidt wrote: >> > Hi folks ! >> > >> > Would there be any objection to adding a second MMIO BAR to qemu-vga >> > which mirrors the bochs magic VBE ports ? >> > >> > Support for IO space is optional in PCIe and can be problematic on some >> > architectures, it would be nice to be able to program the card entirely >> > using mmio. >> >> Can we choose a PCIe chipset that does support IO space? > > Why bother ? It's not like mode setting is performance critical and IO > space is always going to be a pain on non-x86 ... For compatibility? If it's a special pain, then I understand, but what's the difference between emulating chipset A or B? > >> If not, we can add a second BAR, but it should disappear when running an >> older machine type. > > Well, the IO ports in legacy space are still there. We can also make the > "register BAR" exist in both mode or we can add a second BAR and have > x86 "prefer" IO... whatever rocks your boat as long as it's a BAR, it's > the legacy hole that's annoying for me :-) A guest created with -M old must look exactly the same as it did in an older version of qemu, no extra BARs. -- error compiling committee.c: too many arguments to function