All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrew Cooper <andrew.cooper3@citrix.com>
To: Petre Pircalabu <ppircalabu@bitdefender.com>,
	xen-devel@lists.xenproject.org
Cc: Ian Jackson <ian.jackson@eu.citrix.com>, Wei Liu <wl@xen.org>
Subject: Re: [PATCH 1/9] tools/libxc: Consistent usage of xc_vm_event_* interface
Date: Fri, 31 May 2019 16:01:33 -0700	[thread overview]
Message-ID: <9119ed35-e90c-c91e-2138-e2f9afa17d6f@citrix.com> (raw)
In-Reply-To: <a7acd18a3c4bcd288338de12d13ce1cb9fb6d8b2.1559224640.git.ppircalabu@bitdefender.com>

On 30/05/2019 07:18, Petre Pircalabu wrote:
> Modified xc_mem_paging_enable to use directly xc_vm_event_enable and
> moved the ring_page handling from client to libxc (xenpaging).
>
> Restricted vm_event_control usage only to simplest domctls which do
> not expect any return values and change xc_vm_event_enable to call do_domctl
> directly.
>
> Removed xc_memshr_ring_enable/disable and xc_memshr_domain_resume.
>
> Signed-off-by: Petre Pircalabu <ppircalabu@bitdefender.com>
> ---
>  tools/libxc/include/xenctrl.h | 49 +--------------------------------
>  tools/libxc/xc_mem_paging.c   | 23 +++++-----------
>  tools/libxc/xc_memshr.c       | 34 -----------------------
>  tools/libxc/xc_monitor.c      | 31 +++++++++++++++++----
>  tools/libxc/xc_private.h      |  2 +-
>  tools/libxc/xc_vm_event.c     | 64 ++++++++++++++++---------------------------
>  tools/xenpaging/xenpaging.c   | 42 +++-------------------------

So, the diffstat here is very impressive, and judging by the delta, its
all about not opencoding the use of the HVM_PARAM interface.  Overall,
this is clearly a good thing.

However, it is quite difficult to follow exactly what is going on.

AFAICT, this wants splitting into $N patches.

One patch should refactor xc_mem_paging_enable() to use
xc_vm_event_enable(), with the associated xenpaging cleanup.

One patch should be the deletion of xc_memshr_* on its own, because
AFAICT it is an isolated change.  It also needs some justification, even
if it is "interface is unused and/or redundant with $X".

One patch (alone) should be the repositioning of the domain_pause()
calls.  This does certainly look like a vast improvement WRT error
handling in xc_vm_event_enable(), but you've definitely changed the API
(insofar as the expectation that the caller has paused the domain) goes,
and its not at all obvious that this change is safe.  It may very well
be, but you need to convince people as to why in the commit message.


I still haven't figured out what the purpose behind dropping the port
parameter from xc_vm_event_control() is.

~Andrew

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

WARNING: multiple messages have this Message-ID (diff)
From: Andrew Cooper <andrew.cooper3@citrix.com>
To: Petre Pircalabu <ppircalabu@bitdefender.com>,
	<xen-devel@lists.xenproject.org>
Cc: Ian Jackson <ian.jackson@eu.citrix.com>, Wei Liu <wl@xen.org>
Subject: Re: [Xen-devel] [PATCH 1/9] tools/libxc: Consistent usage of xc_vm_event_* interface
Date: Fri, 31 May 2019 16:01:33 -0700	[thread overview]
Message-ID: <9119ed35-e90c-c91e-2138-e2f9afa17d6f@citrix.com> (raw)
Message-ID: <20190531230133.ME-8yCOYFVYA36ERtwO8ZlVOabkQDTVozhI6tYKoiWU@z> (raw)
In-Reply-To: <a7acd18a3c4bcd288338de12d13ce1cb9fb6d8b2.1559224640.git.ppircalabu@bitdefender.com>

