All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Michael S. Tsirkin" <mst@redhat.com>
To: Gleb Natapov <gleb@redhat.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>, qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] Re: [PATCH] spice: add qxl device
Date: Thu, 18 Nov 2010 13:33:08 +0200	[thread overview]
Message-ID: <20101118113308.GC31261@redhat.com> (raw)
In-Reply-To: <20101118095751.GA7948@redhat.com>

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.


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

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

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

> > 
> > > Our BIOS should support
> > > -M isa machine too.
> > 
> > > There is no way to disable VGA or even check if it
> > > is present there.
> > 
> > So I guess with isa you can't have multiple VGA cards work.  With PCI
> > I think you can.
> > 
> With isa you just need custom designed HW and software and you can have
> as many VGA cards as you want :)
> 
> --
> 			Gleb.

  reply	other threads:[~2010-11-18 11:33 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-11-02 13:34 [Qemu-devel] [PATCH] spice: add qxl device Gerd Hoffmann
2010-11-16 14:24 ` Anthony Liguori
2010-11-17 13:14   ` Gerd Hoffmann
2010-11-16 17:43 ` [Qemu-devel] " Michael S. Tsirkin
2010-11-17 13:28   ` Gerd Hoffmann
2010-11-17 13:58     ` Michael S. Tsirkin
2010-11-17 15:20       ` Gerd Hoffmann
2010-11-17 16:42         ` Michael S. Tsirkin
2010-11-17 17:02           ` Gerd Hoffmann
2010-11-17 18:00             ` Michael S. Tsirkin
2010-11-18  8:09               ` Gleb Natapov
2010-11-18  8:22                 ` Gerd Hoffmann
2010-11-18  9:08                   ` Michael S. Tsirkin
2010-11-18 10:46                     ` Gerd Hoffmann
2010-11-18  9:03                 ` Michael S. Tsirkin
2010-11-18  9:11                   ` Gleb Natapov
2010-11-18  9:30                     ` Michael S. Tsirkin
2010-11-18  9:57                       ` Gleb Natapov
2010-11-18 11:33                         ` Michael S. Tsirkin [this message]
2010-11-18 11:55                           ` Gleb Natapov
2010-11-18 12:03                             ` Michael S. Tsirkin
2010-11-18 12:27                               ` Gleb Natapov
2010-11-18 14:04                                 ` Michael S. Tsirkin
2010-11-18 14:57                                   ` Gleb Natapov
2010-11-18 15:25                                     ` Michael S. Tsirkin
2010-11-18 15:42                                       ` Gleb Natapov
2010-11-18 16:04                                         ` Michael S. Tsirkin
2010-11-18 16:10                                           ` Gleb Natapov
2010-11-18 16:14                                             ` Michael S. Tsirkin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20101118113308.GC31261@redhat.com \
    --to=mst@redhat.com \
    --cc=gleb@redhat.com \
    --cc=kraxel@redhat.com \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.