From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Leendert van Doorn" Subject: RE: [PATCH][v2] kvm-userspace: Load PCI option ROMs Date: Sun, 4 Jan 2009 11:54:09 -0600 Message-ID: <010201c96e95$72cd4f10$5867ed30$@org> 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> <4960F1D2.4080600@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Cc: "'Shan, Haitao'" , "'Liu, Kechao'" , To: "'Avi Kivity'" , "'Kevin O'Connor'" Return-path: Received: from faraway.paramecium.org ([168.100.175.242]:51096 "EHLO faraway.paramecium.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751329AbZADRxR (ORCPT ); Sun, 4 Jan 2009 12:53:17 -0500 In-Reply-To: <4960F1D2.4080600@redhat.com> Content-Language: en-us Sender: kvm-owner@vger.kernel.org List-ID: Avi wrote: > 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? At IBM we had many discussions about what precisely constitutes a GPL boundary. Especially when you are examining internal BIOS data structures (which most kernels do when accessing the BIOS). In the end Legal advised us that LGPL was ok and GPL was not. This was all in the context of v2 so things may have changed with v3. I don't want this to turn into a GPL versus LGPL argument because I'm not a lawyer either. If the KVM project picks up SEABIOS I'm all for it because it is much cleaner and easier to maintain. >> 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. I'm already providing the hints, but you are proposing that the default behavior for the BIOS should be to allocate BARs and when given a flag it should try to preserve the host BAR mappings. I can do that. >> Of course, my goal is to run unmodified BIOS/drivers. You could always >> change the drivers. > > Not Windows drivers. Well, at least I have a fighting chance to change the ATI windows drivers :-) Leendert