qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Gleb Natapov <gleb@redhat.com>
To: "Michael S. Tsirkin" <mst@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 17:42:41 +0200	[thread overview]
Message-ID: <20101118154241.GX7948@redhat.com> (raw)
In-Reply-To: <20101118152548.GA10273@redhat.com>

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.

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

> 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 ;)

> > You can have development mobo were chipset can be unplugged. Should we
> > allow to hot-unplug chipset?
> 
> If it's useful, we could :)
On real HW you used to have memory controller there :)

> 
> > > 
> > > > > 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.
> > > 
> > You can't remove PCI card just from any PCI slot IIRC. Slot and add-on
> > card should be specifically designed to be hot-unpluggable.
> > (Something
> > to do with when power and data lines are disconnected during un-plug
> > IIRC). Not all things you can yank from mobo while OS is running are
> > "unpluggable" :)
> 
> That's true for PCI/PCI-X. I didn't check PCI Express, maybe there all cards
> are hotpluggable. Do you know?
> 
> 
Nope, no idea. On PCI Express you have much less lines to care about
though.

--
			Gleb.

  reply	other threads:[~2010-11-18 15:42 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
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 [this message]
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=20101118154241.GX7948@redhat.com \
    --to=gleb@redhat.com \
    --cc=kraxel@redhat.com \
    --cc=mst@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).