From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=56312 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PJ3aM-0005SV-Ac for qemu-devel@nongnu.org; Thu, 18 Nov 2010 07:27:31 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PJ3aK-00023X-LU for qemu-devel@nongnu.org; Thu, 18 Nov 2010 07:27:30 -0500 Received: from mx1.redhat.com ([209.132.183.28]:37230) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PJ3aK-00023Q-Bv for qemu-devel@nongnu.org; Thu, 18 Nov 2010 07:27:28 -0500 Received: from int-mx01.intmail.prod.int.phx2.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id oAICRRv2023173 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Thu, 18 Nov 2010 07:27:27 -0500 Date: Thu, 18 Nov 2010 14:27:26 +0200 From: Gleb Natapov Subject: Re: [Qemu-devel] Re: [PATCH] spice: add qxl device Message-ID: <20101118122726.GM7948@redhat.com> References: <4CE40AAF.7090202@redhat.com> <20101117180008.GE29556@redhat.com> <20101118080935.GW7948@redhat.com> <20101118090321.GD16832@redhat.com> <20101118091149.GY7948@redhat.com> <20101118093026.GG16832@redhat.com> <20101118095751.GA7948@redhat.com> <20101118113308.GC31261@redhat.com> <20101118115529.GJ7948@redhat.com> <20101118120311.GA31987@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=cp1255 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable In-Reply-To: <20101118120311.GA31987@redhat.com> List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Michael S. Tsirkin" Cc: Gerd Hoffmann , qemu-devel@nongnu.org On Thu, Nov 18, 2010 at 02:03:11PM +0200, Michael S. Tsirkin wrote: > On Thu, Nov 18, 2010 at 01:55:29PM +0200, Gleb Natapov wrote: > > On Thu, Nov 18, 2010 at 01:33:08PM +0200, Michael S. Tsirkin wrote: > > > On Thu, Nov 18, 2010 at 11:57:51AM +0200, Gleb Natapov wrote: > > > > On Thu, Nov 18, 2010 at 11:30:27AM +0200, Michael S. Tsirkin wrote: > > > > > On Thu, Nov 18, 2010 at 11:11:49AM +0200, Gleb Natapov wrote: > > > > > > On Thu, Nov 18, 2010 at 11:03:21AM +0200, Michael S. Tsirkin wr= ote: > > > > > > > On Thu, Nov 18, 2010 at 10:09:35AM +0200, Gleb Natapov wrote: > > > > > > > > On Wed, Nov 17, 2010 at 08:00:08PM +0200, Michael S. Tsirki= n wrote: > > > > > > > > > > >> If so: does qemu > > > > > > > > > > >>emulate this correctly? > > > > > > > > > > > > > > > > > > > > > >It mostly does. > > > > > > > > > >=20 > > > > > > > > > > I doubt it actually enables/disables the legacy vga por= ts. > > > > > > > > >=20 > > > > > > > > > I'll check when I have the time. We can fix it if it does= n't, > > > > > > > > >=20 > > > > > > > > So many guests (all of them?) just assume that vga ports and > > > > > > > > framebuffer is there. > > > > > > >=20 > > > > > > > Why do you think they disable io memory then? > > > > > > >=20 > > > > > > Who and how and when disables io memory? > > > > >=20 > > > > > I think guest will do this if you disable the device through the = device > > > > > manager. This might need a reboot to become effective. > > > > >=20 > > > > Try to do it with primary VGA adapter and tell us what happens :) > > > >=20 > > > > > > Some guests are designed to run > > > > > > even on old ISA machines that have no way to disable anything. = The > > > > > > device is just there. > > > > > >=20 > > > > > > This is the same with IDE ports. BIOS "knows" legacy ISA ports = and just > > > > > > program them into PCI IO bars to be nice. > > > > >=20 > > > > > HAven't checked IDE, for VGA AFAIK BIOS does not program legacy p= orts in > > > > > the card, they are hardwired there. However, the card must not cl= aim any > > > > > io transactions if IO memory is disabled in command register. > > > > >=20 > > > > Is this correct also for legacy ports? > > >=20 > > > Yes. The spec is quite explicit on this point: > > >=20 > > > A function that supports a PC legacy function (IDE, VGA, etc.) is > > > allowed to claim those addresses associated with the specific function > > > when the I/O Space (see Figure 6-2) enable bit is set. These address= es > > > are not requested using a Base Address register but are assigned by > > > initialization software. If a device identifies itself as a legacy > > > function (class code), the initialization software grants the device > > > permission to claim the I/O legacy addresses by setting the device=92= s I/O > > > Space enable bit. > > >=20 > > >=20 > > What do they mean by "initialization software". >=20 > BIOS or OS. >=20 > > How addresses is > > assigned by initialization software without use of Base Address registe= r?=20 >=20 > As it says: > " If a device identifies itself as a legacy > " function (class code), the initialization software grants the device > " permission to claim the I/O legacy addresses by setting the device=92s > " I/O > " Space enable bit. >=20 > So you look at the class code and know which addresses will be claimed. > The relevant table is in the appendix D, take a look there. >=20 Strange wording "assigned by initialization software". Not "enabled", but "assigned". > > Looks like "initialization software" is something internal to HW. >=20 > Not really. Seabios does this simply by enabling io unconditionally. > It could easily detect multiple VGA cards and only enable one. >=20 > > And what spec says about legacy mmio? >=20 > What do you want to know? How it claims access to framebuffer. Legacy VGA has not only IO space but MMIO space too. >=20 > > > > This wouldn't be backwards > > > > compatible to ISA machines, so old software my not run properly bac= k in > > > > the days when transaction from ISA to PCI happened. > > >=20 > > > initialization software could be the BIOS. > > > So maybe BIOS update was needed in the transition. > > >=20 > > That is possible. > >=20 > > > > So my guess is that > > > > old ISA ports works in backwards compatible way. > > >=20 > > > The spec seems to contradict this. > > >=20 > > > > > When qemu is started, it works correctly: the io memory is disabl= ed and card does > > > > > not claim any io. Then BIOS comes along and enables io. At this p= oint > > > > > map callback is invoked and maps io memory, card starts claiming = io. > > > > Looking at the code I see that cirrus claims all IO ports and > > > > framebuffer memory during init function unconditionally. > > >=20 > > > So that may be OK for ISA, but not for PCI. > > >=20 > > The code does it for both. >=20 > Yep. So it's a bug. >=20 > > > > >=20 > > > > > What is broken is that if BIOS/guest then disables IO memory, > > > > > (I think - even if guest is rebooted!) we will keep claiming IO t= ransactions. > > > > > That our emulation does this seems to be a clear spec violation, = we are > > > > > just lucky that BIOS/guest does not do this at the moment. > > > > >=20 > > > > >=20 > > > > >=20 > > > > > > > > So what "fixing" this will buy us? > > > > > > >=20 > > > > > > > Besides spec compliancy, you mean? Ability to support multip= le VGA > > > > > > > cards. That's how it works I think: BIOS enables IO on the pr= imary > > > > > > > VGA device only. > > > > > > >=20 > > > > > > What spec defines hot-plug for primary VGA adapter? > > > > >=20 > > > > > No idea about hotplug. I am talking about multiple VGA cards, > > > > > enabling/disabling them dynamically should be possible. > > > > Of course. With properly designed VGA card you should be able to ha= ve > > > > more then one, > > >=20 > > > And, for that to have a chance to work when all cards are identical, = you > > > don't claim IO when IO is disabled. > > >=20 > > But then only one card will be able to use IO since enabling IO on more > > the one cards will cause conflict. >=20 > Sure. That's life for legacy io though. >=20 But that is the point. You can't have two regular VGA card simultaneously. The card should be designed to work in legacy mode and non-legacy mode. Then one of them will be used by legacy software like BIOS and another will be driven from an OS by a driver written specifically for the card. > > > > but one of them will provide legacy functionality > > > > and is not removable. > > >=20 > > > The guest might not support hotplug. But there's no way > > > it can prevent surprise removal. qemu should not crash > > > when this happens. > > Qemu can prevent any removal, surprise or not. Qemu can just > > disallow device removal. >=20 > Yes, but that won't emulate real hardware faithfully. To the letter. There is no HW with hot-unplaggable primary vga card. You are welcome to surprise remove vga card from your machine and see what will happen. > On real hardware with a hotplug supporting slot > (and without an EM lock :) ) you can yank the card out > and the guest can do nothing about it. >=20 And you will not find primary vga there. -- Gleb.