From: Jan Kiszka <jan.kiszka@web.de>
To: Avi Kivity <avi@redhat.com>
Cc: qemu-devel <qemu-devel@nongnu.org>, Richard Henderson <rth@twiddle.net>
Subject: Re: [Qemu-devel] [PATCH] isa: Avoid using obsolete memory_region_set_offset for old portio
Date: Mon, 19 Sep 2011 14:29:40 +0200 [thread overview]
Message-ID: <4E7735B4.1030903@web.de> (raw)
In-Reply-To: <4E77322B.2040008@redhat.com>
[-- Attachment #1: Type: text/plain, Size: 2737 bytes --]
On 2011-09-19 14:14, Avi Kivity wrote:
> On 09/18/2011 10:04 PM, Jan Kiszka wrote:
>> >
>> > If you make the core patch add both mr->offset and mrp->offset, then
>> > change isa to drop memory_region_set_offset(), instead adding the
>> delta
>> > to mrp->offset, does that not work out?
>>
>> Nope. The old API accepted arbitrary portio lists per memory region, the
>> new requires one region with a consistent offset per range. I should
>> have documented it...
>
> What does "a consistent offset per range" mean? You aren't actually
> changing the caller's ranges.
I'm changing the way isa_register_portio_1 registers portios with the
core: only one per offset. The new commit log says:
"This implies that MemoryRegionPortio::offset is no longer used as
offset within the memory region but just as a correction value for the
offset passed to legacy handlers that expect absolute port addresses."
>
>
>>
>> >
>> >> > And I
>> >> > don't want to remove memory_region_set_offset() until
>> everything (that
>> >> > can potentially use it, at least) has been converted.
>> >>
>> >> IMO it's easier to fix those potential users before converting
>> them. You
>> >> need to review them anyway to decide if an offset might be needed,
>> and
>> >> which one precisely.
>> >>
>> >> Are you aware of any candidates? For PIO, there should be none now.
>> >
>> > For pio, none, but mmio has some:
>> >
>> > hw/sh7750.c: cpu_register_physical_memory_offset(0x1f000000,
>> 0x1000,
>> > hw/sh7750.c: cpu_register_physical_memory_offset(0xff000000,
>> 0x1000,
>> > hw/sh7750.c: cpu_register_physical_memory_offset(0x1f800000,
>> 0x1000,
>> > hw/sh7750.c: cpu_register_physical_memory_offset(0xff800000,
>> 0x1000,
>> > hw/sh7750.c: cpu_register_physical_memory_offset(0x1fc00000,
>> 0x1000,
>> > hw/sh7750.c: cpu_register_physical_memory_offset(0xffc00000,
>> 0x1000,
>> > hw/sh_intc.c:
>> > cpu_register_physical_memory_offset(P4ADDR(address), 4,
>> > hw/sh_intc.c:
>> > cpu_register_physical_memory_offset(A7ADDR(address), 4,
>>
>> Cool, that's all. Trivial to fix, just push the offset math into those
>> few handler. Then we can drop cpu_register_physical_memory_offset as
>> well.
>
> They all use the same handler, so you need to split e.g.
> sh7750_io_memory into six MemoryRegionsOps. Or use tricks with aliases -
> have one giant 4G region with one handler, and map six 4k aliases into
> the system address space.
Looks more like 3 regions with one alias each. But we likely need to
disentangle all that logic first. I would be surprised if there wasn't a
more readable way to express it via the memory API.
Jan
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 262 bytes --]
next prev parent reply other threads:[~2011-09-19 12:29 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-09-18 12:54 [Qemu-devel] [PATCH] isa: Avoid using obsolete memory_region_set_offset for old portio Jan Kiszka
2011-09-18 13:09 ` [Qemu-devel] [PATCH] memory: Eliminate region offset Jan Kiszka
2011-09-18 15:57 ` [Qemu-devel] [PATCH] isa: Avoid using obsolete memory_region_set_offset for old portio Avi Kivity
2011-09-18 16:29 ` Jan Kiszka
2011-09-18 16:46 ` Avi Kivity
2011-09-18 19:04 ` Jan Kiszka
2011-09-19 12:14 ` Avi Kivity
2011-09-19 12:29 ` Jan Kiszka [this message]
2011-09-19 12:37 ` Avi Kivity
2011-09-19 12:48 ` Jan Kiszka
2011-09-19 12:59 ` Avi Kivity
2011-09-18 16:49 ` Richard Henderson
2011-09-18 19:16 ` Jan Kiszka
2011-09-19 12:15 ` Avi Kivity
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=4E7735B4.1030903@web.de \
--to=jan.kiszka@web.de \
--cc=avi@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=rth@twiddle.net \
/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.