From: Paul Durrant <Paul.Durrant@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Cc: Andrew Cooper <Andrew.Cooper3@citrix.com>,
Daniel De Graaf <dgdegra@tycho.nsa.gov>,
Wei Liu <wei.liu2@citrix.com>,
"xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
Ian Jackson <Ian.Jackson@citrix.com>
Subject: Re: [PATCH-for-4.9 v1 6/8] dm_op: convert HVMOP_set_mem_type
Date: Fri, 25 Nov 2016 14:00:28 +0000 [thread overview]
Message-ID: <793baa8f898745c5a169b0ab97d7875a@AMSPEX02CL03.citrite.net> (raw)
In-Reply-To: <58384FD102000078001224C7@prv-mh.provo.novell.com>
> -----Original Message-----
> From: Jan Beulich [mailto:JBeulich@suse.com]
> Sent: 25 November 2016 13:51
> To: Paul Durrant <Paul.Durrant@citrix.com>
> Cc: Andrew Cooper <Andrew.Cooper3@citrix.com>; Wei Liu
> <wei.liu2@citrix.com>; Ian Jackson <Ian.Jackson@citrix.com>; xen-
> devel@lists.xenproject.org; Daniel De Graaf <dgdegra@tycho.nsa.gov>
> Subject: Re: [Xen-devel] [PATCH-for-4.9 v1 6/8] dm_op: convert
> HVMOP_set_mem_type
>
> >>> On 18.11.16 at 18:14, <paul.durrant@citrix.com> wrote:
> > --- a/tools/libxc/xc_misc.c
> > +++ b/tools/libxc/xc_misc.c
> > @@ -584,28 +584,18 @@ int xc_hvm_modified_memory( int
> xc_hvm_set_mem_type(
> > xc_interface *xch, domid_t dom, hvmmem_type_t mem_type, uint64_t
> first_pfn, uint64_t nr)
> > {
> > - DECLARE_HYPERCALL_BUFFER(struct xen_hvm_set_mem_type, arg);
> > - int rc;
> > -
> > - arg = xc_hypercall_buffer_alloc(xch, arg, sizeof(*arg));
> > - if ( arg == NULL )
> > - {
> > - PERROR("Could not allocate memory for xc_hvm_set_mem_type
> hypercall");
> > - return -1;
> > - }
> > + struct xen_dm_op op;
> > + struct xen_dm_op_set_mem_type *data;
> >
> > - arg->domid = dom;
> > - arg->hvmmem_type = mem_type;
> > - arg->first_pfn = first_pfn;
> > - arg->nr = nr;
> > + op.op = DMOP_set_mem_type;
> > + data = &op.u.set_mem_type;
> >
> > - rc = xencall2(xch->xcall, __HYPERVISOR_hvm_op,
> > - HVMOP_set_mem_type,
> > - HYPERCALL_BUFFER_AS_ARG(arg));
> > -
> > - xc_hypercall_buffer_free(xch, arg);
> > + data->mem_type = mem_type;
> > + data->first_pfn = first_pfn;
> > + /* NOTE: The following assignment truncates nr to 32-bits */
> > + data->nr = nr;
>
> What strange a comment. Why don't you - again as done in the
> hvmctl series - simply correct the function's parameter type?
> (Same for xc_hvm_track_dirty_vram() and
> xc_hvm_modified_memory() then.)
Because that may cause compiler warnings in clients when they grab the new version of the header. I didn't want to have any adverse effect so just commenting that the value was being truncated (as it always has been) seemed like the best thing to do.
>
> > --- a/xen/arch/x86/hvm/dm.c
> > +++ b/xen/arch/x86/hvm/dm.c
> > @@ -160,6 +160,16 @@ static int dm_op_set_pci_link_route(struct domain
> *d, uint8_t link,
> > return 0;
> > }
> >
> > +static bool_t dm_op_allow_p2m_type_change(p2m_type_t old,
> p2m_type_t new)
>
> bool
>
Ok.
> > +{
> > + if ( p2m_is_ram(old) ||
> > + (p2m_is_hole(old) && new == p2m_mmio_dm) ||
> > + (old == p2m_ioreq_server && new == p2m_ram_rw) )
> > + return 1;
>
> true
>
> > +
> > + return 0;
>
> false (or perhaps even better a simple return statement, and perhaps
> you can by now guess where I could refer you)
>
> > +}
> > +
> > static int dm_op_modified_memory(struct domain *d, xen_pfn_t
> *first_pfn,
>
> Any reason of putting it here rather than ...
>
> > @@ -205,6 +215,79 @@ static int dm_op_modified_memory(struct domain
> *d, xen_pfn_t *first_pfn,
> > return rc;
> > }
> >
> > +
> > +static int dm_op_set_mem_type(struct domain *d, hvmmem_type_t
> mem_type,
> > + xen_pfn_t *first_pfn, unsigned int *nr)
>
> ... right before this one (the helper of which it is)?
>
No, I can move it.
> Also please don't add a second blank line above the function.
>
Yes, that's a mistake.
> > +{
> > + xen_pfn_t last_pfn = *first_pfn + *nr - 1;
> > + unsigned int iter;
> > + int rc;
> > +
> > + /* Interface types to internal p2m types */
> > + static const p2m_type_t memtype[] = {
> > + [HVMMEM_ram_rw] = p2m_ram_rw,
> > + [HVMMEM_ram_ro] = p2m_ram_ro,
> > + [HVMMEM_mmio_dm] = p2m_mmio_dm,
> > + [HVMMEM_unused] = p2m_invalid,
> > + [HVMMEM_ioreq_server] = p2m_ioreq_server
> > + };
> > +
> > + if ( (*first_pfn > last_pfn) ||
> > + (last_pfn > domain_get_maximum_gpfn(d)) )
> > + return -EINVAL;
> > +
> > + if ( mem_type >= ARRAY_SIZE(memtype) ||
> > + unlikely(mem_type == HVMMEM_unused) )
> > + return -EINVAL;
> > +
> > + iter = 0;
> > + rc = 0;
> > + while ( iter < *nr )
> > + {
> > + unsigned long pfn = *first_pfn + iter;
> > + p2m_type_t t;
> > +
> > + get_gfn_unshare(d, pfn, &t);
>
> Note the disagreement between function and parameter names.
>
It was inherited but I'll correct it.
> > + if ( p2m_is_paging(t) )
> > + {
> > + put_gfn(d, pfn);
> > + p2m_mem_paging_populate(d, pfn);
> > + rc = -EAGAIN;
> > + break;
> > + }
> > + if ( p2m_is_shared(t) )
> > + {
> > + put_gfn(d, pfn);
> > + rc = -EAGAIN;
> > + break;
> > + }
> > + if ( !dm_op_allow_p2m_type_change(t, memtype[mem_type]) )
> > + {
> > + put_gfn(d, pfn);
> > + rc = -EINVAL;
> > + break;
> > + }
>
> Why can't all of these simply be return statements?
>
> > + rc = p2m_change_type_one(d, pfn, t, memtype[mem_type]);
> > + put_gfn(d, pfn);
> > +
> > + if ( rc )
> > + break;
>
> Or, again as done you know where, fold some of those redundant
> put_gfn()s as well, by using if/else-if.
That would be neater.
>
> > +struct xen_dm_op_set_mem_type {
> > + /* IN - number of contiguous pages */
> > + uint32_t nr;
> > + /* IN - first pfn in region */
> > + uint64_t first_pfn;
> > + /* IN - new hvmmem_type_t of region */
> > + uint16_t mem_type;
> > +};
>
> mem_type should be moved up, first_pfn be aligned, and explicit
> padding be inserted.
OK.
Paul
>
> Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
next prev parent reply other threads:[~2016-11-25 14:00 UTC|newest]
Thread overview: 39+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-11-18 17:13 [PATCH-for-4.9 v1 0/8] New hypercall for device models Paul Durrant
2016-11-18 17:13 ` [PATCH-for-4.9 v1 1/8] public / x86: Introduce __HYPERCALL_dm_op Paul Durrant
2016-11-22 15:57 ` Jan Beulich
2016-11-22 16:32 ` Paul Durrant
2016-11-22 17:24 ` Jan Beulich
2016-11-22 17:29 ` Paul Durrant
2016-11-18 17:13 ` [PATCH-for-4.9 v1 2/8] dm_op: convert HVMOP_*ioreq_server* Paul Durrant
2016-11-24 17:02 ` Jan Beulich
2016-11-25 7:06 ` Jan Beulich
2016-11-25 8:47 ` Paul Durrant
2016-11-25 9:01 ` Paul Durrant
2016-11-25 9:28 ` Jan Beulich
2016-11-25 9:33 ` Paul Durrant
2016-11-18 17:13 ` [PATCH-for-4.9 v1 3/8] dm_op: convert HVMOP_track_dirty_vram Paul Durrant
2016-11-25 11:25 ` Jan Beulich
2016-11-25 11:32 ` Paul Durrant
2016-11-18 17:14 ` [PATCH-for-4.9 v1 4/8] dm_op: convert HVMOP_set_pci_intx_level, HVMOP_set_isa_irq_level, and Paul Durrant
2016-11-25 11:49 ` Jan Beulich
2016-11-25 11:55 ` Paul Durrant
2016-11-25 12:26 ` Jan Beulich
2016-11-25 13:07 ` Paul Durrant
2016-11-18 17:14 ` [PATCH-for-4.9 v1 5/8] dm_op: convert HVMOP_modified_memory Paul Durrant
2016-11-25 13:25 ` Jan Beulich
2016-11-25 13:31 ` Paul Durrant
2016-11-25 13:56 ` Jan Beulich
2016-11-18 17:14 ` [PATCH-for-4.9 v1 6/8] dm_op: convert HVMOP_set_mem_type Paul Durrant
2016-11-25 13:50 ` Jan Beulich
2016-11-25 14:00 ` Paul Durrant [this message]
2016-11-25 14:16 ` Jan Beulich
2016-11-25 14:20 ` Paul Durrant
2016-11-25 14:46 ` Jan Beulich
2016-11-25 14:56 ` Paul Durrant
2016-11-18 17:14 ` [PATCH-for-4.9 v1 7/8] dm_op: convert HVMOP_inject_trap and HVMOP_inject_msi Paul Durrant
2016-11-25 14:07 ` Jan Beulich
2016-11-25 14:13 ` Paul Durrant
2016-11-18 17:14 ` [PATCH-for-4.9 v1 8/8] x86/hvm: serialize trap injecting producer and consumer Paul Durrant
2016-11-18 17:52 ` Razvan Cojocaru
2016-11-21 7:53 ` Jan Beulich
2016-11-21 8:26 ` Paul Durrant
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=793baa8f898745c5a169b0ab97d7875a@AMSPEX02CL03.citrite.net \
--to=paul.durrant@citrix.com \
--cc=Andrew.Cooper3@citrix.com \
--cc=Ian.Jackson@citrix.com \
--cc=JBeulich@suse.com \
--cc=dgdegra@tycho.nsa.gov \
--cc=wei.liu2@citrix.com \
--cc=xen-devel@lists.xenproject.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).