On 30/05/2019 07:18, Petre Pircalabu wrote:
> Modified xc_mem_paging_enable to use directly xc_vm_event_enable and
> moved the ring_page handling from client to libxc (xenpaging).
>
> Restricted vm_event_control usage only to simplest domctls which do
> not expect any return values and change xc_vm_event_enable to call do_domctl
> directly.
>
> Removed xc_memshr_ring_enable/disable and xc_memshr_domain_resume.
>
> Signed-off-by: Petre Pircalabu <ppircalabu@bitdefender.com>
> ---
>  tools/libxc/include/xenctrl.h | 49 +--------------------------------
>  tools/libxc/xc_mem_paging.c   | 23 +++++-----------
>  tools/libxc/xc_memshr.c       | 34 -----------------------
>  tools/libxc/xc_monitor.c      | 31 +++++++++++++++++----
>  tools/libxc/xc_private.h      |  2 +-
>  tools/libxc/xc_vm_event.c     | 64 ++++++++++++++++---------------------------
>  tools/xenpaging/xenpaging.c   | 42 +++-------------------------

So, the diffstat here is very impressive, and judging by the delta, its
all about not opencoding the use of the HVM_PARAM interface.  Overall,
this is clearly a good thing.

However, it is quite difficult to follow exactly what is going on.

AFAICT, this wants splitting into $N patches.

One patch should refactor xc_mem_paging_enable() to use
xc_vm_event_enable(), with the associated xenpaging cleanup.

One patch should be the deletion of xc_memshr_* on its own, because
AFAICT it is an isolated change.  It also needs some justification, even
if it is "interface is unused and/or redundant with $X".

One patch (alone) should be the repositioning of the domain_pause()
calls.  This does certainly look like a vast improvement WRT error
handling in xc_vm_event_enable(), but you've definitely changed the API
(insofar as the expectation that the caller has paused the domain) goes,
and its not at all obvious that this change is safe.  It may very well
be, but you need to convince people as to why in the commit message.


I still haven't figured out what the purpose behind dropping the port
parameter from xc_vm_event_control() is.

~Andrew

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

  reply	other threads:[~2019-05-31 23:01 UTC|newest]

