All of lore.kernel.org
 help / color / mirror / Atom feed
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Sander Eikelenboom <linux@eikelenboom.it>
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: xen-pciback.hide syntax
Date: Tue, 31 Jul 2012 11:25:58 -0400	[thread overview]
Message-ID: <20120731152558.GM4789@phenom.dumpdata.com> (raw)
In-Reply-To: <1811240070.20120730214741@eikelenboom.it>

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

  reply	other threads:[~2012-07-31 15:25 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-05-19  8:46 xen-pciback.hide syntax Sander Eikelenboom
2012-07-30 19:00 ` Konrad Rzeszutek Wilk
2012-07-30 19:47   ` Sander Eikelenboom
2012-07-31 15:25     ` Konrad Rzeszutek Wilk [this message]
2012-07-31 15:40       ` Sander Eikelenboom
2012-10-19 19:35         ` Konrad Rzeszutek Wilk
2012-10-19 19:48           ` Sander Eikelenboom

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=20120731152558.GM4789@phenom.dumpdata.com \
    --to=konrad.wilk@oracle.com \
    --cc=linux@eikelenboom.it \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.