[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [libvirt] [PATCH 00/12 v6] Unprivleged SG_IO support

On 2012年12月13日 01:18, Daniel P. Berrange wrote:
On Tue, Dec 11, 2012 at 09:37:17PM +0800, Osier Yang wrote:
As a result of RFC [1], this implements the unprivleged SG_IO

v4 - v5:
    * Per discussion in [2], this set uses a hash table to
      store the shared disk's info. See 1/12 for more

Osier Yang (12):
   qemu: Add a hash table for the shared disks
   docs: Add docs and rng schema for new XML cdbfilter
   conf: Parse and format the new XML tag cdbfilter
   util: Prepare helpers for unpriv_sgio setting
   qemu: Manage disk's unpriv_sgio in domain lifecyle
   qemu: Do not restore the sysfs unpriv_sgio if the disk is being
   qemu: Error out when domain starting if the cdbfilter setting
   qemu: Set unpriv_sgio when attaching disk
   qemu: Restore unpriv_sgio when detaching disk
   qemu: Error out if the shared disk conf conflicts with others when
   qemu: Do not restore unpriv_sgio when detaching disk if it's still
   conf: Save disk's original unpriv_sgio state into status XML

IMHO this series would be a hell of alot simpler if we just
didn't bother restoring the original CBD value. The value only
really matters when VMs are actually running in any case

Yeah, that will be a lot simpler if we don't care about
restoring the orignal unpriv_sgio. And it can avoid many
risks. It basicly follows the non-agreement in [1]:

When libvirtd starting, set the sysfs knob "unpriv_sgio" of
the devices listed to 1, and 0 when libvirtd exists.

But now I doubt about this after I went that way forward,
especially it makes no sense after a libvirtd restarting.

Should we avoid the restoring?


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]