xen-pciback.hide syntax

xen-pciback.hide syntax

[Sander Eikelenboom]

Hi Konrad,

The syntax for specifying the devices for pciback to hide is "bus:device.function".
While thinking about cooking up a patch to be able to use a "*" wildcard for the function, i was wondering if not hiding all functions of a device is feasible at all.

For what I understand of PCI, function 0 is always required, so if I only hide function 0, i can't use the other functions in dom0, since those functions would require a function 0, which is hidden.

So would it be more logical to drop/ignore the function from the BDF, and always hide all functions from a device ?

--
Regards,

Sander

Re: xen-pciback.hide syntax

[Konrad Rzeszutek Wilk]

On Sat, May 19, 2012 at 10:46:15AM +0200, Sander Eikelenboom wrote:
> Hi Konrad,
> 
> The syntax for specifying the devices for pciback to hide is "bus:device.function".
> While thinking about cooking up a patch to be able to use a "*" wildcard for the function, i was wondering if not hiding all functions of a device is feasible at all.
> 
> For what I understand of PCI, function 0 is always required, so if I only hide function 0, i can't use the other functions in dom0, since those functions would require a function 0, which is hidden.
> 
> So would it be more logical to drop/ignore the function from the BDF, and always hide all functions from a device ?

That might run afoul of the SR-IOV virtual devices. They (when loaded) provide a fake
bus:device:function, where the device is port (so if the SR-IOV card has two
jacks, you get 00 and 01), and the function is for the amount of VFs it can make.
On the Intel SR-IOV NIC with 'igbvf.max_vfs=7' I end up with 14 PCI devices, where
the function bear no resemblence to each other (and can be passed in different guests).

The PCI restriction I know of is if the device is behind a bridge. The issue here
is that .. well, you could pass in a different function to a different guest, but
one guest's hardware device could listen on the other guests' function. It would
require tweaking the driver to dump the contents of some registers and some deep
hacking, but that is the security issue with that.

> 
> --
> Regards,
> 
> Sander
> 

Re: xen-pciback.hide syntax

[Sander Eikelenboom]

Monday, July 30, 2012, 9:00:06 PM, you wrote:

> On Sat, May 19, 2012 at 10:46:15AM +0200, Sander Eikelenboom wrote:
>> Hi Konrad,
>> 
>> The syntax for specifying the devices for pciback to hide is "bus:device.function".
>> While thinking about cooking up a patch to be able to use a "*" wildcard for the function, i was wondering if not hiding all functions of a device is feasible at all.
>> 
>> For what I understand of PCI, function 0 is always required, so if I only hide function 0, i can't use the other functions in dom0, since those functions would require a function 0, which is hidden.
>> 
>> So would it be more logical to drop/ignore the function from the BDF, and always hide all functions from a device ?

> That might run afoul of the SR-IOV virtual devices. They (when loaded) provide a fake
> bus:device:function, where the device is port (so if the SR-IOV card has two
> jacks, you get 00 and 01), and the function is for the amount of VFs it can make.
> On the Intel SR-IOV NIC with 'igbvf.max_vfs=7' I end up with 14 PCI devices, where
> the function bear no resemblence to each other (and can be passed in different guests).

> The PCI restriction I know of is if the device is behind a bridge. The issue here
> is that .. well, you could pass in a different function to a different guest, but
> one guest's hardware device could listen on the other guests' function. It would
> require tweaking the driver to dump the contents of some registers and some deep
> hacking, but that is the security issue with that.

Hmm that would mean there are three possibilities:
1) Accept a Wildcard syntax like "bus:device.*", which would mean hide all functions of device.
2) Accept not providing the function as a wildcard "bus:device", would mean hide all functions of device.

3) Do nothing, the gained overview on grub lines isn't worth the effort :-)

>> 
>> --
>> Regards,
>> 
>> Sander
>> 




-- 
Best regards,
 Sander                            mailto:linux@eikelenboom.it

Re: xen-pciback.hide syntax

[Konrad Rzeszutek Wilk]

On Mon, Jul 30, 2012 at 09:47:41PM +0200, Sander Eikelenboom wrote:
> Monday, July 30, 2012, 9:00:06 PM, you wrote:
> 
> > On Sat, May 19, 2012 at 10:46:15AM +0200, Sander Eikelenboom wrote:
> >> Hi Konrad,
> >> 
> >> The syntax for specifying the devices for pciback to hide is "bus:device.function".
> >> While thinking about cooking up a patch to be able to use a "*" wildcard for the function, i was wondering if not hiding all functions of a device is feasible at all.
> >> 
> >> For what I understand of PCI, function 0 is always required, so if I only hide function 0, i can't use the other functions in dom0, since those functions would require a function 0, which is hidden.
> >> 
> >> So would it be more logical to drop/ignore the function from the BDF, and always hide all functions from a device ?
> 
> > That might run afoul of the SR-IOV virtual devices. They (when loaded) provide a fake
> > bus:device:function, where the device is port (so if the SR-IOV card has two
> > jacks, you get 00 and 01), and the function is for the amount of VFs it can make.
> > On the Intel SR-IOV NIC with 'igbvf.max_vfs=7' I end up with 14 PCI devices, where
> > the function bear no resemblence to each other (and can be passed in different guests).
> 
> > The PCI restriction I know of is if the device is behind a bridge. The issue here
> > is that .. well, you could pass in a different function to a different guest, but
> > one guest's hardware device could listen on the other guests' function. It would
> > require tweaking the driver to dump the contents of some registers and some deep
> > hacking, but that is the security issue with that.
> 
> Hmm that would mean there are three possibilities:
> 1) Accept a Wildcard syntax like "bus:device.*", which would mean hide all functions of device.

