qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: "Alex Bennée" <alex.bennee@linaro.org>
To: Aaron Lindsay <aaron@os.amperecomputing.com>
Cc: cota@braap.org, richard.henderson@linaro.org, qemu-devel@nongnu.org
Subject: Re: Plugin Address Translations Inconsistent/Incorrect?
Date: Tue, 02 Mar 2021 16:06:46 +0000	[thread overview]
Message-ID: <87sg5dilp7.fsf@linaro.org> (raw)
In-Reply-To: <YD5atyGBcnxG8+ZK@strawberry.localdomain>


Aaron Lindsay <aaron@os.amperecomputing.com> writes:

> On Feb 23 15:53, Aaron Lindsay wrote:
>> On Feb 22 15:48, Aaron Lindsay wrote:
>> > On Feb 22 19:30, Alex Bennée wrote:
>> > > Aaron Lindsay <aaron@os.amperecomputing.com> writes:
>> > > That said I think we could add an additional helper to translate a
>> > > hwaddr to a global address space address. I'm open to suggestions of the
>> > > best way to structure this.
>> > 
>> > Haven't put a ton of thought into it, but what about something like this
>> > (untested):
>> > 
>> > uint64_t qemu_plugin_hwaddr_phys_addr(const struct qemu_plugin_hwaddr *haddr)
>> > {
>> > #ifdef CONFIG_SOFTMMU
>> >     if (haddr) {
>> >         if (!haddr->is_io) {
>> >             RAMBlock *block;
>> >             ram_addr_t offset;
>> > 
>> >             block = qemu_ram_block_from_host((void *) haddr->v.ram.hostaddr, false, &offset);
>> >             if (!block) {
>> >                 error_report("Bad ram pointer %"PRIx64"", haddr->v.ram.hostaddr);
>> >                 abort();
>> >             }
>> > 
>> >             return block->offset + offset + block->mr->addr;
>> >         } else {
>> >             MemoryRegionSection *mrs = haddr->v.io.section;
>> >             return haddr->v.io.offset + mrs->mr->addr;
>> >         }
>> >     }
>> > #endif
>> >     return 0;
>> > }
>> 
>> This appears to successfully return correct physical addresses for RAM
>> at least, though I've not tested it thoroughly for MMIO yet.
>> 
>> If it ends up being desirable based on the discussion elsewhere on this
>> thread I am willing to perform more complete testing, turn this into a
>> patch, and submit it.
>
> Ping - Is this something worth me pursuing?

Yes please. 

-- 
Alex Bennée


  reply	other threads:[~2021-03-02 16:08 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-02-22 17:07 Plugin Address Translations Inconsistent/Incorrect? Aaron Lindsay
2021-02-22 19:30 ` Alex Bennée
2021-02-22 20:08   ` Peter Maydell
2021-02-23  8:52     ` Alex Bennée
2021-02-23 10:55       ` Peter Maydell
2021-02-22 20:48   ` Aaron Lindsay via
2021-02-23 20:53     ` Aaron Lindsay via
2021-03-02 15:33       ` Aaron Lindsay via
2021-03-02 16:06         ` Alex Bennée [this message]
2021-03-02 19:41           ` Aaron Lindsay via
2021-03-02 21:04             ` Alex Bennée

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=87sg5dilp7.fsf@linaro.org \
    --to=alex.bennee@linaro.org \
    --cc=aaron@os.amperecomputing.com \
    --cc=cota@braap.org \
    --cc=qemu-devel@nongnu.org \
    --cc=richard.henderson@linaro.org \
    /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).