From mboxrd@z Thu Jan  1 00:00:00 1970
From: Prasad Joshi <prasadjoshi124@gmail.com>
Subject: Re: Graphics pass-through
Date: Mon, 9 May 2011 15:55:23 +0100
Message-ID: <BANLkTi=cO9twGp=Kq9Q7zHTeKDxG8k=_cg@mail.gmail.com>
References: <AANLkTikNHRcDquYOL3NhsxkkBYcE48nMyu4+t8t=19e7@mail.gmail.com>
	<AANLkTi=h=HNhdwTC_z0+aGDOJN-TwZCVEbPq8qtwdrjA@mail.gmail.com>
	<AANLkTi=mTV591AMNkCVynq_BP04z_vnxn1=Dj4kPK-NA@mail.gmail.com>
	<4D415D70.8070105@web.de>
	<1296175554.2891.29.camel@x201>
	<4DC264CD.9080700@siemens.com>
	<1304608642.3081.35.camel@x201>
	<4DC7CCB3.8030607@siemens.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: QUOTED-PRINTABLE
Cc: Alex Williamson <alex.williamson@redhat.com>,
	=?ISO-8859-1?Q?Andr=E9_Weidemann?= <Andre.Weidemann@web.de>,
	"kvm@vger.kernel.org" <kvm@vger.kernel.org>,
	Oswaldo Cadenas <oswaldo.cadenas@gmail.com>
To: Jan Kiszka <jan.kiszka@siemens.com>
Return-path: <kvm-owner@vger.kernel.org>
Received: from mail-gx0-f174.google.com ([209.85.161.174]:64758 "EHLO
	mail-gx0-f174.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
	with ESMTP id S1750741Ab1EIOzY convert rfc822-to-8bit (ORCPT
	<rfc822;kvm@vger.kernel.org>); Mon, 9 May 2011 10:55:24 -0400
Received: by gxk21 with SMTP id 21so1836928gxk.19
        for <kvm@vger.kernel.org>; Mon, 09 May 2011 07:55:23 -0700 (PDT)
In-Reply-To: <4DC7CCB3.8030607@siemens.com>
Sender: kvm-owner@vger.kernel.org
List-ID: <kvm.vger.kernel.org>

On Mon, May 9, 2011 at 12:14 PM, Jan Kiszka <jan.kiszka@siemens.com> wr=
ote:
> On 2011-05-05 17:17, Alex Williamson wrote:
>>> And what about the host? When does Linux release the legacy range?
>>> Always or only when a specific (!=3Dvga/vesa) framebuffer driver is=
 loaded?
>>
>> Well, that's where it'd be nice if the vga arbiter was actually in m=
ore
>> widespread use. =A0It currently seems to be nothing more than a shar=
ed
>> mutex, but it would actually be useful if it included backends to do=
 the
>> chipset vga routing changes. =A0I think when I was testing this, I w=
as
>> externally poking PCI bridge chipset to toggle the VGA_EN bit.
>
> Right, we had to drop the approach to pass through the secondary card
> for now, the arbiter was not switching properly. Haven't checked yet =
if
> VGA_EN was properly set, though the kernel code looks like it should
> take care of this.
>
> Even with handing out the primary adapter, we had only mixed success =
so
> far. The onboard adapter worked well (in VESA mode), but the NVIDIA i=
s
> not displaying early boot messages at all. Maybe a vgabios issue.
> Windows was booting nevertheless - until we installed the NVIDIA
> drivers. Than it ran into a blue screen.
>
> BTW, what ATI adapter did you use precisely, and what did work, what =
not?

Not hijacking the mail thread. Just wanted to provide some inputs.

=46ew days back I had tried passing through the secondary graphics card=
=2E
I could pass-through two graphics cards to virtual machine.

02:00.0 VGA compatible controller: ATI Technologies Inc Redwood
[Radeon HD 5670] (prog-if 00 [VGA controller])
	Subsystem: PC Partner Limited Device e151
	Flags: bus master, fast devsel, latency 0, IRQ 87
	Memory at d0000000 (64-bit, prefetchable) [size=3D256M]
	Memory at fe6e0000 (64-bit, non-prefetchable) [size=3D128K]
	I/O ports at b000 [size=3D256]
	Expansion ROM at fe6c0000 [disabled] [size=3D128K]
	Capabilities: <access denied>
	Kernel driver in use: radeon
	Kernel modules: radeon

07:00.0 VGA compatible controller: nVidia Corporation G86 [Quadro NVS
290] (rev a1) (prog-if 00 [VGA controller])
       Subsystem: nVidia Corporation Device 0492
       Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr-Stepping- SERR+ FastB2B- DisINTx-
       Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=3Dfast
>TAbort-<TAbort- <MAbort- >SERR- <PERR- INTx-
       Latency: 0, Cache Line Size: 64 bytes
       Interrupt: pin A routed to IRQ 24
       Region 0: Memory at fd000000 (32-bit, non-prefetchable) [size=3D=
16M]
       Region 1: Memory at d0000000 (64-bit, prefetchable) [size=3D256M=
]
       Region 3: Memory at fa000000 (64-bit, non-prefetchable) [size=3D=
32M]
       Region 5: I/O ports at ec00 [size=3D128]
       Expansion ROM at fe9e0000 [disabled] [size=3D128K]
       Capabilities: <access denied>
       Kernel driver in use: nouveau
       Kernel modules: nouveau, nvidiafb

Both of them are PCIe cards. I have one more ATI card and another
NVIDIA card which does not work.

One of the reason the pass-through did not work is because of the
limit on amount of pci configuration memory by SeaBIOS. SeaBIOS places
a hard limit of 256MB or so on the amount of PCI memory space. Thus,
for some of the VGA device that need more memory never worked for me.

SeaBIOS allows this memory region to be extended to some value near
512MB, but even then the range is not enough.

Another problem with SeaBIOS which limits the amount of memory space
is: SeaBIOS allocates the BAR regions as they are encountered. As far
as I know, the BAR regions should be naturally aligned. Thus the
simple strategy of the SeaBIOS results in large fragmentation.
Therefore, even after increasing the PCI memory space to 512MB the BAR
regions were unallocated.

I will confirm you the details of other graphics cards which do not wor=
k.

Thanks and Regards,
Prasad

>
> One thing I was wondering: Most modern adapters should be PCIe these
> days. Our NVIDIA definitely is. But so far we are claiming to have it
> attached to a PCI bus. That caps all the extended capabilities e.g.
> Could this make some relevant difference?
>
> Jan
>
> --
> Siemens AG, Corporate Technology, CT T DE IT 1
> Corporate Competence Center Embedded Linux
>