[libvirt] [PATCH 2/3] New 'permissive' attribute for hostdev

[Daniel P. Berrange]

On Mon, Dec 21, 2009 at 08:43:14PM +0100, Jiri Denemark wrote:
> > > When it is set to 'yes', some check whether a device is safe to be
> > > assigned to a guest will be weakened.
> > 
> > I think this is a rather ill-defined concept to be adding the guest XML,
> > since there are many checks done for assignment, and this is only impacting
> > one of them. Whether to allow a device beind a non-ACS enable switch to be
> > used in a VM has implications beyond just the one VM it is assigned to. Thus
> > is strikes me that the decision as to whether to allow use of devices behind
> > non-ACS switches should be a host level attribute. eg a config item in the
> > /etc/qemu/qemu.conf file
> 
> This was the idea behind:
> 
>      What remains to be implemented is the logic of the whitelist that you
> mention in comments #2 and #3.  To be honest, I don't love this idea of the
> whitelist; not only will we have to maintain some kind of table, we will need
> to make sure the table is up-to-date every time new hardware comes out.  It
> also breaks the security of the setup without letting the user know about
> (because it is on a magic whitelist that the user probably won't know anything
> about).
> 
>      I have an alternate proposal.  What if we added a new <permissive/> tag
> to the libvirt XML for device assignment?  In the normal case, we wouldn't
> allow *any* passthrough of devices behind non-ACS switches.  However, if the
> user knows what they are doing, and they want to take this risk, they can add
> the <permissive/> tag to the XML, in which case it would allow the assignment
> to happen.  This can even be used pretty successfully in virt-manager; it just
> needs to catch the appropriate exception from the first assignment, pop-up
> "This is dangerous because of non-ACS, blah, blah.  Are you sure?", and then
> re-do the assignment with the <permissive/> tag.

I think this is a pretty horrible user experiance, since the first thought
will be 'what on earth is ACS?', closely followed by clicking 'OK'. There are
also already many other restrictions on PCI device assignment, such as the
availabilty of FLR, availablity of PM-reset, even VT-d itself, and we don't
have user facing tunables to turn off those checks. These are all low-level
hardware details that users really aren't equipped to understand - even
most of us developers don't really understand them. 

I don't much like the idea of having to maintain a whitelist of devices
that are safe to use, but pushing the problem off to the end user via 
a config option/confirm dialog is just avoiding the issue. 

Regards,
Daniel
-- 
|: Red Hat, Engineering, London   -o-   http://people.redhat.com/berrange/ :|
|: http://libvirt.org  -o-  http://virt-manager.org  -o-  http://ovirt.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505  -o-  F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|