On Wed, 2011-02-16 at 08:01 -0700, Alex Williamson wrote: > On Wed, 2011-02-16 at 11:10 +0200, Avi Kivity wrote: > > On 02/16/2011 11:05 AM, Hao, Xudong wrote: > > > Hi, all, > > > This is KVM test result against kvm.git > > > a685b38e272587e644fedd37269ddb82df21c052, and qemu-kvm.git > > > 671d89d6411655bb4f8058ce6eb86bb0bb8ec978. > > > > > > Currently qemu-kvm can build successfully on RHEL5, and Qcow image create > > > failure issue also got fixed, our nightly testing resumed. One VT-d > > > device assignment issue opened on latest KVM. > > > > > > New issue: > > > 1. [VT-d] VT-d device passthrough fail to guest > > > https://bugzilla.kernel.org/show_bug.cgi?id=29232 > > > > > Extremely reproducible. Looks like it's a result of this kernel change: > > commit 47970b1b2aa64464bc0a9543e86361a622ae7c03 > Author: Chris Wright <chr...@sous-sol.org> > Date: Thu Feb 10 15:58:56 2011 -0800 > > pci: use security_capable() when checking capablities during config space > re > > Eric Paris noted that commit de139a3 ("pci: check caps from sysfs file > open to read device dependent config space") caused the capability check > to bypass security modules and potentially auditing. Rectify this by > calling security_capable() when checking the open file's capabilities > for config space reads. > > Reported-by: Eric Paris <epa...@redhat.com> > Signed-off-by: Chris Wright <chr...@sous-sol.org> > Signed-off-by: James Morris <jmor...@namei.org> > > Chris, why isn't this working for us? Thanks,
Ah, I see now that this has already been fixed. The above commit was reverted in f00eaeea7a42b5ea327e9ce8839cb0b53d3bdb4e and a corrected version applied in a628e7b87e100befac9702aa0c3b9848a7685e49. So it should be fixed on the next kvm.git merge. Thanks, Alex -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
