From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: [PATCH][v2] kvm-userspace: Load PCI option ROMs Date: Sun, 04 Jan 2009 19:28:50 +0200 Message-ID: <4960F1D2.4080600@redhat.com> References: <49588A4A.8020902@redhat.com> <49589D21.9070201@redhat.com> <61563CE63B4F854986A895DA7AD3C177044E6ECA@pdsmsx502.ccr.corp.intel.com> <495A4367.6050203@redhat.com> <61563CE63B4F854986A895DA7AD3C177044E7098@pdsmsx502.ccr.corp.intel.com> <495B3B43.2090200@redhat.com> <61563CE63B4F854986A895DA7AD3C177044E7306@pdsmsx502.ccr.corp.intel.com> <00e301c96e20$35c2fdb0$a148f910$@org> <49608EBC.2090409@redhat.com> <010101c96e8f$a42d4a20$ec87de60$@org> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "'Shan, Haitao'" , "'Liu, Kechao'" , kvm@vger.kernel.org To: Leendert van Doorn , "Kevin O'Connor" Return-path: Received: from mx2.redhat.com ([66.187.237.31]:35876 "EHLO mx2.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755470AbZADR2z (ORCPT ); Sun, 4 Jan 2009 12:28:55 -0500 In-Reply-To: <010101c96e8f$a42d4a20$ec87de60$@org> Sender: kvm-owner@vger.kernel.org List-ID: Leendert van Doorn wrote: > Avi wrote: > > >> This is worrying as it will cause us to diverge from upstream bochs bios. >> > > Yep. I'll create a less invasive patch. I've been looking at SEABIOS which > seems a much better alternative but the GPLv3 license worries me, especially > when you have proprietary guests that calls back into it. > Surely, the BIOS call interface is a GPL boundary, just like the Linux syscall interface. Kevin, is that not the case? If it is a GPL interface, can you add an explicit exception to make it clear? >> Can you elaborate? Since we're running the card's bios again, won't it >> initialize correctly? >> > > The problem is that the device-assignment code doesn't update the cards > BARs, it just emulates them and maps the guest BARs onto the correct host > BARs. Unfortunately, the graphics card has undocumented interfaces for > obtaining the memory regions (faster than a full PCI lookup) and they of > course return the host mappings as opposed to the guest mappings. > !@#$%^. > My first attempt was to implement a state machine that would emulate these > interfaces and rewrite them but this got pretty ugly pretty fast. No doubt. And it wouldn't work for cards where we don't know about these interfaces, or where we directly assign the mmio regions that implement these interfaces. > Ensuring > the same mappings was much cleaner. > With a switch, please. Default behaviour should be to virtualize. One way to implement it is to pass pci devfn -> BAR hints through the firmware interface. This way you can choose which BARs to place where, and where to allow the default placement. > Of course, my goal is to run unmodified BIOS/drivers. You could always > change the drivers. > > Not Windows drivers. > I'll clean things up and resubmit. > Thanks. -- error compiling committee.c: too many arguments to function