All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Marc Marí" <marc.mari.barcelo@gmail.com>
To: Paolo Bonzini <pbonzini@redhat.com>
Cc: "Peter Maydell" <peter.maydell@linaro.org>,
	qemu-devel@nongnu.org, "Stefan Hajnoczi" <stefanha@redhat.com>,
	"Andreas Färber" <afaerber@suse.de>
Subject: Re: [Qemu-devel] [RFC] qapi: New command query-mtree
Date: Thu, 21 Aug 2014 11:18:10 +0200	[thread overview]
Message-ID: <20140821111810.785eaad2@crunchbang> (raw)
In-Reply-To: <53F5B6AB.7010205@redhat.com>

El Thu, 21 Aug 2014 11:06:51 +0200
Paolo Bonzini <pbonzini@redhat.com> escribió:
> Il 20/08/2014 19:46, Marc Marí ha scritto:
> > Add command query-mtree to get the memory tree of the guest.
> > 
> > As we were looking for a flexible solution on accessing the guest
> > memory from qtests, Stefan came with the idea to implement this new
> > qmp command.
> > 
> > This way, the result can be parsed, and the RAM direction
> > extracted, so only a generic qtest malloc is necessary and not one
> > per machine, as it is implemented at the moment (malloc-pc uses
> > fw_cfg).
> > 
> > The actual output is this: http://pastebin.com/nHAH9Jie
> > Which corresponds to this info mtree: http://pastebin.com/B5vw8DDf
> 
> I don't like this idea very much.  libqos should be using the real
> memory map information from the machine.  In the case of x86, that
> means fw_cfg; in the case of ARM, that would mean using the device
> tree. Getting the information from an out-of-band channel (such as
> QMP) is basically cheating. :)

As we were looking at how to access the device tree, we found that the
device tree is saved in memory with the bootloader or the kernel. So
tests should be using a kernel every time a ARM machine is booted
(and /dev/null, at least in virt machine, does not work). Do you have
any better idea on how to do it?

> If you had a memory map abstraction in libqos, malloc could be
> generic. Perhaps you can start doing that for PC?

Do you mean, start implementing malloc using this "query-mtree"? Or you
have another idea in mind?

Marc

  reply	other threads:[~2014-08-21  9:18 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-08-20 17:46 [Qemu-devel] [RFC] qapi: New command query-mtree Marc Marí
2014-08-20 19:09 ` Eric Blake
2014-08-20 20:08   ` Marc Marí
2014-08-20 20:12   ` Eric Blake
2014-08-21  9:06 ` Paolo Bonzini
2014-08-21  9:18   ` Marc Marí [this message]
2014-08-21  9:47     ` Paolo Bonzini
2014-08-21  9:56     ` Paolo Bonzini

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=20140821111810.785eaad2@crunchbang \
    --to=marc.mari.barcelo@gmail.com \
    --cc=afaerber@suse.de \
    --cc=pbonzini@redhat.com \
    --cc=peter.maydell@linaro.org \
    --cc=qemu-devel@nongnu.org \
    --cc=stefanha@redhat.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.