Which in this context actually makes sense. You probably don't want to use the VF's in
your host.

> 2) Accept not providing the function as a wildcard "bus:device", would mean hide all functions of device.

<nods>.
> 
> 3) Do nothing, the gained overview on grub lines isn't worth the effort :-)

Heh!

I think I like 2).

Re: xen-pciback.hide syntax

[Sander Eikelenboom]

Hello Konrad,

Tuesday, July 31, 2012, 5:25:58 PM, you wrote:

> On Mon, Jul 30, 2012 at 09:47:41PM +0200, Sander Eikelenboom wrote:
>> Monday, July 30, 2012, 9:00:06 PM, you wrote:
>> 
>> > On Sat, May 19, 2012 at 10:46:15AM +0200, Sander Eikelenboom wrote:
>> >> Hi Konrad,
>> >> 
>> >> The syntax for specifying the devices for pciback to hide is "bus:device.function".
>> >> While thinking about cooking up a patch to be able to use a "*" wildcard for the function, i was wondering if not hiding all functions of a device is feasible at all.
>> >> 
>> >> For what I understand of PCI, function 0 is always required, so if I only hide function 0, i can't use the other functions in dom0, since those functions would require a function 0, which is hidden.
>> >> 
>> >> So would it be more logical to drop/ignore the function from the BDF, and always hide all functions from a device ?
>> 
>> > That might run afoul of the SR-IOV virtual devices. They (when loaded) provide a fake
>> > bus:device:function, where the device is port (so if the SR-IOV card has two
>> > jacks, you get 00 and 01), and the function is for the amount of VFs it can make.
>> > On the Intel SR-IOV NIC with 'igbvf.max_vfs=7' I end up with 14 PCI devices, where
>> > the function bear no resemblence to each other (and can be passed in different guests).
>> 
>> > The PCI restriction I know of is if the device is behind a bridge. The issue here
>> > is that .. well, you could pass in a different function to a different guest, but
>> > one guest's hardware device could listen on the other guests' function. It would
>> > require tweaking the driver to dump the contents of some registers and some deep
>> > hacking, but that is the security issue with that.
>> 
>> Hmm that would mean there are three possibilities:
>> 1) Accept a Wildcard syntax like "bus:device.*", which would mean hide all functions of device.

> Which in this context actually makes sense. You probably don't want to use the VF's in
> your host.

In my use cases i always hide all functions, and since my usb controllers have 7 functions, that leads to quite some long lines.

>> 2) Accept not providing the function as a wildcard "bus:device", would mean hide all functions of device.

> <nods>.
>> 
>> 3) Do nothing, the gained overview on grub lines isn't worth the effort :-)

> Heh!

> I think I like 2).

I think that would be the most simple and straightforward to implement, the only thing is that the .cfg files seem to use the "bus:device.*" scheme ...
Don't know if there are any other related cmd options for the kernel that use a certain syntax that could be preferred ?

--

Sander

Re: xen-pciback.hide syntax

[Konrad Rzeszutek Wilk]

