[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: Wed, 6 Jul 2022 10:42:03 +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=6jxOhJ8WD+RSzAjdZgMNYj5h2Pt3OdaCjHSjWhNaf5s=; b=XL421N/kq5aNx16/bi3CYBF6Ps4/uQ4uC82h+T9EcBCbY8epriZDZbWaUJxpdUz5FUToXsh4wmkd4P5uUUzSjYEFeBuhpUzojIMNa/XKp+sGyvrRyANzt3XnoETlWtUkRxZoHbcJJxvuDcupcgArlwT4uwxfsN+cXyJkUbbckcNeHQ4njEiYrfMFbTxvSFZ+yrhW9Ubyk4jutEJXlF2Dw3CR1puNR7U1kq9CRX2Ewk50I/61rAWKZt32KSg3IazGZcCABC1KR1VKq83HUc0fdaeHL/WvO8GSu1y3/aKyQO27Dgrpl9OOt2wBTTAvT6TSVmuDApZ0TS008KwHt0A+sg==
  • 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=6jxOhJ8WD+RSzAjdZgMNYj5h2Pt3OdaCjHSjWhNaf5s=; b=VIMi0O8k01SaqIR8oIaMuhIdUwAQOu3WqzRgGKz/2Jq9QXdnP/ndbmDBn0SUXvQ5vVZWpRH1MYkXTBApgeOsxrG7sc8XNfou3VaoS2ylpV3Dac1ijUBWU01v4TDcgArfan/cRz8LqkHRvM4l4XUi0HSfGXex3ynw2sJhc4A7lhiHWYHurevCEAHgbPi1/DNe81hVl5yjH1xnJ2sutoCbG9cU56B7JndrUmYNYlkroI5HsQoQQTTVOcdlnKtt1QsO6LVt1spIYzPgBuaY0EFkbNjIcO4Y0JYN+n+MEGpaUZWo7axoBpFuJpOW/2oWpunt+zoLWF/LZSurgkcrfVjvEg==
  • Arc-seal: i=2; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=pass; b=UhVTPh7p4Q69kzVmoaGFrMsYujBZKWVPS1TzyeE3+NHgiQCYKJxYVUkUh6EN2cBqTJXMcCUPqnQ1exwB9+0e+uRzqgIWnqg2vcanlGF66/MI/CNKolmAd7v/XD48+5Kc+oLF37/w0WZy6wKop92RtrC2c4zW1GpZHvXk+15Ls9iWxU0CUqqYxbWPtlaYnNIerinxzcoA3Lo139rixau+QvTZyM9IHduYZMwWOyluOin7jppkiTnEDTwttXRYQV8J+KE00I7u1vDrzqy5JTlinqK6Vas8zCUdsh7THRo4Dm8NNlK4oZZ4QGJfNqRZedorosxmhrgaWDE/F99KBTCNyg==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=kv/y+i/2be4OXlTKAvCRBEznkfw4Lal5qJJYMAMYsQUCausUXAEBdPWPg2Jhh2UUFEkhJbf9lI6jMzUtId6XGaS1Qfmnx3cpIwO5ncGKRnidZTaEBLdW6lytX/RV+VzKXyJe7PFhtbWfCdPsklHNtrtYQHItmD3n6WR3mc75xyFJZOHCkCgdJS6QMMOLjlQU9fiKSgeL7XaTRsEjyVi8UE1vmWngji8cNMpuZl9wubvBHozOrjQCYqWcpBpnV5yRHKiPLxuxcCJiy1vh16rDvwD83SMFEDRYoCyqNOxioJhFExG+pOcK/iWtOVYHt6Wm7x5U+7CD/eRY9ObmwSrz/Q==
  • Authentication-results-original: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=arm.com;
  • Cc: Bertrand Marquis <Bertrand.Marquis@xxxxxxx>, xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxxx>, 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: Wed, 06 Jul 2022 10:42:23 +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: AQHYhkX79rj81mJ150e3nBZ0EA7O6K1bhmuAgAGTuoCAAAWegIAHwJEAgAAJPQCAAAcgAIAAB1iAgArhiICAAAgBAIABW/CA
  • Thread-topic: [PATCH 5/8] xen/evtchn: don't close the static event channel.

Hi Julien,

> On 5 Jul 2022, at 2:56 pm, Julien Grall <julien@xxxxxxx> wrote:
> 
> 
> 
> On 05/07/2022 14:28, Rahul Singh wrote:
>> Hi Julien,
> 
> Hi Rahul,
> 
>>> On 28 Jun 2022, at 4:18 pm, Julien Grall <julien@xxxxxxx> wrote:
>>>> a new driver in linux kernel, etc where right now we just need to 
>>>> introduce an extra IOCTL in linux to support this feature.
>>> 
>>> I don't understand why would need a new driver, etc. Given that you are 
>>> introducing a new IOCTL you could pass a flag to say "This is a static 
>>> event channel so don't close it".
>> I tried to implement other solutions to this issue. We can introduce a new 
>> event channel state “ECS_STATIC” and set the
>> event channel state to ECS_STATIC when Xen allocate and create the static 
>> event channels.
> 
> From what you wrote, ECS_STATIC is just an interdomain behind but where you 
> want Xen to prevent closing the port.
> 
> From Xen PoV, it is still not clear why this is a problem to let Linux 
> closing such port. From the guest PoV, there are other way to pass this 
> information (see below).

If Linux closes the port, the static event channel created by Xen associated 
with such port will not be available to use afterward.

When I started implemented the static event channel series, I thought the 
static event channel has to be available for use during
the lifetime of the guest. This patch avoids closing the port if the Linux 
user-space application wants to use the event channel again.

This patch is fixing the problem for Linux OS, and I agree with you that we 
should not modify the Xen to fix the Linux problem.
Therefore, If the guest decided to close the static event channel, Xen will 
close the port. Event Chanel associated with the port
will not be available for use after that.I will discard this patch in the next 
series.

> 
>> From guest OS we can check if the event channel is static (via 
>> EVTCHNOP_status()  hypercall ), if the event channel is
>> static don’t try to close the event channel. If guest OS try to close the 
>> static event channel Xen will return error as static event channel can’t be 
>> closed.
> Why do you need this? You already need a binding indicating which ports will 
> be pre-allocated. So you could update your binding to pass a flag telling 
> Linux "don't close it".
> 
> I have already proposed that before and I haven't seen any explanation why 
> this is not a viable solution.

Sorry I didn’t mention this earlier, I started with your suggestion to fix the 
issue but after going through the Linux evtchn driver code
it is not straight forward to tell Linux don’t close the port. Let me try to 
explain.

In Linux, struct user_evtchn {} is the struct that hold the information for 
each user evtchn opened. We can add one bool parameter in this struct to tell 
Linux driver
via IOCTL if evtchn is static. When user application close the fd 
"/dev/xen/evtchn” , evtchn_release() will traverse all the evtchn and call 
evtchn_unbind_from_user()
for each evtchn. evtchn_unbind_from_user() will call  __unbind_from_irq(irq) 
that will call xen_evtchn_close() . We need references to "struct user_evtchn” 
in
function __unbind_from_irq() to pass as argument to xen_evtchn_close() not to 
close the static event channel.  I am not able to find any way to get 
struct user_evtchn in function __unbind_from_irq() , without modifying the 
other Linux structure.

Regards,
Rahul


 


Rackspace

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