From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: [PATCH] pci-assign: Do not reset the device unless the kernel supports it Date: Tue, 07 Jun 2011 11:06:53 +0300 Message-ID: <4DEDDC1D.7000905@redhat.com> References: <4DED470F.4020203@web.de> <1307396894.5901.5.camel@x201> <4DED4EDA.80803@web.de> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Alex Williamson , Marcelo Tosatti , kvm To: Jan Kiszka Return-path: Received: from mx1.redhat.com ([209.132.183.28]:64292 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751647Ab1FGIG6 (ORCPT ); Tue, 7 Jun 2011 04:06:58 -0400 In-Reply-To: <4DED4EDA.80803@web.de> Sender: kvm-owner@vger.kernel.org List-ID: On 06/07/2011 01:04 AM, Jan Kiszka wrote: > On 2011-06-06 23:48, Alex Williamson wrote: > > On Mon, 2011-06-06 at 23:30 +0200, Jan Kiszka wrote: > >> From: Jan Kiszka > >> > >> At least kernels 2.6.38 and 2.6.39 do not properly support issuing a > >> reset on an assigned device and corrupt its config space. Prevent > >> this by checking for a host kernel with the required support, tagged by > >> the to-be-introduced KVM_CAP_DEVICE_RESET. > > > > Wouldn't it be easier just to revert ed78661f in 2.6.39 stable? I guess > > we don't have an option to do that for .38 since stable is done there, > > but there are also some intel-iommu breakages that won't make stable for > > that release. It seems like the userspace invoked reset resolves known, > > demonstrable issues of devices continuing to DMA into guest memory while > > ed78661f is mostly a theoretical change. > > Easier would be this patch. But I don't mind reverting the problematic > commit in 39, whatever is preferred. We should just resolve the issue > finally. Kernel problems should be solved in the kernel (with exceptions of course, but don't see the need here). -- I have a truly marvellous patch that fixes the bug which this signature is too narrow to contain.