From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:33691) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Y1qI2-0002tu-PJ for qemu-devel@nongnu.org; Fri, 19 Dec 2014 00:39:54 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Y1qHw-0006R6-HJ for qemu-devel@nongnu.org; Fri, 19 Dec 2014 00:39:50 -0500 Received: from ozlabs.org ([103.22.144.67]:35789) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Y1qHv-0006PW-VG for qemu-devel@nongnu.org; Fri, 19 Dec 2014 00:39:44 -0500 Date: Fri, 19 Dec 2014 16:39:37 +1100 From: David Gibson Message-ID: <20141219053937.GI12159@voom.redhat.com> References: <1418690628-20652-1-git-send-email-david@gibson.dropbear.id.au> <1418690628-20652-2-git-send-email-david@gibson.dropbear.id.au> <548F83D5.3000903@suse.de> <20141216012437.GH23547@voom.fritz.box> <96E329FA-8614-4FD4-8F6E-E345BB84AB7E@suse.de> <20141218054328.GF12159@voom.redhat.com> <549364EB.3070108@suse.de> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="boAH8PqvUi1v1f55" Content-Disposition: inline In-Reply-To: <549364EB.3070108@suse.de> Subject: Re: [Qemu-devel] [PATCH 1/5] pseries: Move sPAPR RTC code into its own file List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Alexander Graf Cc: "aik@ozlabs.ru" , "paulus@samba.org" , "qemu-devel@nongnu.org" , "mdroth@us.ibm.com" --boAH8PqvUi1v1f55 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Dec 19, 2014 at 12:36:11AM +0100, Alexander Graf wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 >=20 >=20 >=20 > On 18.12.14 06:43, David Gibson wrote: > > On Tue, Dec 16, 2014 at 10:41:16AM +0100, Alexander Graf wrote: > >>=20 > >>=20 > >>=20 > >>> Am 16.12.2014 um 02:24 schrieb David Gibson > >>> : > >>>=20 > >>>> On Tue, Dec 16, 2014 at 01:59:01AM +0100, Alexander Graf > >>>> wrote: > >>>>=20 > >>>>=20 > >>>>> On 16.12.14 01:43, David Gibson wrote: At the moment the > >>>>> RTAS (firmware/hypervisor) time of day functions are=20 > >>>>> implemented in spapr_rtas.c along with a bunch of other > >>>>> things. Since we're going to be expanding these a bit, > >>>>> move the RTAS RTC related code out into new file > >>>>> spapr_rtc.c. Also add its own initialization function,=20 > >>>>> spapr_rtc_init() called from the main machine init > >>>>> routine. > >>>>>=20 > >>>>> Signed-off-by: David Gibson =20 > >>>>> --- hw/ppc/Makefile.objs | 2 +- hw/ppc/spapr.c | > >>>>> 3 ++ hw/ppc/spapr_rtas.c | 49 > >>>>> ----------------------------- hw/ppc/spapr_rtc.c | 83 > >>>>> ++++++++++++++++++++++++++++++++++++++++++++++++++=20 > >>>>> include/hw/ppc/spapr.h | 1 + 5 files changed, 88 > >>>>> insertions(+), 50 deletions(-) create mode 100644 > >>>>> hw/ppc/spapr_rtc.c > >>>>>=20 > >>>>> diff --git a/hw/ppc/Makefile.objs b/hw/ppc/Makefile.objs=20 > >>>>> index 19d9920..437955d 100644 --- a/hw/ppc/Makefile.objs=20 > >>>>> +++ b/hw/ppc/Makefile.objs @@ -3,7 +3,7 @@ obj-y +=3D ppc.o > >>>>> ppc_booke.o # IBM pSeries (sPAPR) obj-$(CONFIG_PSERIES) +=3D > >>>>> spapr.o spapr_vio.o spapr_events.o obj-$(CONFIG_PSERIES) +=3D > >>>>> spapr_hcall.o spapr_iommu.o spapr_rtas.o=20 > >>>>> -obj-$(CONFIG_PSERIES) +=3D spapr_pci.o=20 > >>>>> +obj-$(CONFIG_PSERIES) +=3D spapr_pci.o spapr_rtc.o ifeq > >>>>> ($(CONFIG_PCI)$(CONFIG_PSERIES)$(CONFIG_LINUX), yyy) obj-y > >>>>> +=3D spapr_pci_vfio.o endif diff --git a/hw/ppc/spapr.c > >>>>> b/hw/ppc/spapr.c index 30de25d..16377a3 100644 --- > >>>>> a/hw/ppc/spapr.c +++ b/hw/ppc/spapr.c @@ -1446,6 +1446,9 @@ > >>>>> static void ppc_spapr_init(MachineState *machine) /* Set up > >>>>> EPOW events infrastructure */ spapr_events_init(spapr); > >>>>>=20 > >>>>> + /* Set up the RTC RTAS interfaces */ + > >>>>> spapr_rtc_init(); > >>>>=20 > >>>> Do you think we could make it a device instead? > >>>=20 > >>> Um.. I guess. Is there a standard place to put such > >>> pseudo-devices in the bus heirarchy? > >>=20 > >> How about we combine this with some cleanup work and create a > >> new spapr bus that (in the long term) exposes all the details we > >> carry around in the spapr struct to its children via the bus? > >=20 > > I've thought about this a bit more. It really doesn't make sense > > to put the rtc device anywhere except the root bus (which > > optionally could become an spapr sub-type of the default root bus > > type). >=20 > Well, we could always just leave sysbus completely unused and instead > create our own global spapr root bus. In fact, that's probably what we > should do ;). We could, but I absolutely disagree that it's what we should do. What is the sysbus for, if not to represent devices on the system that don't fall under some other bus bridge. Putting an spapr bus under it is indirection for no purpose. > If that blows your mind for this patch set, we can make the RTC a > sysbus device too though. >=20 > > But, while splitting this into its own device would be cleaner, I=20 > > don't think we should delay real behavioural fixes for that > > cleanup. Working out how to split out the device without breaking > > old machine types, and keeping migration working is making my head > > hurt. >=20 > I don't think it's that hard. Just create a compat version for version > 2 of "spapr" vmstates and have a post_load hook in there that shoves > the rtc offset into the new rtc device via a qom property. You should > even be able to just find the RTC device by path. Yeah, I kind of figured that out myself in the meantime. It's bit ugly, because we need to retain the otherwise useless rtc_offset field in sPAPREnvironment just to be loaded by the vmstatdescription then pushed into the rtc, but I guess it works. > Keep in mind that we don't support new -> old migration. --=20 David Gibson | I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson --boAH8PqvUi1v1f55 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBAgAGBQJUk7oYAAoJEGw4ysog2bOSGd8P/R/JD51Cmu/+qaZDIdru2tyX SNp74FUR8ySZyQfeKCjatB2ZMDVNpmdWrc9ec6WqlueLRTuO1juJ9W0KQbHBhZEn xVTNqeQvp2BpqzcouG6EzXDSeDS0xM2c7avYdcuw06uStGND4Xk4GRHySmgsMVWP +YYNVi2poJkU5PMOU8qRj/d/2jTVO0HEwGrDwxSUd12+8zErCKGyu3SxFGa4Z8ne I3e8IsqR18i/YokaZZCkx9Gn+RijH5/FYlsRggowyxy2jmx2dcnUMvleJdoAPzaY QNKRnu8nlArLI37+UwexFDQ/SDnQquaFC5kS6agRXFHH84YwMeOzQGXjXIJRRror q5Eysp6PpCsqRB70+UY/Lg6Z0wm8IACxWIrWEe9vUQHAYlcq9qP0oT1bVTn/8zVG PdxW4/VVFSl6UgcfCQHwaUE30FZmA2Mq2x/d74xs+jyfzhoQU/4U797AP3OZBLcL sm6UgKrjqJuyBdgHQtclDkLao9MD1oxxl36/V14Hc1bc0+EfLjWKLXYT+i5+VNgC S4AvottsqFUtCxQcJCHoMwL0Ai+wkZGLbOMV55mqBPYqIx4LRP6A2B5f7cTmYsW9 usVS5qbjukP60y4RpdsRseEBuD/+VC8IGXgd8Xq/s5SetKXpqsrqXHYkFeQhv5jn e69GZojYCmTX1wiax/Ff =4hsL -----END PGP SIGNATURE----- --boAH8PqvUi1v1f55--