xen-devel.lists.xenproject.org archive mirror
 help / color / mirror / Atom feed
From: George Dunlap <george.dunlap@eu.citrix.com>
To: Gordan Bobic <gordan@bobich.net>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	xen-devel@lists.xen.org
Subject: Re: RFC: Automatically making a PCI device assignable in the config file
Date: Wed, 10 Jul 2013 16:29:33 +0100	[thread overview]
Message-ID: <51DD7DDD.5060401@eu.citrix.com> (raw)
In-Reply-To: <b336b976a2b8851e0a975563344a62d1@mail.shatteredsilicon.net>

On 10/07/13 16:12, Gordan Bobic wrote:
> On Wed, 10 Jul 2013 15:45:49 +0100, George Dunlap 
> <george.dunlap@eu.citrix.com> wrote:
>> On 10/07/13 14:55, Ian Jackson wrote:
>>> George Dunlap writes ("Re: [Xen-devel] RFC: Automatically making a 
>>> PCI device assignable in the config file"):
>>>> Auto-seizing is fairly dangerous; you could easily accidentally 
>>>> yank out
>>>> the ethernet card, or even the disk that dom0 is using.  I really 
>>>> think
>>>> it should have to be enabled on a device-by-device basis.
>>> I don't think this makes any sense.
>>>
>>> In practice you are saying that in order to avoid mistakes, the local
>>> admin must provide the BDF of the device to be passed through in two
>>> separate places.
>>
>> That's not what I had in mind; what I had in mind was something like 
>> this:
>>
>> pci = [ '08:04.1,seize=1' ]
>>
>> Or alternately:
>>
>> xl pci-attach h0 08:04.1,seize=1
>>
>> One could also imagine having something in xl.conf like the following:
>>
>> pci.autoseize = [ '08:04.1','01:00.0' ]
>>
>> In this case you wouldn't be simply copy and pasting, because you'd
>> probably have different domains handling each device.  But in any
>> case, this was just exploring the alternatives -- I don't think that's
>> the best thing to do.
>>
>>> But that doesn't actually help.  If this is all properly documented
>>> and so forth (ie, if the admin has a smooth experience and doesn't
>>> trip over having dailed to "seize" the device), they will just
>>> cut-and-paste the same value into both places in the config.
>>>
>>> They will also mutter under their breath to ask why this is
>>> necessary...
>>
>> If someone can accidentally type "xl pci-attach 08:04.0" instead of
>> "xl pci-attach 08.04.1" and suddenly completely lose their network
>> connectivity (or yank their hard drive out), then I think they'll
>> appreciate it.
>>
>> In any case, at the moment it's much worse: you have to either
>> scriptwise run "xl pci-assignable-add" a device, or add an exclusion
>> on the Linux commandline in grub.  So far I'm the only person I know
>> who has complained about it. :-)
>
> This would be an awesome feature, but success can be mixed. My
> experience is that Nvidia drivers (as one example, I'm sure there
> are others) don't handle device detaching very gracefully. ACS
> might help but I have no means of testing
> that at the moment. So ultimately, you still have to either
> exclude at least some devices from grub (if
> xen-pciback is built in) or in modprobe.d (attach device to
> pciback in driver pre-install). I'm not sure what can be
> done about this considering we are talking about 3rd
> party binary drivers. :(

Yes, unfortunately we'll always have to have the fallback for devices 
that don't play well with being re-assigned.  But I my very limited 
experience with network cards gives me some hope that at least for many 
devices for which driver domains might be in use, the auto-reassign 
thing will be useful in a number of cases.

  -George

  reply	other threads:[~2013-07-10 15:29 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-07-05 11:01 RFC: Automatically making a PCI device assignable in the config file George Dunlap
2013-07-05 13:39 ` Andrew Cooper
2013-07-05 13:45   ` George Dunlap
2013-07-05 13:48     ` Andrew Cooper
2013-07-05 13:52       ` George Dunlap
2013-07-08 19:23         ` Konrad Rzeszutek Wilk
2013-07-09 12:52           ` George Dunlap
2013-07-09 14:25             ` Konrad Rzeszutek Wilk
2013-07-09 16:38               ` George Dunlap
2013-07-10 13:45                 ` Stefano Stabellini
2013-07-10 13:49               ` Stefano Stabellini
2013-07-10 13:55     ` Ian Jackson
2013-07-10 14:45       ` George Dunlap
2013-07-10 15:12         ` Gordan Bobic
2013-07-10 15:29           ` George Dunlap [this message]
2013-07-10 15:37             ` Gordan Bobic
2013-07-10 13:53 ` Ian Jackson
2013-07-10 14:48   ` George Dunlap
2013-07-11 11:35     ` David Vrabel
2013-07-12  9:36       ` George Dunlap
2013-07-12  9:55         ` David Vrabel
2013-07-12 10:32           ` George Dunlap
2013-07-12 13:10         ` Ian Jackson
2013-07-12 13:48           ` Konrad Rzeszutek Wilk
2013-07-12 14:43             ` Ian Jackson
2013-07-12 15:01               ` Konrad Rzeszutek Wilk
2013-07-12 15:09                 ` George Dunlap
2013-07-12 16:02                   ` Konrad Rzeszutek Wilk
2013-07-12 16:08                     ` George Dunlap
2013-07-12 14:44             ` 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=51DD7DDD.5060401@eu.citrix.com \
    --to=george.dunlap@eu.citrix.com \
    --cc=Ian.Campbell@citrix.com \
    --cc=Ian.Jackson@eu.citrix.com \
    --cc=andrew.cooper3@citrix.com \
    --cc=gordan@bobich.net \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).