On Tue, Jul 31, 2012 at 05:40:14PM +0200, Sander Eikelenboom wrote:
> Hello Konrad,
> 
> Tuesday, July 31, 2012, 5:25:58 PM, you wrote:
> 
> > On Mon, Jul 30, 2012 at 09:47:41PM +0200, Sander Eikelenboom wrote:
> >> Monday, July 30, 2012, 9:00:06 PM, you wrote:
> >> 
> >> > On Sat, May 19, 2012 at 10:46:15AM +0200, Sander Eikelenboom wrote:
> >> >> Hi Konrad,
> >> >> 
> >> >> The syntax for specifying the devices for pciback to hide is "bus:device.function".
> >> >> While thinking about cooking up a patch to be able to use a "*" wildcard for the function, i was wondering if not hiding all functions of a device is feasible at all.
> >> >> 
> >> >> For what I understand of PCI, function 0 is always required, so if I only hide function 0, i can't use the other functions in dom0, since those functions would require a function 0, which is hidden.
> >> >> 
> >> >> So would it be more logical to drop/ignore the function from the BDF, and always hide all functions from a device ?
> >> 
> >> > That might run afoul of the SR-IOV virtual devices. They (when loaded) provide a fake
> >> > bus:device:function, where the device is port (so if the SR-IOV card has two
> >> > jacks, you get 00 and 01), and the function is for the amount of VFs it can make.
> >> > On the Intel SR-IOV NIC with 'igbvf.max_vfs=7' I end up with 14 PCI devices, where
> >> > the function bear no resemblence to each other (and can be passed in different guests).
> >> 
> >> > The PCI restriction I know of is if the device is behind a bridge. The issue here
> >> > is that .. well, you could pass in a different function to a different guest, but
> >> > one guest's hardware device could listen on the other guests' function. It would
> >> > require tweaking the driver to dump the contents of some registers and some deep
> >> > hacking, but that is the security issue with that.
> >> 
> >> Hmm that would mean there are three possibilities:
> >> 1) Accept a Wildcard syntax like "bus:device.*", which would mean hide all functions of device.
> 
> > Which in this context actually makes sense. You probably don't want to use the VF's in
> > your host.
> 
> In my use cases i always hide all functions, and since my usb controllers have 7 functions, that leads to quite some long lines.
> 
> >> 2) Accept not providing the function as a wildcard "bus:device", would mean hide all functions of device.
> 
> > <nods>.
> >> 
> >> 3) Do nothing, the gained overview on grub lines isn't worth the effort :-)
> 
> > Heh!
> 
> > I think I like 2).
> 
> I think that would be the most simple and straightforward to implement, the only thing is that the .cfg files seem to use the "bus:device.*" scheme ...
> Don't know if there are any other related cmd options for the kernel that use a certain syntax that could be preferred ?
> 

So Jan implemented this and it is in v3.7.

Re: xen-pciback.hide syntax

[Sander Eikelenboom]

Friday, October 19, 2012, 9:35:24 PM, you wrote:

> On Tue, Jul 31, 2012 at 05:40:14PM +0200, Sander Eikelenboom wrote:
>> Hello Konrad,
>> 
>> Tuesday, July 31, 2012, 5:25:58 PM, you wrote:
>> 
>> > On Mon, Jul 30, 2012 at 09:47:41PM +0200, Sander Eikelenboom wrote:
>> >> Monday, July 30, 2012, 9:00:06 PM, you wrote:
>> >> 
>> >> > On Sat, May 19, 2012 at 10:46:15AM +0200, Sander Eikelenboom wrote:
>> >> >> Hi Konrad,
>> >> >> 
>> >> >> The syntax for specifying the devices for pciback to hide is "bus:device.function".
>> >> >> While thinking about cooking up a patch to be able to use a "*" wildcard for the function, i was wondering if not hiding all functions of a device is feasible at all.
>> >> >> 
>> >> >> For what I understand of PCI, function 0 is always required, so if I only hide function 0, i can't use the other functions in dom0, since those functions would require a function 0, which is hidden.
>> >> >> 
>> >> >> So would it be more logical to drop/ignore the function from the BDF, and always hide all functions from a device ?
>> >> 
>> >> > That might run afoul of the SR-IOV virtual devices. They (when loaded) provide a fake
>> >> > bus:device:function, where the device is port (so if the SR-IOV card has two
>> >> > jacks, you get 00 and 01), and the function is for the amount of VFs it can make.
>> >> > On the Intel SR-IOV NIC with 'igbvf.max_vfs=7' I end up with 14 PCI devices, where
>> >> > the function bear no resemblence to each other (and can be passed in different guests).
>> >> 
>> >> > The PCI restriction I know of is if the device is behind a bridge. The issue here
>> >> > is that .. well, you could pass in a different function to a different guest, but
>> >> > one guest's hardware device could listen on the other guests' function. It would
>> >> > require tweaking the driver to dump the contents of some registers and some deep
>> >> > hacking, but that is the security issue with that.
>> >> 
>> >> Hmm that would mean there are three possibilities:
>> >> 1) Accept a Wildcard syntax like "bus:device.*", which would mean hide all functions of device.
>> 
>> > Which in this context actually makes sense. You probably don't want to use the VF's in
>> > your host.
>> 
>> In my use cases i always hide all functions, and since my usb controllers have 7 functions, that leads to quite some long lines.
>> 
>> >> 2) Accept not providing the function as a wildcard "bus:device", would mean hide all functions of device.
>> 
>> > <nods>.
>> >> 
>> >> 3) Do nothing, the gained overview on grub lines isn't worth the effort :-)
>> 
>> > Heh!
>> 
>> > I think I like 2).
>> 
>> I think that would be the most simple and straightforward to implement, the only thing is that the .cfg files seem to use the "bus:device.*" scheme ...
>> Don't know if there are any other related cmd options for the kernel that use a certain syntax that could be preferred ?
>> 

> So Jan implemented this and it is in v3.7.


Yes i saw it :-)
Thx !