From: Jan Kiszka <jan.kiszka@siemens.com>
To: Alex Williamson <alex.williamson@redhat.com>
Cc: "André Weidemann" <Andre.Weidemann@web.de>,
"Prasad Joshi" <prasadjoshi124@gmail.com>,
"kvm@vger.kernel.org" <kvm@vger.kernel.org>,
"Oswaldo Cadenas" <oswaldo.cadenas@gmail.com>
Subject: Re: Graphics pass-through
Date: Mon, 09 May 2011 17:02:30 +0200 [thread overview]
Message-ID: <4DC80206.7030104@siemens.com> (raw)
In-Reply-To: <1304951371.26106.26.camel@x201>
On 2011-05-09 16:29, Alex Williamson wrote:
> On Mon, 2011-05-09 at 13:14 +0200, Jan Kiszka wrote:
>> 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 (!=vga/vesa) framebuffer driver is loaded?
>>>
>>> Well, that's where it'd be nice if the vga arbiter was actually in more
>>> widespread use. It currently seems to be nothing more than a shared
>>> mutex, but it would actually be useful if it included backends to do the
>>> chipset vga routing changes. I think when I was testing this, I was
>>> 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 is
>> 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.
>
> Interesting, IIRC I could never get VESA modes to work. I believe I
> only had a basic VGA16 mode running in a Windows guest too.
>
>> BTW, what ATI adapter did you use precisely, and what did work, what not?
>
> I have an old X550 (rv380?). I also have an Nvidia gs8400, but ISTR the
> ATI working better for me.
Is that Nvidia a PCIe adapter? Did it show BIOS / early boot messages
properly?
BTW, we are fighting with a Quadro FX 3800.
>
>> 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?
>
> The BIOS and early boot use shouldn't care too much about that, but I
> could imagine the high performance drivers potentially failing. Thanks,
Yeah, that was my thinking as well. But we will try to confirm this by
tracing the BIOS activities. There is a telling that some adapters do
not allow reading the true cold-boot ROM content during runtime, thus
booting those adapters inside the guest may fail to some degree.
Anyway, I've hacked on the q35 patches until they allowed me to boot a
Linux guest with an assigned PCIe Atheros WLAN adapter - all caps were
suddenly visible. Those bits are now on their way to our test box. Let's
see if they are able to change the BSOD a bit...
Jan
--
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux
next prev parent reply other threads:[~2011-05-09 15:02 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <AANLkTikNHRcDquYOL3NhsxkkBYcE48nMyu4+t8t=19e7@mail.gmail.com>
2011-01-25 23:03 ` Fwd: Graphics pass-through Prasad Joshi
2011-01-26 5:12 ` Alex Williamson
2011-01-26 8:17 ` Gerd Hoffmann
2011-01-27 11:56 ` André Weidemann
2011-01-28 0:45 ` Alex Williamson
2011-01-28 17:29 ` André Weidemann
2011-01-28 16:25 ` Alex Williamson
2011-05-05 8:50 ` Jan Kiszka
2011-05-05 15:17 ` Alex Williamson
2011-05-09 11:14 ` Jan Kiszka
2011-05-09 14:29 ` Alex Williamson
2011-05-09 15:02 ` Jan Kiszka [this message]
2011-05-09 14:55 ` Prasad Joshi
2011-05-09 15:27 ` Jan Kiszka
2011-05-09 15:40 ` Prasad Joshi
2011-05-09 15:48 ` Alex Williamson
2011-05-09 16:00 ` Jan Kiszka
2011-05-11 11:25 ` Avi Kivity
2011-05-11 13:08 ` Jan Kiszka
2011-05-11 13:26 ` Avi Kivity
2011-05-11 13:50 ` Jan Kiszka
2011-05-11 13:54 ` Avi Kivity
2011-05-11 14:06 ` Jan Kiszka
2011-05-11 14:14 ` Avi Kivity
2011-05-11 11:23 ` Avi Kivity
2011-05-11 12:31 ` Jan Kiszka
2011-05-10 10:53 ` Gerd Hoffmann
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=4DC80206.7030104@siemens.com \
--to=jan.kiszka@siemens.com \
--cc=Andre.Weidemann@web.de \
--cc=alex.williamson@redhat.com \
--cc=kvm@vger.kernel.org \
--cc=oswaldo.cadenas@gmail.com \
--cc=prasadjoshi124@gmail.com \
/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.