From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Yang, Sheng" Subject: Re: [PATCH] kvm: device-assignment: Add PCI option ROM support Date: Fri, 19 Jun 2009 15:27:53 +0800 Message-ID: <200906191527.53430.sheng.yang@intel.com> References: <20090615162815.4830.38216.stgit@host.lart> <200906181330.57935.sheng.yang@intel.com> <1245342521.17330.65.camel@bling> Mime-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Cc: "kvm@vger.kernel.org" To: Alex Williamson Return-path: Received: from mga11.intel.com ([192.55.52.93]:39989 "EHLO mga11.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753304AbZFSH2Y (ORCPT ); Fri, 19 Jun 2009 03:28:24 -0400 In-Reply-To: <1245342521.17330.65.camel@bling> Content-Disposition: inline Sender: kvm-owner@vger.kernel.org List-ID: On Friday 19 June 2009 00:28:41 Alex Williamson wrote: > On Thu, 2009-06-18 at 13:30 +0800, Yang, Sheng wrote: > > On Tuesday 16 June 2009 00:29:17 Alex Williamson wrote: > > > The PCI code already knows about option ROMs, so we just need to > > > mmap some space for it, load it with a copy of the contents, and > > > complete the plubming to the generic code. > > > > > > With this a Linux guest can get access to the ROM contents via > > > /sys/bus/pci/devices//rom. This might also enable the BIOS > > > to execute ROMs by loading them dynamically from the device > > > rather than hoping they all fit into RAM. > > > > The patch looks fine. One question: if guest write to the ROM, I think > > the guest would be killed for QEmu would receive a SIGSEGV? I am not sure > > if it's too severe... > > Hi Sheng, > > Good thought. I tested this with a simple program that mmaps the ROM > address from /dev/mem and tries to write to it (using setpci to enable > the ROM). The results are a little surprising. On the host, writing to > the ROM causes an NMI and the system dies. On the KVM guest, the write > is happily discarded, neither segfaulting from the mprotect nor > affecting the contents of the ROM. So it seems that something above my > mprotect is discarding the write, and if we did hit it, a qemu segfault > isn't that far from what happens on bare metal. > Oh, that's good. :) > 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. -- regards Yang, Sheng > > Alex