From: Gordan Bobic <gordan@bobich.net>
To: George Dunlap <george.dunlap@eu.citrix.com>
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:37:35 +0100 [thread overview]
Message-ID: <af8d8ab38c4a11e98bc0dbbed9335ad1@mail.shatteredsilicon.net> (raw)
In-Reply-To: <51DD7DDD.5060401@eu.citrix.com>
On Wed, 10 Jul 2013 16:29:33 +0100, George Dunlap
<george.dunlap@eu.citrix.com> wrote:
> 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.
What about having a feature that upon parsing the config file modifies
the grub.conf or modprobe.d/xen-pciback.conf (depending on whether
xen-pciback is module or built in) and adds the required entries
for the device(s)?
Gordan
next prev parent reply other threads:[~2013-07-10 15:37 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
2013-07-10 15:37 ` Gordan Bobic [this message]
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=af8d8ab38c4a11e98bc0dbbed9335ad1@mail.shatteredsilicon.net \
--to=gordan@bobich.net \
--cc=Ian.Campbell@citrix.com \
--cc=Ian.Jackson@eu.citrix.com \
--cc=andrew.cooper3@citrix.com \
--cc=george.dunlap@eu.citrix.com \
--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).