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

Re: [XEN PATCH v1] xen/arm : Add support for SMMUv3 driver

  • To: Julien Grall <julien@xxxxxxx>
  • From: Bertrand Marquis <Bertrand.Marquis@xxxxxxx>
  • Date: Tue, 27 Oct 2020 14:19:52 +0000
  • Accept-language: en-GB, en-US
  • 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=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=kI554YTTYiUUDfRBH9gI3S5wDzOkzAMhqDe2vEedAbE=; b=XzcVp/KHwp5UmL2IjiNkqaJWOeM0Um0bcCQ9izIXi53sj8+uBwQlreSpaGr+OqcxqfONXwe+GnsUxjOIDSoN1/l261S0r+nmhMqE1Vdx5MLLsTMwbutmSmVcELVVEsGZKjlZnj6jfsioI8Aq5IC12s1X8ztYkZifOdSRM0bF+PtTTJSqeJkxH0bLDVPwZGTqhVao9n4s1MiDMZrvMd8oHOOyfgo/uqPEj6tW5EqSojKc1uCSZZ+Xs5yxVoIuaVokGWbaZ3d9PTxQ2rOrV5ufqHM8DkY2xELM2cg1Bc1m67In331uwBoCJpLIggUZ/jQQyYzxPUB3f+WDtEyhept3nw==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ZrQIn0PNxSLRGAM0PyLD2VQfLjmprijJnEzcoCPXJ9mmRI12yhynz4kGjkGx4q/GwT/QbjeBBORUF9o9mjpW8hG5JeFxriaqsVFB+ipOqCPOJ7q+xLQ9uJCwQOkTla6TIOMbYocUnwTeanQNqWG5suNr1lTfL4PX0EDYQZOSipircxCNCEKkvvv3mYY8r+qEVXydifvuUntWW0krc065wE3Xg8PUbHlK507cSyAMB0BvjAWTpPpaMA5gJQTqjuwadZvg8UCTtI/Jk6i46bH5jFR5pkTx9WPseunVrXA3+h5FXSstOd6m05ojs9CCqx/ucouUxLdFBobYT1Jv/btNVQ==
  • Authentication-results-original: xen.org; dkim=none (message not signed) header.d=none;xen.org; dmarc=none action=none header.from=arm.com;
  • Cc: Ash Wilding <Ash.Wilding@xxxxxxx>, Rahul Singh <Rahul.Singh@xxxxxxx>, Stefano Stabellini <sstabellini@xxxxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>, Jan Beulich <jbeulich@xxxxxxxx>, Paul Durrant <paul@xxxxxxx>, Volodymyr Babchuk <Volodymyr_Babchuk@xxxxxxxx>
  • Delivery-date: Tue, 27 Oct 2020 14:20:11 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
  • Nodisclaimer: true
  • Original-authentication-results: xen.org; dkim=none (message not signed) header.d=none;xen.org; dmarc=none action=none header.from=arm.com;
  • Thread-topic: [XEN PATCH v1] xen/arm : Add support for SMMUv3 driver

Hi Julien,

> On 26 Oct 2020, at 19:05, Julien Grall <julien@xxxxxxx> wrote:
> On 26/10/2020 12:10, Ash Wilding wrote:
>> Hi,
> Hi Ash,
>>> 1. atomic_set_release
>>> 2. atomic_fetch_andnot_relaxed
>>> 3. atomic_cond_read_relaxed
>>> 4. atomic_long_cond_read_relaxed
>>> 5. atomic_long_xor
>>> 6. atomic_set_release
>>> 7. atomic_cmpxchg_relaxed might be we can use atomic_cmpxchg that is
>>>    implemented in XEN need to check.
>>> 8. atomic_dec_return_release
>>> 9. atomic_fetch_inc_relaxed
>> If we're going to pull in Linux's implementations of the above atomics
>> helpers for SMMUv3, and given the majority of SMMUv3 systems are v8.1+
>> with LSE, perhaps this would be a good time to drop the current
>> atomic.h in Xen completely and pull in both Linux's LL/SC and LSE
>> helpers,
> When I originally answered to the thread, I thought about suggesting 
> importing LSE. But I felt it was too much to ask in order to merge the SMMUv3 
> code.
> However, I would love to have support for LSE in Xen as this would solve 
> other not yet fully closed security issue with LL/SC (see XSA-295 [2]).
> Would Arm be willing to add support for LSE before merging the SMMUv3?

We are willing to work on LSE but I cannot commit on me and my team to start 
working on this subject before the end of the year.

So I think it would be good to integrate this version of SMMUv3 and we can then 
update it to the latest Linux one once LSE has been added.

I think it make sense in the meantime to discuss how this should be designed 
but it might be a good idea to make a specific discussion thread for that.


> As an alternative, it might also be possible to provide "dumb" implementation 
> for all the helpers even if they are stricter than necessary for the memory 
> ordering requirements.
> then use a new Kconfig to toggle between them?
> I would prefer to follow the same approach as Linux and allow Xen to select 
> at boot time which implementations to use. This would enable distro to 
> provide a single binary that boot on all Armv8 and still allow Xen to select 
> the best set of instructions.
> Xen already provides a framework to switch between two sets of instructions 
> at boot. This was borrowed from Linux, so I don't expect a big hurdle to get 
> this supported.
>> Back in 5d45ecabe3 [1] Jan mentioned we probably want to avoid relying
>> on gcc atomics helpers as we can't switch between LL/SC and LSE
>> atomics. 
> I asked Jan to add this line in the commit message :). My concern was that 
> even if we provided a runtime switch (or sanity check for XSA-295), the GCC 
> helpers would not be able to take advantage (the code is not written by Xen 
> community).
> Cheers,
>> [1] https://xenbits.xen.org/gitweb/?p=xen.git;a=commit;h=5d45ecabe3
> [2] https://xenbits.xen.org/xsa/advisory-295.html
> -- 
> Julien Grall



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