public inbox for kvm@vger.kernel.org
 help / color / mirror / Atom feed
From: Gerd Hoffmann <kraxel@redhat.com>
To: "André Weidemann" <Andre.Weidemann@web.de>
Cc: Jan Kiszka <jan.kiszka@siemens.com>,
	Alex Williamson <alex.williamson@redhat.com>,
	seabios@seabios.org, kvm@vger.kernel.org
Subject: Re: Graphics card pass-through working with two pass pci-initialization
Date: Mon, 30 May 2011 09:34:07 +0200	[thread overview]
Message-ID: <4DE3486F.10502@redhat.com> (raw)
In-Reply-To: <4DDFFE1E.1060900@web.de>

   Hi,

> If I am not mistaken then the graphics card needs 2 bars, one with 256MB
> and one with 128K. The sound card then needs 1 bar with 16K of PCI memory.
> How big is the PCI memory with seabios?

Some comments on that (apply to the kraxel.q35 branch):

You can add this to the qemu command line to get the seabios debug 
output printed:

qemu $usualoptions -chardev stdio,id=seabios \
      -device isa-debugcon,iobase=0x402,chardev=seabios

Then you can watch seabios assigning memory.

The ordering of the cards should not matter at all, the hacked bios does 
a two-pass scan to order the memory bars by size and pack them nicely.

Finding holes in address space for pci bars is not perfect yet.  Right 
now it has sort-of hardcoded the 0xf0000000 -> 0xfec00000 range and 
tries to fit in stuff there.  If it fails to fit in everything it tries 
again but leaves out devices which are not essential for boot.  If it 
still fails the error isn't handled yet.  For q35 this is a non-starter 
as it uses the e0000000 -> efffffff range for pci mmconfig.  For the 
piix it doesn't hurt for now as the area above 0xe0000000 is unused. 
And the address space up to 0xe0000000 is used for guest ram only, thus 
it depends on the amount of memory you assign to the guest whenever this 
area is free or not.  If you assign -- say -- 2G to your guest 
everything above 0x80000000 is free.

With your setup (256m + 128m + small stuff) I'd expect seabios place the 
256m bar @ 0xe0000000, the 128m bar @ 0xf0000000 and all the small ones 
above 0xf8000000.  It will maps only the devices which it thinks are 
essential for boot (i.e. skip the sound card).

At the end of the day I want the pci address space allocation code have 
no hard-coded addresses in there but use the e820 table instead to 
figure how big the address space hole is.  Maybe even use multiple holes 
(i.e. also use the memory below mmconfig @ 0xe0000000 with q35).

cheers,
   Gerd

  parent reply	other threads:[~2011-05-30  7:34 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <1306227933-4880-1-git-send-email-kraxel@redhat.com>
     [not found] ` <1306227933-4880-2-git-send-email-kraxel@redhat.com>
     [not found]   ` <20110525023406.GG8517@valinux.co.jp>
     [not found]     ` <20110525043353.GH8517@valinux.co.jp>
     [not found]       ` <4DDCC7A5.60706@redhat.com>
     [not found]         ` <4DDCF9ED.5050208@redhat.com>
     [not found]           ` <4DDDDA8D.6080807@web.de>
     [not found]             ` <4DDDF62C.2010603@redhat.com>
2011-05-27  5:32               ` Graphics card pass-through working with two pass pci-initialization André Weidemann
2011-05-27 11:09                 ` Jan Kiszka
2011-05-27 19:40                   ` André Weidemann
2011-05-27 19:50                     ` André Weidemann
2011-05-26 21:19                       ` André Weidemann
2011-05-28  8:18                         ` Jan Kiszka
2010-05-28 18:49                           ` André Weidemann
2011-05-29 15:22                             ` Jan Kiszka
2011-05-29 15:33                               ` Avi Kivity
2011-05-29 19:30                               ` André Weidemann
2011-05-29 20:51                                 ` Jan Kiszka
2011-05-30  7:34                     ` Gerd Hoffmann [this message]
2011-05-30  9:58                       ` Gerd Hoffmann
2011-05-31  2:29                       ` [SeaBIOS] " Isaku Yamahata
2011-06-01  7:30                         ` Gerd Hoffmann
2011-06-01  9:56                           ` Alexander Graf
2011-06-01 10:20                             ` Rudolf Marek
2011-06-01 13:47                               ` Gerd Hoffmann
2011-06-01 14:40                                 ` Rudolf Marek
2011-06-01 22:15                                   ` Kevin O'Connor
2011-06-01 22:22                                     ` Yushu Yao
2011-06-01 11:13                             ` Avi Kivity
2011-06-01 11:16                               ` [SeaBIOS] " Alexander Graf
2011-06-01 11:18                                 ` Avi Kivity
2011-06-01 14:20                           ` [SeaBIOS] " Isaku Yamahata
2011-06-01 14:31                             ` Jan Kiszka
2011-06-01 14:36                               ` Alex Williamson
2011-06-01 22:34                             ` Kevin O'Connor
2011-06-06  6:30                               ` Gerd Hoffmann
2011-06-07  8:05                                 ` Jan Kiszka

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=4DE3486F.10502@redhat.com \
    --to=kraxel@redhat.com \
    --cc=Andre.Weidemann@web.de \
    --cc=alex.williamson@redhat.com \
    --cc=jan.kiszka@siemens.com \
    --cc=kvm@vger.kernel.org \
    --cc=seabios@seabios.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