qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Alexander Graf <agraf@suse.de>
To: "Stalley, Sean" <sean.stalley@intel.com>,
	Peter Crosthwaite <peter.crosthwaite@xilinx.com>
Cc: "qemu-devel@nongnu.org" <qemu-devel@nongnu.org>
Subject: Re: [Qemu-devel] Adding memory region without specifying address
Date: Mon, 30 Jun 2014 22:21:49 +0200	[thread overview]
Message-ID: <53B1C6DD.3090606@suse.de> (raw)
In-Reply-To: <5FE5E296BC647B42A2509AB982F88C131D1757A3@ORSMSX108.amr.corp.intel.com>


On 30.06.14 19:53, Stalley, Sean wrote:
> Thanks for the quick response! Sorry for my belated reply...
>
>> -----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
>>
>> On Sat, Jun 28, 2014 at 10:29 AM, Stalley, Sean <sean.stalley@intel.com> wrote:
>>> Hello All,
>>>
>>>
>>>
>>> I am working on building a hardware model for QEMU. This model needs a
>>> couple memory regions for MMIO.
>>>
>>> The thing is, I don’t particularly care what the physical address of
>>> the memory region is (so long as it doesn’t 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.

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.

>
>>>
>>> I was wondering if QEMU is able to ‘allocate’ a memory region for
>>> 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 sub-
>> 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.

Why not?

>
>>>
>>> Can QEMU do this? was looking at the various flavors of
>>> memory_region_add_subregion(), but they all seem to require a hardware
>>> offset…
>>>
>> Alex's addressless -device work may be related but it's more about command
>> line usability. Autoallocation of MMIO addresses is a feature there however.
> Where is this code located? I have been looking, but I haven’t been able to find it yet. Is this called by qdev_device_add()?

It's not upstream yet ;).


Alex

  reply	other threads:[~2014-06-30 20:22 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-06-28  0:29 [Qemu-devel] Adding memory region without specifying address Stalley, Sean
2014-06-28  1:26 ` Peter Crosthwaite
2014-06-30 17:53   ` Stalley, Sean
2014-06-30 20:21     ` Alexander Graf [this message]
2014-06-30 21:47       ` Stalley, Sean
2014-07-01  4:03         ` Alexander Graf

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=53B1C6DD.3090606@suse.de \
    --to=agraf@suse.de \
    --cc=peter.crosthwaite@xilinx.com \
    --cc=qemu-devel@nongnu.org \
    --cc=sean.stalley@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).