On Tue, Jun 10, 2014 at 06:47:20PM +0200, lee wrote: > Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx> writes: > > > On Tue, Jun 10, 2014 at 04:44:23AM +0200, lee wrote: > >>> Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx> 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)? > > 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. > > >> > But irrespective of that - the steps mentioned there are out of date. > >> > The correct option should be 'xen-pciback.hide=(06:00.0) xen-pciback.permissive=1' > >> > >> That's one of the problems: Xen is very poorly documented. > > > > Any help in improving the documentations would be appreciated. Every month > > we run 'Documentation days' and any work - either on Wiki, manuals, docs, etc > > would be quite appreciated. > > If I have some time, I might make a writeup about how to set up what I > did. But it seems I'm using an outdated version of xen, which is what > comes with Debian, so by the time I'd finish the writeup, it would be > outdated and contribute to confusion more than do any good. > > And considering xen, I don't really know anything. I figured out that > passthrough doesn't work out of the box on Debian because the module for > the device was loaded from the initrd.img before the xen-pciback module > and made a bug report because you're supposed to be able to use files in > /etc/modprobe.d which can specify dependencies and when you do that, you > can't have that just overridden or there's no point in doing that --- > and there doesn't seem to be any other way to specify the order in which > modules are loaded, and long ago, Debian came up with a policy that > things should work out of the box whenever possible (which they might > have forgotten by now ...). So maybe they'll fix this problem. > > Anyway, it probably goes for other distributions as well, and a hint in > the xen docs probably won't hurt. > > > Please see http://wiki.xenproject.org/wiki/Xen_Project_Document_Days > > I tried to make a request to become a "wiki editor". There might be > some places in the docs I might be able to make clearer. I don't know > if that was successful, though. It seemed to want to redirect me to > some google website ... > > > -- > Knowledge is volatile and fluid. Software is power. > _______________________________________________ > CentOS-virt mailing list > CentOS-virt@xxxxxxxxxx > http://lists.centos.org/mailman/listinfo/centos-virt _______________________________________________ CentOS-virt mailing list CentOS-virt@xxxxxxxxxx http://lists.centos.org/mailman/listinfo/centos-virt
