Konrad Rzeszutek Wilk <konrad.wilk at oracle.com> writes: > On Tue, Jun 10, 2014 at 06:47:20PM +0200, lee wrote: >> Konrad Rzeszutek Wilk <konrad.wilk at oracle.com> writes: >> >> > On Tue, Jun 10, 2014 at 04:44:23AM +0200, lee wrote: >> >>> Konrad Rzeszutek Wilk <konrad.wilk at 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 at heimdall:~# xenpm get-cpufreq-para [CPU0] failed to get cpufreq parameter [...] root at heimdall:~# xenpm get-cpufreq-states root at 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 ... -- Knowledge is volatile and fluid. Software is power.