[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH v2] evtchn: make support for different ABIs tunable

  • To: "Elnikety, Eslam" <elnikety@xxxxxxxxxx>
  • From: Jan Beulich <JBeulich@xxxxxxxx>
  • Date: Thu, 8 Aug 2019 15:12:12 +0000
  • Accept-language: en-US
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=suse.com; dmarc=pass action=none header.from=suse.com; dkim=pass header.d=suse.com; arc=none
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=LJQFiiL3J7JUzoPKfCiaE8db4Tm7QNhNCsYWMXaw+m4=; b=as14yJxbpx8dgR3YQInf8M913Bj1Z/vRpGFZNZEHYpNRMIUc4FiBaBa/hOlvmG3StzGlZn7J5MDwAnZJwWxsHazSLBEZiBvklcRbfTqlIwupOvmzowi3bqXFxROx/OdN2dNsnwUD4Sw0hzW4mLfM2hGGkprh7jeYYg2EU1N5KdOgF5Cewzw0npZvW43HU8HeuyQblQaYgAJ8WknivQv6Hl8B6alnBG2PblWzBxSfyJcXZoEdoRrZtGtLatPstz27PWweLUm+rdjCNj4RDz+Ek//SNeuLGdcL2LirOSXlr4Xf8dUplVM01f6Gv8zm15Y84fCAZDaBIzP7rrA2QPIyjg==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=bmGkrD11MZ9DN9so5T/exjv0GXVLpSnhyj9uHUFgUPa8o2DxGsg6JG5WpW+vpkl2eb0rmd/0kVOWPO2o810eAIJWbcniaXVDc1FFcqcbND0XQOo80xtzVNXzT69+yDWsAsnyWH1i6Vmg+ZWyMv8Ujw0e29QiuPZGzj7JM7i9Y5XnIDMgJ6IPo4ZVlerZCGQix+w0mleLvQ4tN6ADSMW5BgMAvEDvstk/bwdOlsU/BQbFEjG6Tp2j4Y/HWRT4ztYPeCnsCWmls/YjmtOqAocubabhbe/0MfK8vMECnEaiEUd6Ar7KReDvglUyfSNGKnP79XOGy9CiviW8V2zOzFm1LQ==
  • Authentication-results: spf=none (sender IP is ) smtp.mailfrom=JBeulich@xxxxxxxx;
  • Cc: Stefano Stabellini <sstabellini@xxxxxxxxxx>, Wei Liu <wl@xxxxxxx>, Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>, George Dunlap <George.Dunlap@xxxxxxxxxxxxx>, Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, Ian Jackson <ian.jackson@xxxxxxxxxxxxx>, Tim Deegan <tim@xxxxxxx>, Julien Grall <julien.grall@xxxxxxx>, Anthony PERARD <anthony.perard@xxxxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>, David Woodhouse <dwmw@xxxxxxxxxxxx>
  • Delivery-date: Thu, 08 Aug 2019 15:16:15 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
  • Thread-index: AQHVTUemBo6+AevzQUaLlW2s+A9xKqbxP2QAgAAR5wCAAAtvAA==
  • Thread-topic: [Xen-devel] [PATCH v2] evtchn: make support for different ABIs tunable

On 08.08.2019 16:31,  Elnikety, Eslam  wrote:

First of all - can you please try to get your reply quoting
improved, such that readers can actually tell your replies
from context? (I didn't check whether perhaps your mail was
a HTML one, and my plain text reading of it discarded the
markings. If so - please don't send HTML mail.)

> On 8. Aug 2019, at 15:27, Jan Beulich 
> <JBeulich@xxxxxxxx<mailto:JBeulich@xxxxxxxx>> wrote:
> On 07.08.2019 19:42, Eslam Elnikety wrote:
> --- a/xen/common/event_channel.c
> +++ b/xen/common/event_channel.c
> @@ -1170,6 +1170,11 @@ long do_event_channel_op(int cmd, 
>       case EVTCHNOP_init_control: {
>           struct evtchn_init_control init_control;
> +
> +        /* Fail init_control for domains that must use 2l ABI */
> +        if ( current->domain->options & XEN_DOMCTL_CDF_disable_fifo )
> +            return -EPERM;
> +
>           if ( copy_from_guest(&init_control, arg, 1) != 0 )
>               return -EFAULT;
>           rc = evtchn_fifo_init_control(&init_control);
> I think the check would better go into evtchn_fifo_init_control(),
> at least as long as the setting really is FIFO-centric. Also the
> Not sure. It is the FIFO ABI that defines EVTCHNOP_init_control
> (not defined in 2L). Short-circuiting the hypercall at this place
> seems more appropriate.

I'd expect any 3rd variant to also have a need for an init-control
operation, and hence at that point this would become a hook like
many of the other ops. And at that point the check would need to
move anyway. Hence it's better to put it in its long term
designated place right away.

> Moreover, doing copy_from_guest and calling into
> evtchn_fifo_init_control only to return error is not optimal.

True, yet from my pov the more logical alternative code structure
is still preferable.

> Irrespective of these remarks, and along the lines of comments on
> the v1 thread, introducing wider control that would also allow
> disabling 2-level (for HVM guests) would seem better to me. This
> would then hopefully be coded up in a way that would make extending
> it straightforward, once a 3rd mechanism appears.
> Hmmm... we cannot force guests to call init_control (in order to flip from 2L 
> to FIFO). Quoting from [1] 4.4 “If this call (EVTCHNOP_init_control) fails on 
> the boot VCPU, the guest should continue to use the 2-level event channel ABI 
> for all VCPUs.” Support for 2L ABI does not sound like something that can be 
> optional. Once a 3rd mechanism appears, I imagine adding a corresponding 
> domctl flag to control such mechanism.

For HVM, event channels as a whole should be optional; we shouldn't
default a possible control for this to off though. For PV, the
2-level interface indeed has to be considered mandatory. Hence
today there are these (theoretically) possible combinations

                PV              HVM
nothing         invalid         valid
2-level only    valid           valid
FIFO only       ???             valid
both            valid           valid

Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.