xen-devel.lists.xenproject.org archive mirror
 help / color / mirror / Atom feed
From: "Chen, Tiejun" <tiejun.chen@intel.com>
To: Jan Beulich <JBeulich@suse.com>
Cc: kevin.tian@intel.com, ian.campbell@citrix.com,
	stefano.stabellini@eu.citrix.com, ian.jackson@eu.citrix.com,
	xen-devel@lists.xen.org, yang.z.zhang@intel.com
Subject: Re: [RFC][PATCH 2/5] xen:x86: introduce a new hypercall to get RMRR mappings
Date: Tue, 12 Aug 2014 18:55:41 +0800	[thread overview]
Message-ID: <53E9F2AD.1090505@intel.com> (raw)
In-Reply-To: <53E50CB4020000780002AB34@mail.emea.novell.com>

On 2014/8/8 23:45, Jan Beulich wrote:
>>>> On 07.08.14 at 13:02, <tiejun.chen@intel.com> wrote:
>> +    case XENMEM_RMRR_memory_map:
>> +    {
>> +        struct memory_map_context ctxt;
>
> ???
>
>> +        XEN_GUEST_HANDLE(e820entry_t) buffer;
>> +        XEN_GUEST_HANDLE_PARAM(e820entry_t) buffer_param;
>> +        unsigned int i;
>> +
>> +        rc = xsm_machine_memory_map(XSM_PRIV);
>
> Are you sure? Can (and should) this really not be exposed to semi-
> privileged domains?

Will fixed.

>
>> +        if ( rc )
>> +            return rc;
>> +
>> +        if ( copy_from_guest(&ctxt.map, arg, 1) )
>> +            return -EFAULT;
>> +        if ( ctxt.map.nr_entries < rmrr_e820.nr_map + 1 )
>> +            return -EINVAL;
>
> So how would the caller know how many entries are needed?
>
>> +
>> +        buffer_param = guest_handle_cast(ctxt.map.buffer, e820entry_t);
>> +        buffer = guest_handle_from_param(buffer_param, e820entry_t);
>> +        if ( !guest_handle_okay(buffer, ctxt.map.nr_entries) )
>> +            return -EFAULT;
>> +
>> +        for ( i = 0, ctxt.n = 0, ctxt.s = 0; i < rmrr_e820.nr_map; ++i, ++ctxt.n )
>
> i and ctxt.n are redundant.
>
>> +        {
>> +            if ( __copy_to_guest_offset(buffer, ctxt.n, rmrr_e820.map + i, 1) )
>> +                return -EFAULT;
>> +        }
>> +
>> +        ctxt.map.nr_entries = ctxt.n;
>> +
>> +        if ( __copy_to_guest(arg, &ctxt.map, 1) )
>
> __copy_field_to_guest() if all you need to copy back is a single field.

I will try to address all comments in next revision.

>
>> --- a/xen/arch/x86/x86_64/compat/mm.c
>> +++ b/xen/arch/x86/x86_64/compat/mm.c
>> @@ -132,6 +132,14 @@ int compat_arch_memory_op(unsigned long cmd, XEN_GUEST_HANDLE_PARAM(void) arg)
>>           break;
>>       }
>>
>> +    case XENMEM_RMRR_memory_map:
>> +    {
>> +        if ( copy_to_guest(arg, &rmrr_e820, 1) )
>> +            return -EFAULT;
>> +
>> +        return 0;
>> +    }
>
> Pointless braces. And how come this is so much simpler than the
> native version?

Just hvmloader would walk this with a hypercall, and with a test I don't 
see any issue here.

If you think this is not correct, please comment this in next revision.

>
>> --- a/xen/include/public/memory.h
>> +++ b/xen/include/public/memory.h
>> @@ -523,7 +523,15 @@ DEFINE_XEN_GUEST_HANDLE(xen_mem_sharing_op_t);
>>
>>   #endif /* defined(__XEN__) || defined(__XEN_TOOLS__) */
>>
>> -/* Next available subop number is 26 */
>> +/*
>> + * Returns the RMRR memory map as it was when the domain
>> + * was started.
>> + */
>> +#define XENMEM_RMRR_memory_map           26
>> +typedef struct e820map rmrr_e820_t;
>> +DEFINE_XEN_GUEST_HANDLE(rmrr_e820_t);
>
> Again just as a general remark: What in the world does the "e820"
> in here mean?

