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 XMLIMHO 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 -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list