All of lore.kernel.org
 help / color / mirror / Atom feed
From: Arianna Avanzini <avanzini.arianna@gmail.com>
To: Ian Campbell <Ian.Campbell@eu.citrix.com>
Cc: paolo.valente@unimore.it, keir@xen.org,
	stefano.stabellini@eu.citrix.com, Ian.Jackson@eu.citrix.com,
	dario.faggioli@citrix.com, tim@xen.org, xen-devel@lists.xen.org,
	julien.grall@citrix.com, etrudeau@broadcom.com,
	JBeulich@suse.com, viktor.kleinik@globallogic.com
Subject: Re: [PATCH v5 3/8] arch, arm: let map_mmio_regions() take pfn as parameters
Date: Sat, 12 Apr 2014 11:20:46 +0200	[thread overview]
Message-ID: <5349056E.7050008@gmail.com> (raw)
In-Reply-To: <1397051683.6275.71.camel@kazak.uk.xensource.com>

Hello,

thank you for your comments, and sorry for the huge delay in replying.

On 04/09/2014 03:54 PM, Ian Campbell wrote:
> On Mon, 2014-04-07 at 01:31 +0200, Arianna Avanzini wrote:
>> -        res = map_mmio_regions(d, addr & PAGE_MASK,
>> -                               PAGE_ALIGN(addr + size) - 1,
>> -                               addr & PAGE_MASK);
>> +        res = map_mmio_regions(d,
>> +                               paddr_to_pfn(addr & PAGE_MASK),
>> +                               paddr_to_pfn_aligned(addr + size - 1),
> 
> 
> With
> +#define paddr_to_pfn_aligned(paddr)    paddr_to_pfn(PAGE_ALIGN(paddr))
> 
> There is a subtle difference here, which is that the "- 1" is now inside
> the align. Does this always have the same result? I'm not sure.
> 
> If addr+size == 0x1000 (page aligned) then:
> 
>         PAGE_ALIGN(0x10000)-1 = 0x10000-1 = 0xffff
> 
> But
> 
>         paddr_to_pfn_aligned(0x10000 - 1) =
>         paddr_to_pfn(PAGE_ALIGN(0xffff)) = paddr_to_pfn(0x10000) = 0x10
> 
> The new map_mmio_regions uses pfn_to_paddr which is:
> #define pfn_to_paddr(pfn) ((paddr_t)(pfn) << PAGE_SHIFT)
> 
> So with the old code the end address would be 0xffff, while with the new
> code it is 0x10<<12 = 0x10000.
> 
> I suspect the implementation of apply_to_p2m_changes is such that it
> doesn't actually change anything. Can you confirm that this was your
> intention?
> 

It wasn't my intention to change the size of the address range to be mapped,
thank you for pointing that out. As far as I can understand, the changes in this
patch would let apply_p2m_changes() use one extra address for the mapping; sorry
for that.

While preparing the patch I saw that, e.g., with addr + size = 0x10000,

end_gfn = paddr_to_pfn(PAGE_ALIGN(0x10000) - 1) =
          paddr_to_pfn(PAGE_ALIGN(0x10000)) - 1 = 0xf

and

pfn_to_paddr(end_gfn) = 0xf000

which seemed to me to be wrong, as the previous end address was, as you wrote,
0xffff.

Instead, if

end_gfn = paddr_to_pfn(PAGE_ALIGN(0x10000 - 1)) = 0x10

then

pfn_to_paddr(end_gfn) = 0x10000

which I thought lets the needed address range be mapped; however I didn't see
what you pointed out, that it also lets one extra address be used for the mapping.

> Is the end argument tio map_mmio_regions now intended to be inclusive or
> exclusive? 

As far as I understand, apply_p2m_changes(), which is called by the ARM version
of map_mmio_regions(), seems to take it as exclusive, as the mapping is
performed while (addr < end_gpaddr).
In the x86 version of map_mmio_regions() it is instead intended to be inclusive;
sorry for this mismatch, I'll try to make the behavior of the two versions
consistent.

> This sort of issue can be avoided by using a count instead of
> an end in the interface.
> 

Thank you very much for the hint.


> Ian.
> 



-- 
/*
 * Arianna Avanzini
 * avanzini.arianna@gmail.com
 * 73628@studenti.unimore.it
 */

  reply	other threads:[~2014-04-12  9:20 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-04-06 23:31 [PATCH v5 0/8] Implement the XEN_DOMCTL_memory_mapping hypercall for ARM Arianna Avanzini
2014-04-06 23:31 ` [PATCH v5 1/8] arch, arm: domain build: let dom0 access I/O memory of mapped devices Arianna Avanzini
2014-04-06 23:31 ` [PATCH v5 2/8] arch, arm: add consistency check to REMOVE p2m changes Arianna Avanzini
2014-04-07 11:05   ` Julien Grall
2014-04-09 13:39     ` Ian Campbell
2014-04-22 19:27       ` Julien Grall
2014-04-06 23:31 ` [PATCH v5 3/8] arch, arm: let map_mmio_regions() take pfn as parameters Arianna Avanzini
2014-04-07 14:56   ` Julien Grall
2014-04-09 13:54   ` Ian Campbell
2014-04-12  9:20     ` Arianna Avanzini [this message]
2014-04-06 23:31 ` [PATCH v5 4/8] arch, x86: check if mapping exists before memory_mapping removes it Arianna Avanzini
2014-04-06 23:31 ` [PATCH v5 5/8] xen, common: add the XEN_DOMCTL_memory_mapping hypercall Arianna Avanzini
2014-04-07  7:55   ` Jan Beulich
2014-04-09 14:03   ` Ian Campbell
2014-04-06 23:31 ` [PATCH v5 6/8] tools, libxl: parse optional start gfn from the iomem config option Arianna Avanzini
2014-04-09 14:10   ` Ian Campbell
2014-04-06 23:31 ` [PATCH v5 7/8] tools, libxl: add helpers to establish if guest is auto-translated Arianna Avanzini
2014-04-06 23:32 ` [PATCH v5 8/8] tools, libxl: handle the iomem parameter with the memory_mapping hcall Arianna Avanzini
2014-04-09 14:25   ` Ian Campbell

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=5349056E.7050008@gmail.com \
    --to=avanzini.arianna@gmail.com \
    --cc=Ian.Campbell@eu.citrix.com \
    --cc=Ian.Jackson@eu.citrix.com \
    --cc=JBeulich@suse.com \
    --cc=dario.faggioli@citrix.com \
    --cc=etrudeau@broadcom.com \
    --cc=julien.grall@citrix.com \
    --cc=keir@xen.org \
    --cc=paolo.valente@unimore.it \
    --cc=stefano.stabellini@eu.citrix.com \
    --cc=tim@xen.org \
    --cc=viktor.kleinik@globallogic.com \
    --cc=xen-devel@lists.xen.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.