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

[Gleb Natapov]

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 wrote:
> > > > > > > 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. Tsirkin 
> > > > > > > > wrote:
> > > > > > > > > > >>  If so: does qemu
> > > > > > > > > > >>emulate this correctly?
> > > > > > > > > > >
> > > > > > > > > > >It mostly does.
> > > > > > > > > > 
> > > > > > > > > > I doubt it actually enables/disables the legacy vga ports.
> > > > > > > > > 
> > > > > > > > > I'll check when I have the time. We can fix it if it doesn't,
> > > > > > > > > 
> > > > > > > > So many guests (all of them?) just assume that vga ports and
> > > > > > > > framebuffer is there.
> > > > > > > 
> > > > > > > Why do you think they disable io memory then?
> > > > > > > 
> > > > > > Who and how and when disables io memory?
> > > > > 
> > > > > I think guest will do this if you disable the device through the 
> > > > > device
> > > > > manager. This might need a reboot to become effective.
> > > > > 
> > > > Try to do it with primary VGA adapter and tell us what happens :)
> > > > 
> > > > > > Some guests are designed to run
> > > > > > even on old ISA machines that have no way to disable anything. The
> > > > > > device is just there.
> > > > > > 
> > > > > > This is the same with IDE ports. BIOS "knows" legacy ISA ports and 
> > > > > > just
> > > > > > program them into PCI IO bars to be nice.
> > > > > 
> > > > > HAven't checked IDE, for VGA AFAIK BIOS does not program legacy ports 
> > > > > in
> > > > > the card, they are hardwired there. However, the card must not claim 
> > > > > any
> > > > > io transactions if IO memory is disabled in command register.
> > > > > 
> > > > Is this correct also for legacy ports?
> > > 
> > > Yes. The spec is quite explicit on this point:
> > > 
> > > 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 addresses
> > > 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’s I/O
> > > Space enable bit.
> > > 
> > > 
> > What do they mean by "initialization software".
> 
> BIOS or OS.
> 
> > How addresses is
> > assigned by initialization software without use of Base Address register? 
> 
> 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’s
> " I/O
> " Space enable bit.
> 
> 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.
> 
Strange wording "assigned by initialization software". Not "enabled",
but "assigned".

> > Looks like "initialization software" is something internal to HW.
> 
> Not really. Seabios does this simply by enabling io unconditionally.
> It could easily detect multiple VGA cards and only enable one.
> 
> > And what spec says about legacy mmio?
> 
> What do you want to know?
How it claims access to framebuffer. Legacy VGA has not only IO space
but MMIO space too.

> 
> > > > 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. 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.
> > > 
> > > 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.

> 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.
> 
And you will not find primary vga there.

--
                        Gleb.