qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Michael S. Tsirkin
Subject: Re: [Qemu-devel] Re: [PATCH] spice: add qxl device
Date: Thu, 18 Nov 2010 16:04:14 +0200
User-agent: Mutt/1.5.21 (2010-09-15)

On Thu, Nov 18, 2010 at 02:27:26PM +0200, Gleb Natapov wrote:
> 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.

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.


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

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

There's nothing in the spec that says so. IMO it
should be possible to have two cards and have BIOS (or maybe even the
OS) select which one to use.

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

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

Where? PCI spec explicitly allows VGA cards behind expansion slots,
stick it there, and you can remove it too.

> --
>                       Gleb.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]