On Wed, May 09, 2012 at 02:51:01PM +0200, Gerd Hoffmann wrote: > 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 ...
Sounds like a good idea. I'll try to do a patch with the sync warning first - the reason for this patch was trying to prevent deadlocks with boxes, the management in question. The virtio-rings - I know someone is already working on this and is pretty well advanced. Actually I think they are doing a whole new device, but I haven't seen any code yet. Probably not pci. But just replacing the rings should not be that hard (tm) :) > > cheers, > Gerd
