[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] GTX 760 passed through



On Tue, 3 Dec 2013 11:09:34 -0500, Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx> wrote:
On Mon, Dec 02, 2013 at 09:04:51PM +0000, Gordan Bobic wrote:
On 12/02/2013 08:16 PM, Konrad Rzeszutek Wilk wrote:
>On Mon, Dec 02, 2013 at 06:36:48PM +0100, Nvidia Reverse wrote:
>>The nvlddmkm.sys needs to be patched removing the whitelist for the device
>>ids allowed to be virtualized.
>>But the interesting part is how NVIDIA detects that the GPU is
>>virtualized...
>
>Interesting. I was thinking that the BIOS/firmware would run itself
>in the virtualized or non-virtualized code depending on the device id.
>But you seem to imply that it is all in the OS driver code.

Certainly not the case with the BIOS part - Quadro BIOS is quite
different. GeForce BIOS, for example, doesn't have ECC control code
and a few other things. For example, flash a 4GB GTX680 with a K5000
BIOS and the ECC control options start to show up in the control
panel. If they went to the trouble of stripping all that out of the
GeForce BIOS I'd rather like to think that they would have tripped
out any magic required to run virtualized.

Since we know that isn't the case (since removing a single resistor
on a 680 makes it work just fine virtualized as a Tesla K10), the
only logical conclusion there is nothing that the BIOS does that
makes any difference to virtualization.

>At which point the idea of just modifying in QEMU the PCI device ID
>to be different would .. well, make it possible to do a lot of
>neat stuff as Gordan pointed out.

Only on pre-Kepler GPUs. As far as I can tell, there is a register
in the GPU where the hard-strapped device ID is kept, and this gets
set at boot time BEFORE the BIOS runs. It is the pre-BIOS device ID
that gets stuck in the GPU, and the soft-strap only affects the PCI
device ID - yes, the two can differ on Kepler. Driver keys off the

HA! Schizophrenic card.

I think it's to do with the way Grid cards are designed to work.
The idea being that the card itself is a Grid, but you can run
it in different modes in the guest (at least on ESXi), e.g.
GeForce, Quadro or Tesla. So the guest sees the PCI device ID
of a GeForce card, and the driver for the GeForce card loads,
but it only works because it checks the GPU's device ID, and
only works if the GPU's device ID is one that it is supposed
to work on.

The PCI device IDs for the virtual GPUs are different from
the physical ones, though (see the thing I pasted in the
other thread.

hard-strapped ID.

>In terms of legal issues of patching up a windows kernel driver and
>showing other folks how to do it?
>
>No idea. Presumarily there is some license thing that you had agreed
>when you installed the Nvidia driver - check to see what it says.

I think the OP was more referring to specifically applying a patch
to Xen to prevent the Nvidia driver in domU from being able to
figure out it's running in a VM. If it doesn't think it's running in
a VM, it doesn't disable the device.

Oh, Xen is open-source so you can do whatever you want (to a certain
extent of course - you can't package and resell it without providing
a means to get the source code).

I for one am very much looking forward to seeing aidivn's patch
for this. :)

BTW, Konrad, did your GTX460 work with PCI passthrough after
modifying it to a Q4000M?

Yes, pretty fantastic! And it seems to work OK - I am loading some
games on the Windows guest to double-check. The audio part does not
seem to work - oddly enough.

Splendid! I never tried HDMI audio - I don't have any HDMI audio
hardware, so I have no way of testing whether it works. In fairness
I find PCI audio passthrough to be problematic anyway. Sound gets
choppy with both Intel HDA (ICH10) and Creative Labs PCIe audio
at times (both run with intel-snd-hda driver on Linux). OTOH, a
Â3 USB audio adapter (USB host passed via PCI passthrough) works
lovely.

I also have a Radeon 4870  that in the past worked when passing
in the guest but one had to 'unplug' it in Windows to be able to
restart it again. Will try that once I get a machine that can have
three GPUs in it.

I have seen major problems with a setup where I have a dom0 ATI
card and want another ATI card for domU. With 4850 in dom0 and a
7970 for domU, when the domU starts up the host crashes solid.
As far as I can tell, something happens with BIOS on one card
initializing the other, and the dom0 GPU gets wiped out in
the process. I just gave up on ATI for this decade. Maybe next
decade.

Now I hadn't tried to start the Windows guest with more than 2GB -
but when I do that I should have some patches to make that work (based
on your work).

If your IOMMU and PCIe bridges work fine you shouldn't need
them. Remember that those (unfinished) patches were only
useful when running with secondary PCIe bridges that bypas
the root PCIe bridge and do DMA directly (thus preventing
the IOMMU from translating the memory addresses). If your
motherboard doesn't engage in such crazyness, you shouldn't
need those patches.

I've put the work on those patches on hold because
everything I've read about PVH thus far looks suspiciously
like it might solve the problem anyway (in fact, some of the
patches in the set you mention came straight out of the PVH
implementation, IIRC). So I think I'll try PVH when the next
version comes out and see how that fares. For now I can live
with the fact that my incomplete patch set results in 2.5GB
or RAM going "missing" for each domU.

Either way, even if you need the patches, you should be OK
with passing the amount of RAM to domU that only goes up to
the address where your lowest mapped BAR is on the host.

Gordan

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.