From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:52179) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SPDrp-0005uL-KB for qemu-devel@nongnu.org; Tue, 01 May 2012 10:15:51 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SPDrn-0007nf-Ag for qemu-devel@nongnu.org; Tue, 01 May 2012 10:15:49 -0400 Received: from mail-pb0-f45.google.com ([209.85.160.45]:44121) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SPDrm-0007n6-S5 for qemu-devel@nongnu.org; Tue, 01 May 2012 10:15:47 -0400 Received: by pbbro12 with SMTP id ro12so4955939pbb.4 for ; Tue, 01 May 2012 07:15:45 -0700 (PDT) Message-ID: <4F9FF00C.2070000@codemonkey.ws> Date: Tue, 01 May 2012 09:15:40 -0500 From: Anthony Liguori MIME-Version: 1.0 References: <4F9D797E.500@ilande.co.uk> <4F9D97F3.8080608@codemonkey.ws> <4F9E5028.7010306@redhat.com> <4F9E82C7.10706@ilande.co.uk> <4F9E9268.70408@redhat.com> <4F9E9569.5000700@redhat.com> <4F9FD997.9000403@redhat.com> <4F9FDA38.6030108@redhat.com> <4F9FDB80.4020604@redhat.com> <4F9FDEBC.2030806@redhat.com> <4F9FEA24.3070603@codemonkey.ws> <4F9FEE83.70306@redhat.com> In-Reply-To: <4F9FEE83.70306@redhat.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] Memory API: handling unassigned physical memory List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Avi Kivity Cc: Peter Maydell , Mark Cave-Ayland , qemu-devel@nongnu.org On 05/01/2012 09:09 AM, Avi Kivity wrote: > On 05/01/2012 04:50 PM, Anthony Liguori wrote: >> On 05/01/2012 08:01 AM, Avi Kivity wrote: >>> On 05/01/2012 03:49 PM, Peter Maydell wrote: >>>> On 1 May 2012 13:48, Avi Kivity wrote: >>>>> On 05/01/2012 03:43 PM, Peter Maydell wrote: >>>>>> On 1 May 2012 13:42, Avi Kivity wrote: >>>>>>> sysbus should just die. >>>>>> >>>>>> Totally agreed. It's not going to go quietly though... >>>>> >>>>> Not if you keep suggesting workarounds when I tell unsuspecting >>>>> developers to qomify their devices. >>>> >>>> When QOM supports (1) exporting gpio signals and >> >> This is trivial. It'll come in as soon as 1.2 opens up. If folks >> want to start working on a branch with it: >> >> https://github.com/aliguori/qemu/tree/qom-pin.4 >> >>>> (2) exporting memory regions, then it will be providing the >>>> main things that sysbus provides. >> >> This is a little tricky. Here's the problems I've encountered so far: >> >> a) A lot of devices need the equivalent of it_shift. it_shift affects >> how addresses are decoded and the size of the memory region. it_shift >> usually needs to be a device property. >> >> Since we need to know the size of the memory region to initialize it, >> we need to know the value of it_shift before we can initialize it >> which means we have to delay the initialization of the mmemory region >> until realize. >> >> I think a nice fix would be to make it_shift as memory region mutator >> and allow it to be set after initialization. > > Indeed I wanted to make it_shift as part of the memory core. But a > mutator? It doesn't change in real hardware, so this looks artificial. > So far all mutators really change at runtime. QOM has a concept of initialization and realize. You can change properties after initialization but not before realize. So as long as it_shift can be set after initialization but before realize (which I think is roughly memory_region_add_subregion) it doesn't need to be a mutator. > What is the problem with delaying region initialization until realize? We need to initialize the MemoryRegion in order to expose it as a property. We want to do that during initialize. Here's an example: qom-create isa-i8259 foo qom-set /peripheral/foo/io it_shift 1 qom-set /peripheral/foo/realize true For this to work, it_shift needs to be a QOM property of the "io" MemoryRegion. The MemoryRegion needs to be created in instance_init. >> b) There's some duplication in MemoryRegions with respect to QOM. >> Memory regions want to have a name but with QOM they'll be addressable >> via a path. I go back and forth about how aggressively we want to >> refactor MemoryRegions. > > These days region names are purely for debugging. The ABI bit was moved > to a separate function. Fair enough. BTW, in the branch I've posted, I've got a number of memory API conversions or removal of legacy interfaces. Regards, Anthony Liguori