I will redefine a struct to represent this to avoid any confusion.

Thanks
Tiejun

>
> Jan
>
>

  reply	other threads:[~2014-08-12 10:55 UTC|newest]

Thread overview: 49+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-08-07 11:02 [RFC][PATCH 0/5] xen: reserve RMRR to avoid conflicting MMIO/RAM Tiejun Chen
2014-08-07 11:02 ` [RFC][PATCH 1/5] xen:x86: record RMRR mappings Tiejun Chen
2014-08-08 15:36   ` Jan Beulich
2014-08-11  3:04     ` Chen, Tiejun
2014-08-11  6:51       ` Jan Beulich
2014-08-11  7:00         ` Chen, Tiejun
2014-08-11  8:42           ` Jan Beulich
2014-08-07 11:02 ` [RFC][PATCH 2/5] xen:x86: introduce a new hypercall to get " Tiejun Chen
2014-08-08 15:45   ` Jan Beulich
2014-08-12 10:55     ` Chen, Tiejun [this message]
2014-08-12 12:19       ` Jan Beulich
2014-08-13  0:40         ` Chen, Tiejun
2014-08-13 18:21           ` Tian, Kevin
2014-08-14  1:07             ` Chen, Tiejun
2014-08-14 16:51               ` Jan Beulich
2014-08-15  6:13                 ` Chen, Tiejun
2014-08-07 11:02 ` [RFC][PATCH 3/5] tools:libxc: remove mmio BAR out of " Tiejun Chen
2014-08-08 15:49   ` Jan Beulich
2014-08-08 21:33     ` Tian, Kevin
2014-08-12 10:56       ` Chen, Tiejun
2014-08-12 12:21         ` Jan Beulich
2014-08-12 10:55     ` Chen, Tiejun
2014-08-07 11:02 ` [RFC][PATCH 4/5] tools:firmware:hvmloader: reserve RMRR mappings in e820 Tiejun Chen
2014-08-07 12:03   ` Andrew Cooper
2014-08-08  2:11     ` Chen, Tiejun
2014-08-08  6:42       ` Jan Beulich
2014-08-08  7:30         ` Chen, Tiejun
2014-08-08  7:43           ` Jan Beulich
2014-08-08  8:39             ` Chen, Tiejun
2014-08-08  9:01               ` Jan Beulich
2014-08-08  9:28                 ` Chen, Tiejun
2014-08-08 15:53   ` Jan Beulich
2014-08-08 15:58     ` Andrew Cooper
2014-08-11  6:48       ` Jan Beulich
2014-08-12  7:59     ` Chen, Tiejun
2014-08-08 21:47   ` Tian, Kevin
2014-08-11  6:53     ` Jan Beulich
2014-08-11 16:00       ` Tian, Kevin
2014-08-12 10:59         ` Chen, Tiejun
2014-08-12 12:25           ` Jan Beulich
2014-08-13  0:57             ` Chen, Tiejun
2014-08-13 19:10               ` Tian, Kevin
2014-08-14  3:03                 ` Chen, Tiejun
2014-08-14 23:11                   ` Tian, Kevin
2014-08-15  8:21                     ` Chen, Tiejun
2014-08-12 10:56       ` Chen, Tiejun
2014-08-12 12:22         ` Jan Beulich
2014-08-12 10:56     ` Chen, Tiejun
2014-08-07 11:02 ` [RFC][PATCH 5/5] 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=53E9F2AD.1090505@intel.com \
    --to=tiejun.chen@intel.com \
    --cc=JBeulich@suse.com \
    --cc=ian.campbell@citrix.com \
    --cc=ian.jackson@eu.citrix.com \
    --cc=kevin.tian@intel.com \
    --cc=stefano.stabellini@eu.citrix.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 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).