From: Jonathan Cameron via <qemu-devel@nongnu.org>
To: Peter Maydell <peter.maydell@linaro.org>
Cc: "Richard Henderson" <richard.henderson@linaro.org>,
"Jørgen Hansen" <Jorgen.Hansen@wdc.com>,
"Ajay Joshi" <Ajay.Joshi@wdc.com>,
qemu-devel <qemu-devel@nongnu.org>,
"Sid Manning" <sidneym@quicinc.com>
Subject: Re: An issue with x86 tcg and MMIO
Date: Thu, 2 Feb 2023 12:31:18 +0000 [thread overview]
Message-ID: <20230202123118.00003bd6@Huawei.com> (raw)
In-Reply-To: <CAFEAcA9ohWGgaCK60Di4iUdgYqpmHeB_WnDGv4PzyfyfquMUzw@mail.gmail.com>
On Thu, 2 Feb 2023 11:39:28 +0000
Peter Maydell <peter.maydell@linaro.org> wrote:
> On Thu, 2 Feb 2023 at 10:56, Richard Henderson
> <richard.henderson@linaro.org> wrote:
> >
> > On 2/1/23 23:39, Jonathan Cameron wrote:
> > > Not sure - if we can do the handling above then sure we could make that change.
> > > I can see there is a path to register the callbacks but I'd kind of assumed
> > > ROM meant read only...
> >
> > I think "romd" means "read mostly".
> >
> > In the case of flash, I believe that a write changes modes (block erase something
> > something) and the region changes state into MMIO. But normal state is read mode where
> > read+execute go through unchallenged.
>
> In QEMU a ROMD MemoryRegion (created by memory_region_init_rom_device())
> is a memory region backed by RAM for reads and by callbacks for writes.
> (I think ROMD stands for "ROM device".)
>
> You can then use memory_region_device_set_romd() to put the ROMD into
> either ROMD mode (the default, reads backed by RAM) or MMIO mode
> (reads backed by MMIO callbacks). Writes are always callbacks regardless.
> This is mainly meant for flash devices, which are usually reads-as-data
> but have a programming mode where you write a command to it and then
> read back command results. It's possible to use it for other tricks too.
>
> When a ROMD is in ROMD mode then execution from it is as fast as execution
> from any RAM; when it is in MMIO mode then execution from it is as slow
> as execution from any other MMIO-backed MemoryRegion.
Thanks for the info - I don't think ROMD helps us much here as we'd need
to be constantly in the MMIO mode as we need the callbacks for both read
and write.
>
> Note that AFAIK you can't execute from MMIO at all with KVM (either
> ROMD-in-MMIO mode or a plain old MMIO device).
That may not be a significant problem for CXL emulation - though we should
definitely make that restriction clear and it might slow down some testing.
As far as I know there are no usecases beyond testing of software stacks
and TCG is fine for that.
>
> You might want to look at whether QEMU's iommu functionality is helpful
> to you -- I'm assuming CXL doesn't do weird stuff on a less-than-page
> granularity, and the iommu APIs will let you do "programmatically decide
> where this address should actually go". The other option involves
> mapping and unmapping MemoryRegions inside a container MR.
Unfortunately it does weird stuff well below a page granularity.
Interleaving is down to 256 bytes.
We discussed the memory region approach when this originally came up.
The issue is that we get an insane number of memory regions to support
even basic interleave setups (many millions) - hence doing the address
decoding via a read and write callbacks at runtime instead.
Jonathan
>
> thanks
> -- PMM
next prev parent reply other threads:[~2023-02-02 12:33 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <78bc53e3-bad3-a5c3-9e53-7a89054aa37a@wdc.com>
2023-02-01 21:50 ` An issue with x86 tcg and MMIO Richard Henderson
2023-02-02 9:39 ` Jonathan Cameron via
2023-02-02 10:56 ` Richard Henderson
2023-02-02 11:39 ` Peter Maydell
2023-02-02 12:31 ` Jonathan Cameron via [this message]
2023-02-02 13:31 ` 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=20230202123118.00003bd6@Huawei.com \
--to=qemu-devel@nongnu.org \
--cc=Ajay.Joshi@wdc.com \
--cc=Jonathan.Cameron@Huawei.com \
--cc=Jorgen.Hansen@wdc.com \
--cc=peter.maydell@linaro.org \
--cc=richard.henderson@linaro.org \
--cc=sidneym@quicinc.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).