xen-devel.lists.xenproject.org archive mirror
 help / color / mirror / Atom feed
From: Arianna Avanzini <avanzini.arianna@gmail.com>
To: Jan Beulich <JBeulich@suse.com>
Cc: Ian.Campbell@eu.citrix.com, paolo.valente@unimore.it,
	keir@xen.org, stefano.stabellini@eu.citrix.com, tim@xen.org,
	dario.faggioli@citrix.com, Ian.Jackson@eu.citrix.com,
	xen-devel@lists.xen.org, julien.grall@citrix.com,
	etrudeau@broadcom.com, viktor.kleinik@globallogic.com
Subject: Re: [PATCH v4 4/7] xen, common: add the XEN_DOMCTL_memory_mapping hypercall
Date: Fri, 28 Mar 2014 14:24:18 +0100	[thread overview]
Message-ID: <53357802.1050707@gmail.com> (raw)
In-Reply-To: <53315B620200007800001A12@nat28.tlf.novell.com>

On 03/25/2014 10:33 AM, Jan Beulich wrote:
>>>> On 25.03.14 at 03:02, <avanzini.arianna@gmail.com> wrote:
>> +int unmap_mmio_regions(struct domain *d,
>> +                       unsigned long start_gfn,
>> +                       unsigned long end_gfn,
>> +                       unsigned long mfn)
>> +{
>> +    int ret = 0;
>> +    unsigned long nr_mfns = end_gfn - start_gfn + 1;
>> +    unsigned long i;
>> +
>> +    if ( !paging_mode_translate(d) )
>> +        return 0;
>> +
>> +    for ( i = 0; i < nr_mfns; i++ )
>> +        ret |= !clear_mmio_p2m_entry(d, start_gfn + i);
>> +
>> +    return ret;
>> +}
> 
> Either you keep the function returning a boolean value (but then
> please the more conventional 1=success 0=failure), in which case
> the function return type should be bool_t, or you make the
> function return a proper error code (and propagate that as
> necessary in the caller).
> 
> Furthermore the mfn parameter is unused here (and effectively
> unused also in the ARM variant - it's meaningful only when passing
> INSERT to apply_p2m_changes()), so please drop it.
> 

Thank you for the detailed feedback, I will certainly try to address the issues
you pointed out. Sorry if I bother you with a question on this hunk.
Patch 0002 added to the REMOVE case of apply_p2m_changes() a consistency check
which makes use of the mfn parameter. More in detail, the function should check
whether the mappings to be removed actually involve the gfn and mfn ranges
passed as parameters.
Do you think it is acceptable to keep the mfn parameter to this purpose? In case
you think it is useful/necessary, would you prefer a similar check to be
performed also someplace in the x86-related code?

>> +    case XEN_DOMCTL_memory_mapping:
>> +    {
>> +        unsigned long gfn = op->u.memory_mapping.first_gfn;
>> +        unsigned long mfn = op->u.memory_mapping.first_mfn;
>> +        unsigned long nr_mfns = op->u.memory_mapping.nr_mfns;
>> +        unsigned long mfn_end = mfn + nr_mfns;
>> +        unsigned long gfn_end = gfn + nr_mfns;
> 
> Afaics all uses of [gm]fn_end involve subtracting 1 - please do this
> right here if you already introduce these helper variables.
> 
>> --- /dev/null
>> +++ b/xen/include/xen/p2m.h
>> @@ -0,0 +1,16 @@
>> +#ifndef _XEN_P2M_COMMON_H
>> +#define _XEN_P2M_COMMON_H
> 
> You're on the right track with the guard - please name the header
> p2m-common.h, so that it won't violate the common inclusion
> hierarchy of the common header including the corresponding arch
> one. The alternative would be to keep the name, rename the guard,
> and replace all relevant (not necessarily all) #include <asm/p2m.h>
> with #include <xen/p2m.h>.
> 
> Jan
> 


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

  reply	other threads:[~2014-03-28 13:24 UTC|newest]

Thread overview: 50+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-03-25  2:02 [PATCH v4 0/7] Implement the XEN_DOMCTL_memory_mapping hypercall for ARM Arianna Avanzini
2014-03-25  2:02 ` [PATCH v4 1/7] arch, arm: domain build: let dom0 access I/O memory of mapped devices Arianna Avanzini
2014-03-25 12:37   ` Julien Grall
2014-03-25  2:02 ` [PATCH v4 2/7] arch, arm: add consistency checks to REMOVE p2m changes Arianna Avanzini
2014-03-25 12:18   ` Stefano Stabellini
2014-03-25 12:51   ` Julien Grall
2014-03-25 13:10     ` Julien Grall
2014-03-25 17:41   ` Ian Campbell
2014-03-25  2:02 ` [PATCH v4 3/7] arch, arm: let map_mmio_regions() take pfn as parameters Arianna Avanzini
2014-03-25 12:22   ` Stefano Stabellini
2014-03-25 12:54     ` Julien Grall
2014-03-28 12:51       ` Arianna Avanzini
2014-03-28 13:31         ` Julien Grall
2014-03-25 13:00   ` Julien Grall
2014-03-25  2:02 ` [PATCH v4 4/7] xen, common: add the XEN_DOMCTL_memory_mapping hypercall Arianna Avanzini
2014-03-25  9:33   ` Jan Beulich
2014-03-28 13:24     ` Arianna Avanzini [this message]
2014-03-28 13:30       ` Jan Beulich
2014-03-25 12:35   ` Stefano Stabellini
2014-03-25 14:10     ` Jan Beulich
2014-03-25 15:10       ` Stefano Stabellini
2014-03-25 15:36         ` Jan Beulich
2014-03-25 15:42           ` Stefano Stabellini
2014-04-01 15:01             ` Ian Campbell
2014-04-01 15:18               ` Jan Beulich
2014-04-01 15:37                 ` Ian Campbell
2014-03-25 13:17   ` Julien Grall
2014-04-01 14:52     ` Ian Campbell
2014-04-01 15:16       ` Julien Grall
2014-04-01 15:39         ` Ian Campbell
2014-04-01 16:00           ` Julien Grall
2014-04-02  9:43             ` Ian Campbell
2014-04-02 10:06               ` Jan Beulich
2014-04-02 10:19                 ` Ian Campbell
2014-04-02 10:53                   ` Jan Beulich
2014-04-05 12:08                     ` Arianna Avanzini
2014-04-06 16:23                       ` Stefano Stabellini
2014-04-07  7:01                       ` Jan Beulich
2014-03-25  2:02 ` [PATCH v4 5/7] tools, libxl: parse optional start gfn from the iomem config option Arianna Avanzini
2014-03-25 15:39   ` Julien Grall
2014-03-25 15:45     ` Julien Grall
2014-03-25 16:27     ` Ian Campbell
2014-03-25  2:02 ` [PATCH v4 6/7] tools, libxl: add helpers to establish if guest is auto-translated Arianna Avanzini
2014-03-25  2:02 ` [PATCH v4 7/7] tools, libxl: handle the iomem parameter with the memory_mapping hcall Arianna Avanzini
2014-04-01 15:13   ` Ian Campbell
2014-04-01 15:26     ` Julien Grall
2014-04-01 15:34       ` Ian Campbell
2014-04-01 20:52       ` Daniel De Graaf
2014-04-02  9:45         ` Ian Campbell
2014-04-02 14:14           ` Daniel De Graaf

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=53357802.1050707@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 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).