Thread overview: 67+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-05-30 14:18 [PATCH 0/9] Per vcpu vm_event channels Petre Pircalabu
2019-05-30 14:18 ` [Xen-devel] " Petre Pircalabu
2019-05-30 14:18 ` [PATCH 1/9] tools/libxc: Consistent usage of xc_vm_event_* interface Petre Pircalabu
2019-05-30 14:18   ` [Xen-devel] " Petre Pircalabu
2019-05-31 23:01   ` Andrew Cooper [this message]
2019-05-31 23:01     ` Andrew Cooper
2019-06-04 14:23     ` Petre Ovidiu PIRCALABU
2019-06-04 16:07       ` Andrew Cooper
2019-05-30 14:18 ` [PATCH 2/9] vm_event: Define VM_EVENT type Petre Pircalabu
2019-05-30 14:18   ` [Xen-devel] " Petre Pircalabu
2019-05-31 23:26   ` Andrew Cooper
2019-05-31 23:26     ` [Xen-devel] " Andrew Cooper
2019-06-03 22:22     ` Tamas K Lengyel
2019-06-03 22:22       ` [Xen-devel] " Tamas K Lengyel
2019-06-03 22:26       ` Tamas K Lengyel
2019-06-03 22:26         ` [Xen-devel] " Tamas K Lengyel
2019-06-04 16:09         ` Andrew Cooper
2019-06-04 10:12     ` Petre Ovidiu PIRCALABU
2019-06-04 10:12       ` [Xen-devel] " Petre Ovidiu PIRCALABU
2019-06-03 15:51   ` Jan Beulich
2019-06-03 15:51     ` [Xen-devel] " Jan Beulich
2019-05-30 14:18 ` [PATCH 3/9] vm_event: Make ‘local’ functions ‘static’ Petre Pircalabu
2019-05-30 14:18   ` [Xen-devel] " Petre Pircalabu
2019-05-31 23:28   ` Andrew Cooper
2019-05-31 23:28     ` [Xen-devel] " Andrew Cooper
2019-06-02  0:36   ` Tamas K Lengyel
2019-06-02  0:36     ` [Xen-devel] " Tamas K Lengyel
2019-05-30 14:18 ` [PATCH 4/9] vm_event: Remove "ring" suffix from vm_event_check_ring Petre Pircalabu
2019-05-30 14:18   ` [Xen-devel] " Petre Pircalabu
2019-05-31 23:32   ` Andrew Cooper
2019-05-31 23:32     ` [Xen-devel] " Andrew Cooper
2019-06-05 15:52   ` Tamas K Lengyel
2019-05-30 14:18 ` [PATCH 5/9] vm_event: Simplify vm_event interface Petre Pircalabu
2019-05-30 14:18   ` [Xen-devel] " Petre Pircalabu
2019-05-31 23:43   ` Andrew Cooper
2019-05-31 23:43     ` [Xen-devel] " Andrew Cooper
2019-06-01  0:06     ` Andrew Cooper
2019-06-01  0:06       ` [Xen-devel] " Andrew Cooper
2019-06-03 15:33       ` Petre Ovidiu PIRCALABU
2019-06-03 15:33         ` [Xen-devel] " Petre Ovidiu PIRCALABU
2019-05-30 14:18 ` [PATCH 6/9] vm_event: Move struct vm_event_domain to vm_event.c Petre Pircalabu
2019-05-30 14:18   ` [Xen-devel] " Petre Pircalabu
2019-05-31 23:44   ` Andrew Cooper
2019-05-31 23:44     ` [Xen-devel] " Andrew Cooper
2019-06-03 11:28     ` Petre Ovidiu PIRCALABU
2019-06-03 11:28       ` [Xen-devel] " Petre Ovidiu PIRCALABU
2019-06-05 15:53   ` Tamas K Lengyel
2019-05-30 14:18 ` [PATCH 7/9] vm_event: Decouple implementation details from interface Petre Pircalabu
2019-05-30 14:18   ` [Xen-devel] " Petre Pircalabu
2019-05-30 14:18 ` [PATCH 8/9] vm_event: Add vm_event_ng interface Petre Pircalabu
2019-05-30 14:18   ` [Xen-devel] " Petre Pircalabu
2019-06-04 14:43   ` Andrew Cooper
2019-06-05 17:01     ` Petre Ovidiu PIRCALABU
2019-06-06  8:37       ` Jan Beulich
2019-06-06 13:48         ` Petre Ovidiu PIRCALABU
2019-06-06 14:16           ` Jan Beulich
2019-05-30 14:18 ` [PATCH 9/9] xen-access: Add support for " Petre Pircalabu
2019-05-30 14:18   ` [Xen-devel] " Petre Pircalabu
2019-06-04 16:04   ` Andrew Cooper
2019-05-30 15:27 ` [PATCH 0/9] Per vcpu vm_event channels Tamas K Lengyel
2019-05-30 15:27   ` [Xen-devel] " Tamas K Lengyel
2019-05-31  7:07   ` Petre Ovidiu PIRCALABU
2019-05-31  7:07     ` [Xen-devel] " Petre Ovidiu PIRCALABU
2019-06-01  0:25 ` Andrew Cooper
2019-06-01  0:25   ` [Xen-devel] " Andrew Cooper
2019-06-03 14:04   ` Petre Ovidiu PIRCALABU
2019-06-03 14:04     ` [Xen-devel] " Petre Ovidiu PIRCALABU

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=9119ed35-e90c-c91e-2138-e2f9afa17d6f@citrix.com \
    --to=andrew.cooper3@citrix.com \
    --cc=ian.jackson@eu.citrix.com \
    --cc=ppircalabu@bitdefender.com \
    --cc=wl@xen.org \
    --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 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.