Re: [Qemu-devel] Re: [PATCH] spice: add qxl device

[Gleb Natapov]

On Thu, Nov 18, 2010 at 06:04:56PM +0200, Michael S. Tsirkin wrote:
> On Thu, Nov 18, 2010 at 05:42:41PM +0200, Gleb Natapov wrote:
> > On Thu, Nov 18, 2010 at 05:25:48PM +0200, Michael S. Tsirkin wrote:
> > > On Thu, Nov 18, 2010 at 04:57:55PM +0200, Gleb Natapov wrote:
> > > > On Thu, Nov 18, 2010 at 04:04:14PM +0200, Michael S. Tsirkin wrote:
> > > > > > > What do you want to know?
> > > > > > How it claims access to framebuffer. Legacy VGA has not only IO 
> > > > > > space
> > > > > > but MMIO space too.
> > > > > 
> > > > > There's a separate bit to enable memory is that is what you
> > > > > are asking about.
> > > > > 
> > > > > The spec specifies the address ranges:
> > > > > 
> > > > >       Base class 03. Sub-class 00. Interface 000 0000b:
> > > > > 
> > > > >       VGA-compatible controller. Memory addresses 0A 0000h through 0B 
> > > > > FFFFh.
> > > > >       I/O addresses 3B0h to 3BBh and 3C0h to 3DFh and all aliases of 
> > > > > these
> > > > >       addresses.
> > > > > 
> > > > > 
> > > > So MMIO space is also not configurable? In short you can't insert two
> > > > vga card in two pci slots and use both simultaneously.
> > > 
> > > I think so, yes. But you can switch between them by disabling
> > > one and enabling another one.
> > > 
> > Sure. At init time.
> > 
> > > > > > > > > > This wouldn't be backwards
> > > > > > > > > > compatible to ISA machines, so old software my not run 
> > > > > > > > > > properly back in
> > > > > > > > > > the days when transaction from ISA to PCI happened.
> > > > > > > > > 
> > > > > > > > > initialization software could be the BIOS.
> > > > > > > > > So maybe BIOS update was needed in the transition.
> > > > > > > > > 
> > > > > > > > That is possible.
> > > > > > > > 
> > > > > > > > > > So my guess is that
> > > > > > > > > > old ISA ports works in backwards compatible way.
> > > > > > > > > 
> > > > > > > > > The spec seems to contradict this.
> > > > > > > > > 
> > > > > > > > > > > When qemu is started, it works correctly: the io memory 
> > > > > > > > > > > is disabled and card does
> > > > > > > > > > > not claim any io. Then BIOS comes along and enables io. 
> > > > > > > > > > > At this point
> > > > > > > > > > > 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.
> > > > > > > > > 
> > > > > > > > > So that may be OK for ISA, but not for PCI.
> > > > > > > > > 
> > > > > > > > The code does it for both.
> > > > > > > 
> > > > > > > Yep. So it's a bug.
> > > > > > > 
> > > > > > > > > > > 
> > > > > > > > > > > What is broken is that if BIOS/guest then disables IO 
> > > > > > > > > > > memory,
> > > > > > > > > > > (I think - even if guest is rebooted!) we will keep 
> > > > > > > > > > > claiming IO transactions.
> > > > > > > > > > > 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.
> > > > > > > > > > > 
> > > > > > > > > > > 
> > > > > > > > > > > 
> > > > > > > > > > > > > > So what "fixing" this will buy us?
> > > > > > > > > > > > > 
> > > > > > > > > > > > > Besides spec compliancy, you mean?  Ability to 
> > > > > > > > > > > > > support multiple VGA
> > > > > > > > > > > > > cards. That's how it works I think: BIOS enables IO 
> > > > > > > > > > > > > on the primary
> > > > > > > > > > > > > VGA device only.
> > > > > > > > > > > > > 
> > > > > > > > > > > > What spec defines hot-plug for primary VGA adapter?
> > > > > > > > > > > 
> > > > > > > > > > > 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 have
> > > > > > > > > > more then one,
> > > > > > > > > 
> > > > > > > > > And, for that to have a chance to work when all cards are 
> > > > > > > > > identical, you
> > > > > > > > > don't claim IO when IO is disabled.
> > > > > > > > > 
> > > > > > > > But then only one card will be able to use IO since enabling IO 
> > > > > > > > on more
> > > > > > > > the one cards will cause conflict.
> > > > > > > 
> > > > > > > Sure. That's life for legacy io though.
> > > > > > > 
> > > > > > But that is the point. You can't have two regular VGA card
> > > > > > simultaneously.
> > > > > 
> > > > > You can't *enable* them simultaneously. The fact that we cant create
> > > > > them in qemu is a bug.
> > > > You can insert two of them on real HW too.
> > > 
> > > Yes. You can insert any number of VGA cards on a PCI bus,
> > > BIOS can configure one and disable the rest.
> > > 
> > Bios can configure one as legacy. And all other can be happily used by
> > guest OS with proper drivers.
> 
> Maybe. There's no standard way to disable 'legacy mode' though.
> So a card might or might not keep claiming the legacy ranges (assuming
> io/memory is enabled).  Maybe if you want to use multiple cards all of
> them need drivers.
> 
May be.

> > > > > > > > > > but one of them will provide legacy functionality
> > > > > > > > > > and is not removable.
> > > > > > > > > 
> > > > > > > > > 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.
> > > > > > > 
> > > > > > > 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.
> > > > > 
> > > > > This is different from removing any other card with hotplug module
> > > > > unloaded in OS how?  OS might crash but so what? You can always reboot
> > > > > it, hardware won't be damaged, so qemu shouldn't crash too.
> > > > If guest can't handle unplug there is no meaning for qemu to provide it.
> > > 
> > > Sure there's meaning. Giving guest access to backend
> > > has security implications. We must have a way to revoke that
> > > access even if guest misbehaves.
> > > 
> > I am not sure what do you mean by "giving guest access to backend"?
> > Guest shouldn't be able to surprise removal VGA card, or any card at all
> > for that matter.
> 
> WHQL includes surprise removal tests. So any card that passed
> that will work with surprise removal.
> 
Yeah. But it is not real "surprise removal". It will not crash qemu.

> > > I expect surprise removal to be of most use for
> > > assigned devices. But even for emulated devices, we have a small
> > > number of slots available, so it would still be useful to free up the PCI 
> > > slot,
> > > even if guest needs to be rebooted then.
> > > 
> > We are talking about should we require primary VGA to be
> > hot-unplaggable. The last thing you want to remove to free PCI slots is
> > primary VGA card especially if no guest OS can handle it ;)
> 
> What I am saying is we need surprise removal generally.
For all HW that we allow to remove from monitor sure.

> If won't be too bad if we make these commands fail for VGA.
> 
The patch is on the list already.

--
                        Gleb.