All of lore.kernel.org
 help / color / mirror / Atom feed
From: Igor Mammedov <imammedo@redhat.com>
To: David Hildenbrand <david@redhat.com>
Cc: "Eduardo Habkost" <ehabkost@redhat.com>,
	"Richard Henderson" <richard.henderson@linaro.org>,
	"Philippe Mathieu-Daudé" <f4bug@amsat.org>,
	"Peter Xu" <peterx@redhat.com>,
	qemu-devel@nongnu.org, "Paolo Bonzini" <pbonzini@redhat.com>
Subject: Re: [PATCH v1 2/2] memory: Update description of memory_region_is_mapped()
Date: Wed, 13 Oct 2021 11:43:42 +0200	[thread overview]
Message-ID: <20211013114342.43e99dac@redhat.com> (raw)
In-Reply-To: <067a10ee-0897-df8d-2eff-b347c5958b03@redhat.com>

On Wed, 13 Oct 2021 09:14:35 +0200
David Hildenbrand <david@redhat.com> wrote:

> On 12.10.21 12:09, David Hildenbrand wrote:
> >>
> >> The less confusing would be one where check works for any memory region
> >> involved.  
> > 
> > Exactly, so for any alias, even in-between another alias and the target.
> >   
> >>      
> >>>>
> >>>>       
> >>>>>         I am not aware of actual issues, this is rather a cleanup.
> >>>>>         
> >>>>>         Signed-off-by: David Hildenbrand <david@redhat.com>
> >>>>>
> >>>>> diff --git a/include/exec/memory.h b/include/exec/memory.h
> >>>>> index 75b4f600e3..93d0190202 100644
> >>>>> --- a/include/exec/memory.h
> >>>>> +++ b/include/exec/memory.h
> >>>>> @@ -728,6 +728,7 @@ struct MemoryRegion {
> >>>>>          const MemoryRegionOps *ops;
> >>>>>          void *opaque;
> >>>>>          MemoryRegion *container;
> >>>>> +    int mapped_via_alias; /* Mapped via an alias, container might be NULL */
> >>>>>          Int128 size;
> >>>>>          hwaddr addr;
> >>>>>          void (*destructor)(MemoryRegion *mr);
> >>>>> diff --git a/softmmu/memory.c b/softmmu/memory.c
> >>>>> index 3bcfc3899b..1168a00819 100644
> >>>>> --- a/softmmu/memory.c
> >>>>> +++ b/softmmu/memory.c
> >>>>> @@ -2535,8 +2535,13 @@ static void memory_region_add_subregion_common(MemoryRegion *mr,
> >>>>>                                                     hwaddr offset,
> >>>>>                                                     MemoryRegion *subregion)
> >>>>>      {
> >>>>> +    MemoryRegion *alias;
> >>>>> +
> >>>>>          assert(!subregion->container);
> >>>>>          subregion->container = mr;
> >>>>> +    for (alias = subregion->alias; alias; alias = alias->alias) {
> >>>>> +       alias->mapped_via_alias++;  
> >>>>
> >>>> it it necessary to update mapped_via_alias for intermediate aliases?
> >>>> Why not just update on counter only on leaf (aliased region)?  
> >>>
> >>> Assume we have alias0 -> alias1 -> region and map alias0.
> >>>
> >>> Once alias0 is mapped it will have ->container set and
> >>> memory_region_is_mapped(alias0) will return "true".
> >>>
> >>> With my patch, both, "alias1" and the region will be marked
> >>> "mapped_via_alias" and memory_region_is_mapped() will succeed on both of
> >>> them. With what you propose, memory_region_is_mapped() would only
> >>> succeed on the region (well, and on alias 0) but not on alias1.  
> >>
> >> as long as add_subregion increments counter on leaf it doesn't matter
> >> how many intermediate aliases are there. Check on every one of them
> >> should end up at the leaf counter (at expense of traversing
> >> chain on every check but less state to track/think about).
> >>  
> > 
> > Sure, we could also let memory_region_is_mapped() walk all aliases to
> > the leaf. Not sure though, if it really simplifies things. It merely
> > adds another loop and doesn't get rid of the others :) But I don't
> > particularly care.
> >   
> 
> I just realized that this might not be what we want: we could get false 
> positives when a memory region is referenced via multiple alias and only 
> one of them is mapped. memory_region_is_mapped() could return "true" for 
> an alias that isn't actually mapped.
Agreed, that would be inconsistent.



      reply	other threads:[~2021-10-13 10:04 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-10-11 17:45 [PATCH v1 0/2] memory: Update description of memory_region_is_mapped() David Hildenbrand
2021-10-11 17:45 ` [PATCH v1 1/2] machine: Use host_memory_backend_is_mapped() in machine_consume_memdev() David Hildenbrand
2021-10-11 21:16   ` Richard Henderson
2021-10-12  8:25   ` Igor Mammedov
2021-10-11 17:45 ` [PATCH v1 2/2] memory: Update description of memory_region_is_mapped() David Hildenbrand
2021-10-11 21:21   ` Richard Henderson
2021-10-11 22:17     ` Philippe Mathieu-Daudé
2021-10-12  6:50       ` David Hildenbrand
2021-10-12  8:53         ` Igor Mammedov
2021-10-12  9:28           ` David Hildenbrand
2021-10-12 10:00             ` Igor Mammedov
2021-10-12 10:09               ` David Hildenbrand
2021-10-13  7:14                 ` David Hildenbrand
2021-10-13  9:43                   ` Igor Mammedov [this message]

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=20211013114342.43e99dac@redhat.com \
    --to=imammedo@redhat.com \
    --cc=david@redhat.com \
    --cc=ehabkost@redhat.com \
    --cc=f4bug@amsat.org \
    --cc=pbonzini@redhat.com \
    --cc=peterx@redhat.com \
    --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 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.