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

[Osier Yang]

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
>> support.
>>
>> v4 - v5:
>>     * Per discussion in [2], this set uses a hash table to
>>       store the shared disk's info. See 1/12 for more
>>       details.
>>
>> 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
>>      shared
>>    qemu: Error out when domain starting if the cdbfilter setting
>>      conflicts
>>    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
>>      attaching
>>    qemu: Do not restore unpriv_sgio when detaching disk if it's still
>>      shared
>>    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?

Regards,
Osier