xen-devel.lists.xenproject.org archive mirror
 help / color / mirror / Atom feed
From: Gordan Bobic <gordan@bobich.net>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Cc: xen-devel@lists.xen.org, Nvidia Reverse <aidivnreverse@gmail.com>
Subject: Re: GTX 760 passed through
Date: Mon, 02 Dec 2013 21:04:51 +0000	[thread overview]
Message-ID: <529CF5F3.1050904@bobich.net> (raw)
In-Reply-To: <20131202201620.GA17961@phenom.dumpdata.com>

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

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

Gordan

  reply	other threads:[~2013-12-02 21:04 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-12-02 12:18 GTX 760 passed through Nvidia Reverse
2013-12-02 16:12 ` Gordan Bobic
2013-12-02 17:36   ` Nvidia Reverse
2013-12-02 20:16     ` Konrad Rzeszutek Wilk
2013-12-02 21:04       ` Gordan Bobic [this message]
2013-12-03 16:09         ` Konrad Rzeszutek Wilk
2013-12-03 16:56           ` Gordan Bobic

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=529CF5F3.1050904@bobich.net \
    --to=gordan@bobich.net \
    --cc=aidivnreverse@gmail.com \
    --cc=konrad.wilk@oracle.com \
    --cc=xen-devel@lists.xen.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).