From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jan Kiszka Subject: Re: [Qemu-devel] [PATCH v5 06/16] apic: Introduce backend/frontend infrastructure for KVM reuse Date: Tue, 20 Dec 2011 01:32:06 +0100 Message-ID: <4EEFD786.8030609@web.de> References: <4EEFB72E.7030508@codemonkey.ws> <4EEFC970.9030205@web.de> <4EEFD69F.6080700@codemonkey.ws> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig851A2F69B5D185DF92251FBC" Cc: Anthony Liguori , kvm@vger.kernel.org, "Michael S. Tsirkin" , Marcelo Tosatti , qemu-devel , Blue Swirl , Avi Kivity To: Anthony Liguori Return-path: Received: from fmmailgate02.web.de ([217.72.192.227]:48448 "EHLO fmmailgate02.web.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752593Ab1LTAcN (ORCPT ); Mon, 19 Dec 2011 19:32:13 -0500 Received: from moweb002.kundenserver.de (moweb002.kundenserver.de [172.19.20.108]) by fmmailgate02.web.de (Postfix) with ESMTP id CEE931BCB69B9 for ; Tue, 20 Dec 2011 01:32:12 +0100 (CET) In-Reply-To: <4EEFD69F.6080700@codemonkey.ws> Sender: kvm-owner@vger.kernel.org List-ID: This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig851A2F69B5D185DF92251FBC Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 2011-12-20 01:28, Anthony Liguori wrote: > On 12/19/2011 05:32 PM, Jan Kiszka wrote: >>> struct APICCommonInfo { >>> DeviceInfo qdev; >>> void (*init)(APICState *s); >>> void (*set_base)(APICState *s, uint64_t val); >>> void (*set_tpr)(APICState *s, uint8_t val); >>> void (*external_nmi)(APICState *s); >>> }; >>> >>> Take a look at SCSIDevice for an example of this in practice. This i= s >>> nicer because as we move save/load into devices methods, it becomes >>> natural to define the state and save/load function in the base class.= >>> Provided it only uses base class state, it lets save/load be compatib= le >>> between both in-kernel and in-qemu device model. >> >> The difference is (unless I completely miss your point) that a common >> SCSI base class is used by different derived classes. >=20 > The 'frontend' is the common code and the 'backend' are the bits that > are different, no? >=20 > We ultimately want there to be two devices that share all of the > 'frontend' code by providing different 'backend' implementations. >=20 > So make the 'frontend' a base class that provides a set of abstract > virtual methods (the set you have as the 'backend' interface). Each > device instance then inherits from the base class and provides its own > implementation of the virtual methods. >=20 >> Here we have a >> common frontend class but different base classes, so to say. And we ha= ve >> a mechanism to chose where to inherit from on instantiation. Precisely= >> this allows to keep the compatibility between in-kernel and user space= >> model in this series. >=20 > Okay, so I really think this is the problem. The in-kernel APIC is a > separate device, no a property of the userspace APIC device. >=20 > It should be modeled as two separate devices. That was v1 of my patches. Avi didn't like it, I tried it like this, and in the end I had to agree. So, no, I don't think we want such a model. Jan --------------enig851A2F69B5D185DF92251FBC Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk7v14cACgkQitSsb3rl5xSLbQCePCWheQJq+FLsiEjSHe+YSBym kOEAn1v0YC0GzoY9VKpbvPiasNhTr3RT =uK1D -----END PGP SIGNATURE----- --------------enig851A2F69B5D185DF92251FBC--