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

Re: [PATCH 5/8] xen/evtchn: don't close the static event channel.


  • To: Julien Grall <julien@xxxxxxx>
  • From: Rahul Singh <Rahul.Singh@xxxxxxx>
  • Date: Thu, 23 Jun 2022 15:10:18 +0000
  • Accept-language: en-US
  • Arc-authentication-results: i=2; mx.microsoft.com 1; spf=pass (sender ip is 63.35.35.123) smtp.rcpttodomain=lists.xenproject.org smtp.mailfrom=arm.com; dmarc=pass (p=none sp=none pct=100) action=none header.from=arm.com; dkim=pass (signature was verified) header.d=armh.onmicrosoft.com; arc=pass (0 oda=1 ltdi=1 spf=[1,1,smtp.mailfrom=arm.com] dkim=[1,1,header.d=arm.com] dmarc=[1,1,header.from=arm.com])
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=arm.com; dmarc=pass action=none header.from=arm.com; dkim=pass header.d=arm.com; arc=none
  • Arc-message-signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=9gZT7tq89fRXo1NwAY5FwgPpPY8hPZ6uzpqvCrR1a6o=; b=RCzzWp8aG1VNEJfxa0xvnYigWYsDUMM48Jf5QZel6lV/Ews5scCvMhs0BfstgCNDhLHt7yf9eoljCt8Q//sGYQm0+/WB1Y9f+4EOgVAUa6eTTgHGXFpDZNnXskXabqneTRk+8Ue7L02DQJc/jPZyq+45N0ffWSMkM5fCLicjH6ZeOxtcNdbKNJqGR+fYqIlxIzHVbpv+3D2FV2tp6v/lvLrEZEDxgSWp9kV3dE4QtgzZVit/8bX93lcEpOC/PBgKh0QZGAUtf+Wij9Pc1tA7Wv/X2gF9e7UJ2SQPb7GXCqEE7GSWh16xLEm8MisrOcLRPCZbQPXN7IdHKnsSgW4YXg==
  • 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-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=9gZT7tq89fRXo1NwAY5FwgPpPY8hPZ6uzpqvCrR1a6o=; b=Jat5vAmuzHeZZ6tKVMSl9hWvAmrhHrbXbV7rKhcZTzB7woBfHO9dIRE66HVizNmtQ7hPqUmFrjc1hSWWwqDy03lkurazmCJsOdIgZmBBJvypKjd/rD8ON9ZtpJ+D0Fqh+28kW/vbmOS29sZN22hi5EZLRV5plxtsyy+N+khaIiMNMgqIAxAA3EjPHMB+VtORgNjwtMGbJxye7iK+u75Kb6LroOESnhKDj/PaX6pSeWpPLAJ5SVuKahaBthFx7o6iIAPdCELfpMwND0UX4qEg/Hk3CDLJNqzHe8LU2Foindhi5e50Y75wydTHPzdW02xABQuj6Gzr9PBSqCZaLLVcDA==
  • Arc-seal: i=2; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=pass; b=YtNHSA49pG+kFhFnqPkipXKY+7dOATZIYMhAvep+nCtiW7ePS7WzbnL/Udy4/i1NNljMOfak+g2KmEKb99wV1rbCBKrGBPFR5CXpE4qVpdYRcu3BmjoTelpCrTHW5homOM2Ia7plg+SmtgpcGCemZ841u+vFZBtSrmZR0of1KCZvFlBbwsayAn73gj2Y7yDIqko8zFdU+M1iEKHDdl8Xkin3ZO+FOtpPqRRuFimBY/jp/oRS8fInZ2HgHGKndWnwhb8f5Mc0ZkSR+lXhqo2JYkNdHTQRblUI0l4RMPwGvcbj0U0Q1gmUpR9B+qe/rP70hUppUlXdQUe6Mg/VGZ1Bpw==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=WdHSwQ4dqBayujt9mPpTYrnM44fnOgHA79FkgC5OjyhwcOX9HtGgJG3WWhBd77RdxL91+cGITubwQ4sNCIrGbv+QuY9MTLI/SxXeGx0yhZPOwiJ8Yc64SXlClXXTiTvRQ8qldYVI90tRBiZgzQtBGXUZQKUADWfdB7iO9CkGykf8CfFpHNxzxcE4ye6O0jBLetHkTI2CWdoKstevorUM2RmRX4/H+hpt7TN9ynWSzHZSosg6p6qnyzeunq1phgXkW268W4GmxULMiUIqeU5dWZQDfg1pwjRGGqTi0jXjQRxY8BFZQrQk996AiH5jqF0Zn2dSjayYScGdfKs43Y4plA==
  • Authentication-results-original: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=arm.com;
  • Cc: xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxxx>, Bertrand Marquis <Bertrand.Marquis@xxxxxxx>, Stefano Stabellini <sstabellini@xxxxxxxxxx>, Volodymyr Babchuk <Volodymyr_Babchuk@xxxxxxxx>, Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, George Dunlap <george.dunlap@xxxxxxxxxx>, Jan Beulich <jbeulich@xxxxxxxx>, Wei Liu <wl@xxxxxxx>
  • Delivery-date: Thu, 23 Jun 2022 15:10:59 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
  • Nodisclaimer: true
  • Original-authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=arm.com;
  • Thread-index: AQHYhkX79rj81mJ150e3nBZ0EA7O6K1bhmuAgAGTuoA=
  • Thread-topic: [PATCH 5/8] xen/evtchn: don't close the static event channel.

