All of lore.kernel.org
 help / color / mirror / Atom feed
From: Julien Grall <julien.grall@linaro.org>
To: Arianna Avanzini <avanzini.arianna@gmail.com>,
	Eric Trudeau <etrudeau@broadcom.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Cc: "julien.grall@citrix.com" <julien.grall@citrix.com>,
	"dario.faggioli@citrix.com" <dario.faggioli@citrix.com>,
	"paolo.valente@unimore.it" <paolo.valente@unimore.it>,
	"viktor.kleinik@globallogic.com" <viktor.kleinik@globallogic.com>,
	"stefano.stabellini@eu.citrix.com"
	<stefano.stabellini@eu.citrix.com>
Subject: Re: [RFC PATCH 2/3] arch, arm32: add the XEN_DOMCTL_memory_mapping hypercall
Date: Fri, 07 Mar 2014 11:41:50 +0800	[thread overview]
Message-ID: <53193FFE.9080605@linaro.org> (raw)
In-Reply-To: <53191948.4090100@gmail.com>


Hello Arianna,

On 07/03/14 08:56, Arianna Avanzini wrote:
>>> Beware:  I found that map_mmio_regions was off by one page unless I changed
>>> "gfn + nr_mfns - 1" to "gfn + nr_mfns".
>>> This may have been fixed in more recent upstream code.
>>
>> That makes me think, map_mmio_regions is buggy if the range is not correctly
>> aligned. For instance:
>>
>> start_gaddr = 0x1001 and end_gaddr = 0x2001, we only map 0x1000-0x2000 to the
>> domain.
>>
>> The problem is the same with p2m_populate_ram (even if I doubt that RAM range is
>> not page-aligned).
>>
>> I see 2 solutions to fix it:
>>      - Change map_mmio_regions prototype to use frame is instead address.
>>          - Aligned the input addresses.
>>
>> IHMO, the former seems to be better, at least it avoid developer to discover
>> that some bits was mapped under his feet.
>>
>
> Sorry if I intrude here, thank you for pointing that out. As of now I have tried
> to simply pass aligned addresses to map_mmio_regions() when it is invoked by the
> memory_mapping hypercall.

FYI, the end address should be PAGE-aligned minus 1. Otherwise you will 
map a spurious page to the guest.

> Sorry for the additional question, do you think that it would be appropriate to
> add to the series a patch implementing one of the above-described solutions (the
> one believed to be better)?

I'd like to have some input from Ian before. I think for now it's fine 
to stay with the current implementation.

Regards,

-- 
Julien Grall

  reply	other threads:[~2014-03-07  3:41 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-03-02  0:49 [RFC PATCH 0/3] Implement the XEN_DOMCTL_memory_mapping hypecall for arm32 Arianna Avanzini
2014-03-02  0:49 ` [RFC PATCH 1/3] arch, arm32: add definition of paddr_bits Arianna Avanzini
2014-03-02  8:13   ` Julien Grall
2014-03-07  0:36     ` Arianna Avanzini
2014-03-02  0:49 ` [RFC PATCH 2/3] arch, arm32: add the XEN_DOMCTL_memory_mapping hypercall Arianna Avanzini
2014-03-02  9:56   ` Julien Grall
2014-03-03 11:56     ` Dario Faggioli
2014-03-03 15:20       ` Julien Grall
2014-03-03 15:33         ` Dario Faggioli
2014-03-04  2:42           ` Julien Grall
2014-03-07  0:47             ` Arianna Avanzini
2014-03-03 16:25         ` Eric Trudeau
2014-03-03 16:35           ` Dario Faggioli
2014-03-03 19:04             ` Eric Trudeau
2014-03-05 13:59     ` Arianna Avanzini
2014-03-06  3:41       ` Julien Grall
2014-03-07  0:57         ` Arianna Avanzini
2014-03-03 18:06   ` Eric Trudeau
2014-03-04  3:08     ` Julien Grall
2014-03-07  0:56       ` Arianna Avanzini
2014-03-07  3:41         ` Julien Grall [this message]
2014-03-07 19:49           ` Arianna Avanzini
2014-03-02  0:49 ` [RFC PATCH 3/3] tools, libxl: handle the iomem parameter with the memory_mapping hcall Arianna Avanzini
2014-03-02 10:33   ` Julien Grall
2014-03-02 11:27     ` Ian Campbell
2014-03-03 10:32       ` Dario Faggioli
2014-03-03 15:13         ` Julien Grall
2014-03-07  0:45           ` Arianna Avanzini
2014-03-07  4:03             ` Julien Grall
2014-03-07 19:54               ` Arianna Avanzini
2014-03-03 11:19     ` Dario Faggioli
2014-03-07  4:05       ` Julien Grall
2014-03-02  8:13 ` [RFC PATCH 0/3] Implement the XEN_DOMCTL_memory_mapping hypecall for arm32 Julien Grall

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=53193FFE.9080605@linaro.org \
    --to=julien.grall@linaro.org \
    --cc=avanzini.arianna@gmail.com \
    --cc=dario.faggioli@citrix.com \
    --cc=etrudeau@broadcom.com \
    --cc=julien.grall@citrix.com \
    --cc=paolo.valente@unimore.it \
    --cc=stefano.stabellini@eu.citrix.com \
    --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.