From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:46512) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bn2WE-0004Ev-QF for qemu-devel@nongnu.org; Thu, 22 Sep 2016 07:50:23 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bn2WA-0006PD-KQ for qemu-devel@nongnu.org; Thu, 22 Sep 2016 07:50:21 -0400 Received: from mx1.redhat.com ([209.132.183.28]:43190) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bn2WA-0006P6-As for qemu-devel@nongnu.org; Thu, 22 Sep 2016 07:50:18 -0400 From: Markus Armbruster References: <877fa5aiu4.fsf@dusky.pond.sub.org> <6373e011-5068-b0ae-5672-e3704af556d9@redhat.com> <87h998nvf6.fsf@dusky.pond.sub.org> <6280ba63-cbe9-c2d3-ba8f-7de1369f059e@redhat.com> Date: Thu, 22 Sep 2016 13:50:15 +0200 In-Reply-To: <6280ba63-cbe9-c2d3-ba8f-7de1369f059e@redhat.com> (Paolo Bonzini's message of "Thu, 22 Sep 2016 11:22:45 +0200") Message-ID: <87vaxojgqw.fsf@dusky.pond.sub.org> MIME-Version: 1.0 Content-Type: text/plain Subject: Re: [Qemu-devel] [PATCH v11 0/8] Add a generic loader List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini Cc: Peter Maydell , Peter Crosthwaite , Christopher Covington , "qemu-devel@nongnu.org Developers" , Alistair Francis Paolo Bonzini writes: > On 22/09/2016 11:19, Markus Armbruster wrote: >>> > I think -device is okay for something that isn't a "backend" but is >>> > directly guest-visible. >> Well, the contents of a block device is just as guest-visible. We split >> the device in a frontend and a backend, and the contents comes from the >> backend. >> >> We traditionally don't model memory as a split device. Perhaps we >> should. Regardless of whether we actually do, "contents of a memory >> device that you need to create by some other means (explicit or >> implicit)" feels much more like -object than like -device to me. > > The closest precedents here are "-bios" (not an object at all), PCI ROMs > (a property points to the file), and "-pflash" (split into backend and > frontend, the frontend being a device). -pflash ARG is sugar for -drive if=pflash,file=ARG. Like all -drive other than drive if=none, it creates a block backend and asks the board to create a block frontend. Some boards create a modern QOMified device such as "cfi.pflash01", some create just a ROM memory region, which isn't a device (in the same way RAM normally isn't), and some ignore the request silently. The modern, fully general form for QOMified devices would be to define the backend with -drive if=none, and the frontend with -device. -bios ARG is sugar for -machine firmware=ARG. This asks the board to load firmware from file ARG. Again, boards could create a modern QOMified ROM device (theoretical, not sure there are any), a non-device ROM memory region, or ignore the request. The difference to pflash is that we don't wrap a full-blown block backend around the file, simply because that would complicate things for no gain. But that's detail; it's playing the role of a backend all the same. A (QOMified) PCI may have a PCI ROM. To configure its contents, you use a PCI device property naming a file. In all cases, QOMified devices get bits from the host via a backend. The backend can be an explicit object (e.g. a block backend) or, if the backend is trivial, folded into the frontend. > I think there is a device concept in here, the question is whether you > want to split the backend and frontend. For read-only data the > precedents favor not splitting it. Yes, we sometimes choose to fold trivial backends into the frontends instead of doing a split device. That's fine. However, in the case we're discussing, we're not doing that! There is no RAM device with a trivial backend folded in. There's only a weird pseudo-device that copies the contents of a file into memory, then sits around doing absolutely nothing. For me, that's an abuse of -device. It's certainly no worse than some other parts of the QEMU command line / QMP. Not exactly a good excuse, though :)