Hi Julien,


> On 22 Jun 2022, at 4:05 pm, Julien Grall <julien@xxxxxxx> wrote:
> 
> Hi,
> 
> On 22/06/2022 15:38, Rahul Singh wrote:
>> Guest can request the Xen to close the event channels. Ignore the
>> request from guest to close the static channels as static event channels
>> should not be closed.
> 
> Why do you want to prevent the guest to close static ports? The problem I can 
> see is...

As a static event channel should be available during the lifetime of the guest 
we want to prevent
the guest to close the static ports. 

I tested this series to send/receive event notification from the Linux 
user-space application via "/dev/xen/evtchn” interface and
ioctl ( IOCTL_EVTCHN_*) calls. When we close the "/dev/xen/evtchn” interface 
Linux event channel
driver will try to close the static event channel also, that why we need this 
patch to avoid guests to close 
the event channel as we don’t want to close the static event channel.

>  
> [...]
> 
>> diff --git a/xen/common/event_channel.c b/xen/common/event_channel.c
>> index 84f0055a5a..cedc98ccaf 100644
>> --- a/xen/common/event_channel.c
>> +++ b/xen/common/event_channel.c
>> @@ -294,7 +294,8 @@ void evtchn_free(struct domain *d, struct evtchn *chn)
>>   * If port is zero get the next free port and allocate. If port is non-zero
>>   * allocate the specified port.
>>   */
>> -int evtchn_alloc_unbound(evtchn_alloc_unbound_t *alloc, evtchn_port_t port)
>> +int evtchn_alloc_unbound(evtchn_alloc_unbound_t *alloc, evtchn_port_t port,
>> +                         bool is_static)
>>  {
>>      struct evtchn *chn;
>>      struct domain *d;
>> @@ -330,6 +331,7 @@ int evtchn_alloc_unbound(evtchn_alloc_unbound_t *alloc, 
>> evtchn_port_t port)
>>      evtchn_write_lock(chn);
>>        chn->state = ECS_UNBOUND;
>> +    chn->is_static = is_static;
>>      if ( (chn->u.unbound.remote_domid = alloc->remote_dom) == DOMID_SELF )
>>          chn->u.unbound.remote_domid = current->domain->domain_id;
>>      evtchn_port_init(d, chn);
>> @@ -368,7 +370,7 @@ static void double_evtchn_unlock(struct evtchn *lchn, 
>> struct evtchn *rchn)
>>   * allocate the specified lport.
>>   */
>>  int evtchn_bind_interdomain(evtchn_bind_interdomain_t *bind, struct domain 
>> *ld,
>> -                            evtchn_port_t lport)
>> +                            evtchn_port_t lport, bool is_static)
>>  {
>>      struct evtchn *lchn, *rchn;
>>      struct domain *rd;
>> @@ -423,6 +425,7 @@ int evtchn_bind_interdomain(evtchn_bind_interdomain_t 
>> *bind, struct domain *ld,
>>      lchn->u.interdomain.remote_dom  = rd;
>>      lchn->u.interdomain.remote_port = rport;
>>      lchn->state                     = ECS_INTERDOMAIN;
>> +    lchn->is_static                 = is_static;
>>      evtchn_port_init(ld, lchn);
>>            rchn->u.interdomain.remote_dom  = ld;
>> @@ -659,6 +662,9 @@ int evtchn_close(struct domain *d1, int port1, bool 
>> guest)
>>          rc = -EINVAL;
>>          goto out;
>>      }
>> +    /* Guest cannot close a static event channel. */
>> +    if ( chn1->is_static && guest )
>> +        goto out;
> 
> ... at least the interdomain structure store pointer to the domain. I am a 
> bit concerned that we would end up to leave dangling pointers (such as 
> chn->u.interdomain.remote_domain) as evtchn_close() is also used while 
> destroying the domain.

Let me have a look again if we have to do the cleanup when we destroy the guest 
and close the static event channel.
> 
> Also, AFAICT Xen will return 0 (i.e. success) to the caller. I think this is 
> a mistake because we didn't close the port as requested.

If we return non-zero to guest (in particular if linux guest), Linux will 
report the BUG(). Therefore I decided to return 0. 

if (HYPERVISOR_event_channel_op(EVTCHNOP_close, &close) != 0)               
        BUG();

Regards,
Rahul


 


Rackspace

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