From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:52052) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1X1pHg-0007EV-EA for qemu-devel@nongnu.org; Tue, 01 Jul 2014 00:03:13 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1X1pHb-00016r-8t for qemu-devel@nongnu.org; Tue, 01 Jul 2014 00:03:08 -0400 Received: from cantor2.suse.de ([195.135.220.15]:34824 helo=mx2.suse.de) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1X1pHa-00016f-Tc for qemu-devel@nongnu.org; Tue, 01 Jul 2014 00:03:03 -0400 Content-Type: text/plain; charset=cp932 Mime-Version: 1.0 (1.0) From: Alexander Graf In-Reply-To: <5FE5E296BC647B42A2509AB982F88C131D17597C@ORSMSX108.amr.corp.intel.com> Date: Tue, 1 Jul 2014 06:03:01 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <1E4B5D4F-7AED-4C96-9AAF-3A2BECBA0FD5@suse.de> References: <5FE5E296BC647B42A2509AB982F88C131D1748CD@ORSMSX108.amr.corp.intel.com> <5FE5E296BC647B42A2509AB982F88C131D1757A3@ORSMSX108.amr.corp.intel.com> <53B1C6DD.3090606@suse.de> <5FE5E296BC647B42A2509AB982F88C131D17597C@ORSMSX108.amr.corp.intel.com> Subject: Re: [Qemu-devel] Adding memory region without specifying address List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Stalley, Sean" Cc: Peter Crosthwaite , "qemu-devel@nongnu.org" > Am 30.06.2014 um 23:47 schrieb "Stalley, Sean" : >=20 >=20 >=20 >> -----Original Message----- >> From: Alexander Graf [mailto:agraf@suse.de] >> Sent: Monday, June 30, 2014 1:22 PM >> To: Stalley, Sean; Peter Crosthwaite >> Cc: qemu-devel@nongnu.org >> Subject: Re: [Qemu-devel] Adding memory region without specifying address= >>=20 >>=20 >>> On 30.06.14 19:53, Stalley, Sean wrote: >>> Thanks for the quick response! Sorry for my belated reply... >>>=20 >>>> -----Original Message----- >>>> From: peter.crosthwaite@petalogix.com >>>> [mailto:peter.crosthwaite@petalogix.com] On Behalf Of Peter >>>> Crosthwaite >>>> Sent: Friday, June 27, 2014 6:26 PM >>>> To: Stalley, Sean; Alexander Graf >>>> Cc: qemu-devel@nongnu.org >>>> Subject: Re: [Qemu-devel] Adding memory region without specifying >>>> address >>>>=20 >>>> On Sat, Jun 28, 2014 at 10:29 AM, Stalley, Sean >> wrote: >>>>> Hello All, >>>>>=20 >>>>>=20 >>>>>=20 >>>>> I am working on building a hardware model for QEMU. This model needs >>>>> a couple memory regions for MMIO. >>>>>=20 >>>>> The thing is, I don=81ft particularly care what the physical address o= f >>>>> the memory region is (so long as it doesn=81ft overlap with any other >>>>> memory region). >>>> Curious, what's your mechanism for giving the auto allocated address >>>> to the guest? >>> We have one memory space that is fixed. The plan is to put the addresses= of >> the automatically allocated locations in the fixed space. >>=20 >> That sounds exactly like what I've been working on. The first incarnation= was >> called "platform bus", the second "platform devices", the current work is= going >> to be "sysbus hints" - but it's WIP. >=20 > Hmm, it sounds very similar. Out of curiosity, is there any relation to Li= nux platform devices? There's inspiration from them. After all, both are basically abstractions of= the same things ;). >=20 >>=20 >>>=20 >>>>>=20 >>>>> I was wondering if QEMU is able to =81eallocate=81f a memory region fo= r >>>>> hardware >>>>> (IE: I call into something saying I need a memory region X bytes long,= >>>>> and QEMU returns with a pointer to a memory region X bytes long). >>>> Do you have full control over the memory region you are adding these su= b- >>>> regions too and can you implement a "for-everything" allocator on the >> machine >>>> level? >>> We want to be able to put these sub-regions anywhere in memory-space, so= a >> "for-everything" allocator isn't really a good option. >>=20 >> Why not? >=20 > I think I misinterpreted the meaning of the term 'full control'. > Right now, the sole purpose of the guest machine is to validate this hardw= are model. I can change the hardware models in the guest as needed (although= I hope to keep them the same). In that sense, I have full control over the m= emory region.=20 >=20 >>=20 >>>=20 >>>>>=20 >>>>> Can QEMU do this? was looking at the various flavors of >>>>> memory_region_add_subregion(), but they all seem to require a hardware= >>>>> offset=81c >>>> Alex's addressless -device work may be related but it's more about comm= and >>>> line usability. Autoallocation of MMIO addresses is a feature there how= ever. >>> Where is this code located? I have been looking, but I haven=81ft been a= ble to find >> it yet. Is this called by qdev_device_add()? >>=20 >> It's not upstream yet ;). >=20 > Aah, that explains why I couldn't find it :P >=20 >=20 > It seems like the answer to my initial question, "can qemu add a memory re= gion for hardware without being given a specific address" is "Not yet". Exactly. But you can also add a "it will very soon". :) Alex >=20 > Thanks, > Sean=20