qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: David Hildenbrand <david@redhat.com>
To: Peter Maydell <peter.maydell@linaro.org>
Cc: "Marc-André Lureau" <marcandre.lureau@gmail.com>,
	QEMU <qemu-devel@nongnu.org>,
	"Paolo Bonzini" <pbonzini@redhat.com>,
	"Stefan Berger" <stefanb@linux.vnet.ibm.com>,
	qiaonuohan@cn.fujitsu.com
Subject: Re: Page alignment & memory regions expectations
Date: Thu, 25 Aug 2022 09:26:59 +0200	[thread overview]
Message-ID: <bd40c251-b670-3a9a-f29c-86268d06a5b7@redhat.com> (raw)
In-Reply-To: <CAFEAcA9OH4ih2pOUbsv6dTMW=3_9LTkzSRj4ogO4oxVS4fOASw@mail.gmail.com>

On 24.08.22 21:55, Peter Maydell wrote:
> On Wed, 24 Aug 2022 at 17:43, David Hildenbrand <david@redhat.com> wrote:
>> One idea is doing another pass over the list at the end (after possible
>> merging of sections) and making sure everything is page-aligned.
>>
>> Another idea is specifying somehow that that memory region should simply
>> not be dumped ...
>>
>>
>> But I do wonder why the ram memory region that's mapped into the guest
>> physical address space has such a weird alignment/size ...
> 
> Lumps of memory can be any size you like and anywhere in
> memory you like. Sometimes we are modelling real hardware
> that has done something like that. Sometimes it's just
> a convenient way to model a device. Generic code in
> QEMU does need to cope with this...

But we are talking about system RAM here. And judging by the fact that
this is the first time dump.c blows up like this, this doesn't seem to
very common, no?


-- 
Thanks,

David / dhildenb



  reply	other threads:[~2022-08-25  7:29 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-08-24 12:43 Page alignment & memory regions expectations Marc-André Lureau
2022-08-24 16:42 ` David Hildenbrand
2022-08-24 19:55   ` Peter Maydell
2022-08-25  7:26     ` David Hildenbrand [this message]
2022-08-25 11:47       ` Peter Maydell
2022-08-25 11:57         ` David Hildenbrand
2022-08-25 12:18           ` Peter Maydell

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=bd40c251-b670-3a9a-f29c-86268d06a5b7@redhat.com \
    --to=david@redhat.com \
    --cc=marcandre.lureau@gmail.com \
    --cc=pbonzini@redhat.com \
    --cc=peter.maydell@linaro.org \
    --cc=qemu-devel@nongnu.org \
    --cc=qiaonuohan@cn.fujitsu.com \
    --cc=stefanb@linux.vnet.ibm.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).