qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Paolo Bonzini <pbonzini@redhat.com>
To: Alexey Kardashevskiy <aik@ozlabs.ru>, qemu-devel@nongnu.org
Cc: Stefan Hajnoczi <stefanha@gmail.com>,
	Peter Maydell <peter.maydell@linaro.org>,
	David Gibson <david@gibson.dropbear.id.au>
Subject: Re: [Qemu-devel] [RFC PATCH qemu 3/4] memory: Share flat views and dispatch trees between address spaces
Date: Tue, 12 Sep 2017 09:12:47 +0200	[thread overview]
Message-ID: <adb82532-59fc-5eed-0976-0a08fea56601@redhat.com> (raw)
In-Reply-To: <7fff3fb3-0d55-9c80-6269-ceb693ba93f0@ozlabs.ru>

On 12/09/2017 07:55, Alexey Kardashevskiy wrote:
> On 12/09/17 01:30, Paolo Bonzini wrote:
>> On 11/09/2017 14:08, Alexey Kardashevskiy wrote:
>>>> Ok, this makes sense.  Maybe it should be a flatview rather than an
>>>> AddressSpaceDispatch (a FlatView is essentially a list of
>>>> MemoryRegionSections; attaching the ASD to the FlatView is more or less
>>>> an implementation detail).
>>> The helpers I converted from AddressSpace to AddressSpaceDispatch do use
>>> dispatch structure only and do not use FlatView so it seemed logical.
>>
>> Understood, but from a design POV FlatView makes more sense.
>>
>>> btw this address_space in MemoryRegionSection - it does not seem to make
>>> much sense in the PhysPageMap::sections array, it only makes sense when
>>> MemoryRegionSection uses as a temporary object when calling listeners. Will
>>> it make sense if we enforce MemoryRegionSection::address_space to be NULL
>>> in the array and not NULL when used temporary?
>>
>> memory_region_section_get_iotlb needs to access the AddressSpaceDispatch
>> for sections stored in the PhysPageMap array, because
>> memory_region_section_get_iotlb uses the ASD to compute the section index.
> 
> Ohhh, not extremely trivial, out of curiosity - is that iotlb encoding
> described anywhere?

No, I don't think so.

> Anyway, this can be simplified (or rather made more straightforward?) -
> tlb_set_page_with_attrs() can calculate the section index and pass it to
> memory_region_section_get_iotlb(). Still does not make much sense? It just
> looks quite useless to keep that address_space pointer alive just for one
> case which can easily avoid using this pointer.

Hmm I suppose address_space_translate_for_iotlb knows the ASD and could
also return the index, basically combining it and
memory_region_section_get_iotlb() into one function.

Paolo

  reply	other threads:[~2017-09-12  7:13 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-09-07  9:20 [Qemu-devel] [RFC PATCH qemu 0/4] memory: Reduce memory use Alexey Kardashevskiy
2017-09-07  9:20 ` [Qemu-devel] [RFC PATCH qemu 1/4] memory: Postpone flatview and dispatch tree building till all devices are added Alexey Kardashevskiy
2017-09-07  9:30   ` Peter Maydell
2017-09-07 14:27     ` Alexey Kardashevskiy
2017-09-07 14:30       ` Peter Maydell
2017-09-08  6:21         ` Alexey Kardashevskiy
2017-09-07  9:20 ` [Qemu-devel] [RFC PATCH qemu 2/4] memory: Prepare for shared flat views Alexey Kardashevskiy
2017-09-09  7:18   ` David Gibson
2017-09-10  9:17     ` Alexey Kardashevskiy
2017-09-07  9:20 ` [Qemu-devel] [RFC PATCH qemu 3/4] memory: Share flat views and dispatch trees between address spaces Alexey Kardashevskiy
2017-09-07 20:53   ` Philippe Mathieu-Daudé
2017-09-07 22:18     ` Alexey Kardashevskiy
2017-09-11  7:40   ` Paolo Bonzini
2017-09-11  9:06     ` Alexey Kardashevskiy
2017-09-11  9:37       ` Paolo Bonzini
2017-09-11 12:08         ` Alexey Kardashevskiy
2017-09-11 15:30           ` Paolo Bonzini
2017-09-12  5:55             ` Alexey Kardashevskiy
2017-09-12  7:12               ` Paolo Bonzini [this message]
2017-09-12  9:47                 ` Alexey Kardashevskiy
2017-09-07  9:20 ` [Qemu-devel] [RFC PATCH qemu 4/4] memory: Add flat views to HMP "info mtree" Alexey Kardashevskiy
2017-09-07  9:51 ` [Qemu-devel] [RFC PATCH qemu 0/4] memory: Reduce memory use Dr. David Alan Gilbert
2017-09-07 10:08   ` David Gibson
2017-09-07 14:44   ` Alexey Kardashevskiy
2017-09-07 14:54     ` Dr. David Alan Gilbert
2017-09-08  2:08       ` Alexey Kardashevskiy
2017-09-08  4:04         ` Alexey Kardashevskiy
2017-09-08 11:12         ` Dr. David Alan Gilbert

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=adb82532-59fc-5eed-0976-0a08fea56601@redhat.com \
    --to=pbonzini@redhat.com \
    --cc=aik@ozlabs.ru \
    --cc=david@gibson.dropbear.id.au \
    --cc=peter.maydell@linaro.org \
    --cc=qemu-devel@nongnu.org \
    --cc=stefanha@gmail.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).