Konrad Rzeszutek Wilk konrad.wilk@oracle.com writes:
On Tue, Jun 10, 2014 at 06:47:20PM +0200, lee wrote:
Konrad Rzeszutek Wilk konrad.wilk@oracle.com writes:
On Tue, Jun 10, 2014 at 04:44:23AM +0200, lee wrote:
Konrad Rzeszutek Wilk konrad.wilk@oracle.com writes:
The device should be visible in the dom0 - even when it is for passthrough.
Why should it be visible when it's hidden?
The 'hide' part is to hide it from the device drivers in the initial domain - dom0. That is so that they will not try to use it - as we plan to pass them to a guest. We need it in the dom0 to do admin type work - FLR it, etc.
With Debian, it's not visible in dom0 when the passthrough works. That's how I found out that it does work to begin with, and it makes sense to me.
That is a surprise. If you do 'lspci' in your dom0 do you see the device (06:00.0)?
Lspci still shows it, and the device (eth1) is invisible.
What does FLR mean? And how do you do something with a device for which no drivers are loaded? I'd find it rather unusual to have a device without drivers and even be able to use it; such devices usually don't show up.
Function Level Reset.
You pass the device to a guest so it can load the drivers and the initial domain (dom0) won't use it.
Hm, xen kinda makes the cpus and their power management invisible, too:
root@heimdall:~# xenpm get-cpufreq-para [CPU0] failed to get cpufreq parameter [...] root@heimdall:~# xenpm get-cpufreq-states root@heimdall:~#
So I guess it could as well make it so that lspci doesn't show passed-out devices.
BTW, getting some info in dmesg might be nice, like a message saying "xen-pciback: device 06:00.0 can be passed through to guests". We could actually see right away if it did work or not. That a device disappears isn't too great as indication, especially not when lspci still lists it.
Of course, you could use the command (which I don't remember) to show devices that can be passed through. But that may just work as well as 'xenpm get-cpufreq-states': Apparently, there aren't any CPUs ...