From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MFAoG-0002rd-82 for qemu-devel@nongnu.org; Fri, 12 Jun 2009 13:45:00 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MFAoB-0002rF-Ld for qemu-devel@nongnu.org; Fri, 12 Jun 2009 13:44:59 -0400 Received: from [199.232.76.173] (port=37122 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MFAoB-0002rC-H4 for qemu-devel@nongnu.org; Fri, 12 Jun 2009 13:44:55 -0400 Received: from mail-bw0-f223.google.com ([209.85.218.223]:43012) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MFAo8-00053Y-Ef for qemu-devel@nongnu.org; Fri, 12 Jun 2009 13:44:55 -0400 Received: by bwz23 with SMTP id 23so2025488bwz.34 for ; Fri, 12 Jun 2009 10:44:41 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <1244827883.26769.44.camel@blaa> References: <20090610182227.GN28601@redhat.com> <20090610192702.GH7416@shareable.org> <1244796209.16425.20.camel@blaa> <4A326B5C.5010501@codemonkey.ws> <1244821292.30522.56.camel@blaa> <4A327E4A.7010300@codemonkey.ws> <1244825303.26769.19.camel@blaa> <4A328991.3040006@codemonkey.ws> <1244827883.26769.44.camel@blaa> Date: Fri, 12 Jun 2009 20:44:41 +0300 Message-ID: Subject: Re: Configuration vs. compat hints [was Re: [Qemu-devel] [PATCHv3 03/13] qemu: add routines to manage PCI capabilities] From: Blue Swirl Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Mark McLoughlin Cc: Carsten Otte , kvm@vger.kernel.org, "Michael S. Tsirkin" , Glauber Costa , Rusty Russell , qemu-devel@nongnu.org, virtualization@lists.linux-foundation.org, Christian Borntraeger , Paul Brook , Avi Kivity On 6/12/09, Mark McLoughlin wrote: > On Fri, 2009-06-12 at 12:00 -0500, Anthony Liguori wrote: > > Mark McLoughlin wrote: > > > So, when libvirt creates a guest for the first time, it makes a copy of > > > the device tree and continues to use that even if qemu is upgraded. > > > That's enough to ensure compat is retained for all built-in devices. > > > > > > However, in order to retain compat for that SCSI device (e.g. ensuring > > > the PCI address doesn't change as other devices are added an removed), > > > we're back to the same problem ... either: > > > > > > 1) Use '-drive file=foo.img,if=scsi,pci_addr=foo'; in order to figure > > > out what address to use, libvirt would need to query qemu for what > > > address was originally allocated to device or it would do all the > > > PCI address allocation itself ... or: > > > > > > 2) Don't use the command line, instead get a dump of the entire > > > device tree (including the SCSI device) - if the device is to be > > > removed or modified in future, libvirt would need to modify the > > > device tree > > > > > > The basic problem would be that the command line config would have very > > > limited ability to override the device tree config. > > > > > > > After libvirt has done -drive file=foo... it should dump the machine > > config and use that from then on. > > Right - libvirt then wouldn't be able to avoid the complexity of merging > any future changes into the dumped machine config. > > > To combined to a single thread... > > > How do you add a new attribute to the device tree and, when a supplied > > > device tree lacking said attribute, distinguish between a device tree > > > from an old version of qemu (i.e. use the old default) and a partial > > > device tree from the VM manager (i.e. use the new default) ? > > > > > > > Please define "attribute". I don't follow what you're asking. > > e.g. a per-device "enable MSI support" flag. > > If qemu is supplied with a device tree that lacks that flag, does it > enable or disable MSI? > > Enable by default is bad - it could be a device tree dumped from an old > version of qemu, so compat would be broken. > > Disable by default is bad - it could be a simple device tree supplied by > the user, and the latest features are wanted. > > Maybe we want a per-device "this is a complete device description" flag > and if anything is missing from a supposedly complete description, the > old defaults would be used. A config dumped from qemu would have this > flag set, a config generated by libvirt would not have the flag. If the device has different behavior or different properties from guest perspective compared to the old device, it should get a new device type so that you could specify in the device tree either the old device or the new one. Flags won't help in the long term.