From mboxrd@z Thu Jan 1 00:00:00 1970 From: Alex Williamson Subject: Re: [PATCH] kvm: device-assignment: Add PCI option ROM support Date: Fri, 19 Jun 2009 07:44:40 -0600 Message-ID: <1245419080.17330.98.camel@bling> References: <20090615162815.4830.38216.stgit@host.lart> <200906181330.57935.sheng.yang@intel.com> <1245342521.17330.65.camel@bling> <200906191527.53430.sheng.yang@intel.com> Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit Cc: "kvm@vger.kernel.org" To: "Yang, Sheng" Return-path: Received: from g1t0027.austin.hp.com ([15.216.28.34]:29472 "EHLO g1t0027.austin.hp.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752799AbZFSNol (ORCPT ); Fri, 19 Jun 2009 09:44:41 -0400 In-Reply-To: <200906191527.53430.sheng.yang@intel.com> Sender: kvm-owner@vger.kernel.org List-ID: On Fri, 2009-06-19 at 15:27 +0800, Yang, Sheng wrote: > On Friday 19 June 2009 00:28:41 Alex Williamson wrote: > > The one oddity I noticed is that even when the enable bit is clear, the > > guest can read the ROM. I don't know that this is actually illegal, vs > > returning zeros or ones though. It seems like maybe the generic PCI > > code isn't tracking the enable bit. I think that's an independent > > problem from this patch though. Thanks, > > That should be fine. I've taken a look at code, seems Linux kernel set > enable_bit when someone begin to read rom, and copy rom to buffer, then unmap > the rom. So the rom can be read when enable bit clear. For this testing, I used an mmap of the ROM address though, so the kernel caching shouldn't have been involved. It looks to me like the problem is that the map function provided via pci_register_io_region() only knows how to create mappings, not tear them down. I think maybe pci_update_mappings() should still call the map_func when new_addr is -1 to let the io space drive shutdown the mapping. As it is, once we setup the mapping, it lives until something else happens to overlap it, regardless of the state of the PCI BAR. Thanks, Alex