From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=51003 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PIjoa-0000Tz-5e for qemu-devel@nongnu.org; Wed, 17 Nov 2010 10:20:53 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PIjoZ-0003vf-3b for qemu-devel@nongnu.org; Wed, 17 Nov 2010 10:20:52 -0500 Received: from mx1.redhat.com ([209.132.183.28]:24710) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PIjoY-0003vV-Sg for qemu-devel@nongnu.org; Wed, 17 Nov 2010 10:20:51 -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 oAHFKnbS020680 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 17 Nov 2010 10:20:49 -0500 Message-ID: <4CE3F2CD.4030701@redhat.com> Date: Wed, 17 Nov 2010 16:20:45 +0100 From: Gerd Hoffmann MIME-Version: 1.0 References: <1288704898-30234-1-git-send-email-kraxel@redhat.com> <20101116174306.GC4077@redhat.com> <4CE3D875.9020701@redhat.com> <20101117135842.GA13690@redhat.com> In-Reply-To: <20101117135842.GA13690@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [Qemu-devel] Re: [PATCH] spice: add qxl device List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Michael S. Tsirkin" Cc: qemu-devel@nongnu.org Hi, >>>> + qxl0 = qxl; >>> >>> What happens when this device is then removed? >> >> Better don't try ... > > Better prevent it then? How can I do that? >> The primary vga can't be hot-unplugged in qemu. Not only because >> the qxl0 pointer would point into nowhere in this case, but also >> because you can't unregister the graphic console. > > But do we really have to make this part of qxl design, with global > vars and stuff? Even if we have a limitation in qemu, qxl should be able > to keep all its data in device state I think ... It isn't part of the qxl design. It is just that register_displaychangelistener() doesn't provide a way to pass through a device state pointer, so these callbacks use qxl0 instead. >> Also having non-pci ressources (legacy vga I/O ports) is a problem. > > I'm not sure why is this a problem. It shouldn't be. Because it has ressources not visible in the pci config space? But you know the pci specs better than me. If you think it would work you are probably right ;) >> Because the first one actually *is* different. It is the only one >> which is vga compatible. It serves as primary display. You'll see >> the boot messages there. > > I thought it's up to the guest where to send boot messages. > Modern BIOSes have options to control this behaviour. It isn't. For one qemu has no multihead support. You'll see non-primary displays only when connecting via spice because of that. I also doubt seabios supports this. How does this work btw? Only one vga adapter can drive the legacy vga ports, right? Is there some way to enable/disable this per vga device? If so: does qemu emulate this correctly? > I think it's a mistake to make things such as device class > depend on the order devices are created in. > It would be better to make it a separate property, or give it a > different name. Having qxl-vga and qxl devices would certainly be an option. Works probably better than some qdev property usability-wise. >> I doubt you'll see it wrap in any real world scenario. Even with one >> hotplug + unplug cycle per second you'll need a bunch of years to >> see it wrap. Beside that at least in windows the device can't be >> unplugged in the first place, windows will veto the unplug request. > > Yes but we are splitting the unplug part from the guest eject, so user > will in the future be able to perform surprise removal just like with > real hardware. And with this in place, it need not take even a > millisecond to unplug a device. If you do that your guest will likely be quite upset and you'll have much bigger problems than the counter wrapping after millions of hotplugs. I also don't see the point in plugging a display like mad. Can we care about the *real* problems please? thanks, Gerd