From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([208.118.235.92]:48458)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <qemulist@gmail.com>) id 1UfVEi-0004yC-1X
	for qemu-devel@nongnu.org; Thu, 23 May 2013 09:07:21 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <qemulist@gmail.com>) id 1UfVEc-0004Tt-TG
	for qemu-devel@nongnu.org; Thu, 23 May 2013 09:07:15 -0400
Received: from mail-la0-x232.google.com ([2a00:1450:4010:c03::232]:47286)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <qemulist@gmail.com>) id 1UfVEc-0004Tm-Lw
	for qemu-devel@nongnu.org; Thu, 23 May 2013 09:07:10 -0400
Received: by mail-la0-f50.google.com with SMTP id ed20so3211208lab.37
	for <qemu-devel@nongnu.org>; Thu, 23 May 2013 06:07:09 -0700 (PDT)
MIME-Version: 1.0
In-Reply-To: <519DE876.8030503@redhat.com>
References: <1369133851-1894-1-git-send-email-pbonzini@redhat.com>
	<1369133851-1894-18-git-send-email-pbonzini@redhat.com>
	<CAJnKYQ=LVyWvoV_ygfvaZbKXE2rpKrC0yViE=rZR=PkVgmaUOw@mail.gmail.com>
	<519DE876.8030503@redhat.com>
From: liu ping fan <qemulist@gmail.com>
Date: Thu, 23 May 2013 21:06:48 +0800
Message-ID: <CAJnKYQkGBETAbgRW9qO5WMWbdDOTU-qX+4Emp_9fa+cqkRydwA@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Subject: Re: [Qemu-devel] [PATCH 17/30] memory: add address_space_translate
List-Id: <qemu-devel.nongnu.org>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Paolo Bonzini <pbonzini@redhat.com>
Cc: peter.maydell@linaro.org, David Gibson <david@gibson.dropbear.id.au>, qemu-devel@nongnu.org, jan.kiszka@gmail.com

On Thu, May 23, 2013 at 5:59 PM, Paolo Bonzini <pbonzini@redhat.com> wrote:
> Il 23/05/2013 09:09, liu ping fan ha scritto:
>>> >  void address_space_rw(AddressSpace *as, hwaddr addr, uint8_t *buf,
>>> >                        int len, bool is_write)
>>> >  {
>>> > -    AddressSpaceDispatch *d = as->dispatch;
>>> > -    int l;
>>> > +    hwaddr l;
>>> >      uint8_t *ptr;
>>> >      uint32_t val;
>>> > -    hwaddr page;
>>> > +    hwaddr addr1;
>>> >      MemoryRegionSection *section;
>>> >
>>> >      while (len > 0) {
>>> > -        page = addr & TARGET_PAGE_MASK;
>>> > -        l = (page + TARGET_PAGE_SIZE) - addr;
>>> > -        if (l > len)
>>> > -            l = len;
>>> > -        section = phys_page_find(d, page >> TARGET_PAGE_BITS);
>>> > +        l = len;
>>> > +        section = address_space_translate(as, addr, &addr1, &l, is_write);
>>> >
>> Jan's "Rework sub-page handling" patch broke the tlb_set_page
>> (anything else?)  But I think we still need a function based on
>> address_space_translate to wrap the subpage logic inside and ease the
>> incoming RCU style.
>
> The idea is that address_space_translate gets a ref to the MemoryRegion,
> and the ref is then released by the caller of address_space_translate.
>
This will require subpage hold a reference to real mr. But I think it
is needless. Maybe when later in your these series, we will see how to
resolve it.  BTW,  do you target URCU patches to 1.6

Regards,
Pingfan

> That means that the actual memory accesses can run outside the RCU
> critical section.
>
> But I'm not sure how that is related to subpage logic.  Subpages are
> simply MemoryRegions that only exist in the phys page map, rather than
> within an AddressSpace.  Their destruction will be delayed anyway by
> doing call_rcu on the old phys page map.
>
> Paolo