All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Jan Beulich" <JBeulich@suse.com>
To: Tiejun Chen <tiejun.chen@intel.com>
Cc: kevin.tian@intel.com, ian.campbell@citrix.com,
	stefano.stabellini@eu.citrix.com, andrew.cooper3@citrix.com,
	ian.jackson@eu.citrix.com, xen-devel@lists.xen.org,
	yang.z.zhang@intel.com
Subject: Re: [v5][PATCH 03/10] xen:x86: define a new hypercall to get RMRR mappings
Date: Tue, 02 Sep 2014 09:25:52 +0100	[thread overview]
Message-ID: <54059B30020000780002FB93@mail.emea.novell.com> (raw)
In-Reply-To: <1409050980-21933-4-git-send-email-tiejun.chen@intel.com>

>>> On 26.08.14 at 13:02, <tiejun.chen@intel.com> wrote:
> @@ -4842,6 +4843,54 @@ long arch_memory_op(unsigned long cmd, XEN_GUEST_HANDLE_PARAM(void) arg)
>          return rc;
>      }
>  
> +    case XENMEM_reserved_device_memory_map:
> +    {
> +        struct xen_mem_reserved_device_memory_map map;
> +        XEN_GUEST_HANDLE(xen_mem_reserved_device_memory_t) buffer;
> +        XEN_GUEST_HANDLE_PARAM(xen_mem_reserved_device_memory_t) buffer_param;
> +        unsigned int i = 0;
> +        static struct xen_mem_reserved_device_memory rmrr_map;
> +        struct acpi_rmrr_unit *rmrr;
> +
> +        if ( copy_from_guest(&map, arg, 1) )
> +            return -EFAULT;
> +
> +        if ( !acpi_rmrr_unit_entries )
> +                return -ENOENT;
> +
> +        if ( map.nr_entries < acpi_rmrr_unit_entries )
> +        {
> +            map.nr_entries = acpi_rmrr_unit_entries;
> +            if ( copy_to_guest(arg, &map, 1) )
> +                return -EFAULT;
> +            return -ENOBUFS;
> +        }
> +
> +        map.nr_entries = acpi_rmrr_unit_entries;
> +        buffer_param = guest_handle_cast(map.buffer,
> +                                         xen_mem_reserved_device_memory_t);
> +        buffer = guest_handle_from_param(buffer_param,
> +                                         xen_mem_reserved_device_memory_t);
> +        if ( !guest_handle_okay(buffer, map.nr_entries) )
> +            return -EFAULT;
> +
> +        list_for_each_entry( rmrr, &acpi_rmrr_units, list )
> +        {
> +            rmrr_map.start_pfn = rmrr->base_address >> PAGE_SHIFT;
> +            rmrr_map.nr_pages = PAGE_ALIGN(rmrr->end_address -
> +                                           rmrr->base_address) /
> +                                           PAGE_SIZE;
> +            if ( copy_to_guest_offset(buffer, i, &rmrr_map, 1) )
> +                return -EFAULT;
> +            i++;
> +        }

So as said before, a callback based mechanism will serve you quite
fine here. However, you're not obeying to the buffer size the
caller passed in (i.e. you may corrupt guest memory). And having
used guest_handle_okay() in the loop (which will get moved into
the callback function) you can then use __copy_to_guest_offset().

> +
> +        if ( copy_to_guest(arg, &map, 1) )
> +                return -EFAULT;

As much as, due to the earlier copy_from_guest() on the same
handle, you can use __copy_to_guest() here. For mechanical
things like these please consult other code - there are plenty of
useful examples throughout the tree.

> +struct xen_mem_reserved_device_memory_map {
> +    /*
> +     * On call the number of entries which can be stored in buffer. On
> +     * return the number of entries which have been stored in
> +     * buffer.
> +     */
> +    unsigned int nr_entries;
> +
> +    /*
> +     * Entries in the buffer are in the same format as
> +     * xen_mem_reserved_device_memory.
> +     */
> +    XEN_GUEST_HANDLE(void) buffer;

I think I had asked before that you use a properly typed handle here,
saving you from needing convoluted conversion code as you have
above.

Jan

  parent reply	other threads:[~2014-09-02  8:25 UTC|newest]

Thread overview: 53+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-08-26 11:02 [v5][PATCH 0/10] xen: reserve RMRR to avoid conflicting MMIO/RAM Tiejun Chen
2014-08-26 11:02 ` [v5][PATCH 01/10] xen:vtd:rmrr: export acpi_rmrr_units Tiejun Chen
2014-08-26 11:02 ` [v5][PATCH 02/10] xen:vtd:rmrr: introduce acpi_rmrr_unit_entries Tiejun Chen
2014-08-26 11:02 ` [v5][PATCH 03/10] xen:x86: define a new hypercall to get RMRR mappings Tiejun Chen
2014-08-26 12:02   ` Andrew Cooper
2014-08-26 12:37     ` Jan Beulich
2014-08-27  1:37       ` Chen, Tiejun
2014-08-27  6:51         ` Jan Beulich
2014-08-27  7:21           ` Chen, Tiejun
2014-08-28  2:24             ` Chen, Tiejun
2014-08-28  6:50               ` Jan Beulich
2014-08-28  7:09                 ` Chen, Tiejun
2014-08-28  7:19                   ` Chen, Tiejun
2014-08-28  7:29                     ` Chen, Tiejun
2014-08-28  7:44                     ` Jan Beulich
2014-08-29  3:02                       ` Chen, Tiejun
2014-08-29  9:18                         ` Jan Beulich
2014-09-01  9:44                           ` Chen, Tiejun
2014-09-01 10:29                             ` Jan Beulich
2014-09-02  9:59                               ` Chen, Tiejun
2014-09-02 10:15                                 ` Jan Beulich
2014-09-02 11:10                                   ` Chen, Tiejun
2014-09-02 13:15                                     ` Jan Beulich
2014-09-03  1:45                                       ` Chen, Tiejun
2014-09-03  8:31                                         ` Chen, Tiejun
2014-09-03  8:41                                           ` Jan Beulich
2014-09-03  8:59                                             ` Chen, Tiejun
2014-09-03  9:01                                               ` Chen, Tiejun
2014-09-03  9:54                                                 ` Chen, Tiejun
2014-09-03 12:54                                             ` Jan Beulich
2014-09-04  1:15                                               ` Chen, Tiejun
2014-09-03  8:35                                         ` Jan Beulich
2014-08-27  1:15     ` Chen, Tiejun
2014-09-02  8:25   ` Jan Beulich [this message]
2014-08-26 11:02 ` [v5][PATCH 04/10] tools:libxc: introduce hypercall for xc_reserved_device_memory_map Tiejun Chen
2014-08-26 11:02 ` [v5][PATCH 05/10] tools:libxc: check if mmio BAR is out of RMRR mappings Tiejun Chen
2014-08-26 11:02 ` [v5][PATCH 06/10] hvm_info_table: introduce nr_reserved_device_memory_map Tiejun Chen
2014-09-02  8:34   ` Jan Beulich
2014-09-04  2:07     ` Chen, Tiejun
2014-09-04  6:32       ` Jan Beulich
2014-09-04  6:55         ` Chen, Tiejun
     [not found]           ` <54082E3B0200007800030BCB@mail.emea.novell.com>
2014-09-09  6:40             ` Chen, Tiejun
2014-08-26 11:02 ` [v5][PATCH 07/10] xen:x86:: support xc_reserved_device_memory_map in compat case Tiejun Chen
2014-09-02  8:35   ` Jan Beulich
2014-09-04  2:13     ` Chen, Tiejun
2014-08-26 11:02 ` [v5][PATCH 08/10] tools:firmware:hvmloader: introduce hypercall for xc_reserved_device_memory_map Tiejun Chen
2014-09-02  8:37   ` Jan Beulich
2014-08-26 11:02 ` [v5][PATCH 09/10] tools:firmware:hvmloader: check to reserve RMRR mappings in e820 Tiejun Chen
2014-09-02  8:47   ` Jan Beulich
2014-09-04  3:04     ` Chen, Tiejun
2014-09-04  4:32       ` Chen, Tiejun
2014-09-04  6:36       ` Jan Beulich
2014-08-26 11:03 ` [v5][PATCH 10/10] xen:vtd: make USB RMRR mapping safe Tiejun Chen

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=54059B30020000780002FB93@mail.emea.novell.com \
    --to=jbeulich@suse.com \
    --cc=andrew.cooper3@citrix.com \
    --cc=ian.campbell@citrix.com \
    --cc=ian.jackson@eu.citrix.com \
    --cc=kevin.tian@intel.com \
    --cc=stefano.stabellini@eu.citrix.com \
    --cc=tiejun.chen@intel.com \
    --cc=xen-devel@lists.xen.org \
    --cc=yang.z.zhang@intel.com \
    /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.