Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Subject: Re: [PATCH 0/3] Add quirk to support exynos ufshci
To:     jongmin jeong <jjmin.jeong@samsung.com>, jejb@linux.ibm.com,
        martin.petersen@oracle.com
Cc:     alim.akhtar@samsung.com, avri.altman@wdc.com, cang@codeaurora.org,
        beanhuo@micron.com, adrian.hunter@intel.com,
        linux-scsi@vger.kernel.org, linux-kernel@vger.kernel.org,
        Christoph Hellwig <hch@lst.de>
References: <CGME20210527031217epcas2p44b9d999edcc55b345dfd0749acefeaec@epcas2p4.samsung.com>
 <20210527030901.88403-1-jjmin.jeong@samsung.com>
From:   Bart Van Assche <bvanassche@acm.org>
Message-ID: <8bc342ef-b434-6a56-97e8-582a6588e920@acm.org>
Date:   Thu, 27 May 2021 09:40:01 -0700
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101
 Thunderbird/78.10.2
MIME-Version: 1.0
In-Reply-To: <20210527030901.88403-1-jjmin.jeong@samsung.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Precedence: bulk

On 5/26/21 8:08 PM, jongmin jeong wrote:
> In ExynosAuto(variant of the Exynos for automotive), the UFS Storage needs
> to be accessed from multi-OS.
> To increase IO performance and reduce SW complexity, we implemented UFS-IOV
> to support storage IO virtualization feature on UFS.
> 
> IO virtualization increases IO performance and reduce SW complexity
> with small area cost. And IO virtualization supports virtual machine isolation
> for Security and Safety which are requested by Multi-OS system such as
> automotive application.
> 
> Below figure is the conception of UFS-IOV architeture.
> 
>     +------+          +------+
>     | OS#1 |          | OS#2 |
>     +------+          +------+
>        |                 |
>  +------------+     +------------+
>  |  Physical  |     |   Virtual  |
>  |    Host    |     |    Host    |
>  +------------+     +------------+
>    |      |              | <-- UTP_CMD_SAP, UTP_TM_SAP
>    |   +-------------------------+
>    |   |    Function Arbitor     |
>    |   +-------------------------+
>  +-------------------------------+
>  |           UTP Layer           |
>  +-------------------------------+
>  +-------------------------------+
>  |           UIC Layer           |
>  +-------------------------------+
> 
> There are two types of host controllers on the UFS host controller
> that we designed.
> The UFS device has a Function Arbitor that arranges commands of each host.
> When each host transmits a command to the Arbitor, the Arbitor transmits it
> to the UTP layer.
> Physical Host(PH) support all UFSHCI functions(all SAPs) same as conventional
> UFSHCI.
> Virtual Host(VH) support only data transfer function(UTP_CMD_SAP and UTP_TM_SAP).
> 
> In an environment where multiple OSs are used, the OS that has the leadership of
> the system is called System OS. This system OS uses PH and controls error handling.
> 
> Since VH can only use less functions than PH, it is necessary to send a request
> to PH for Detected Error Handling in VH. To interface among PH and VHs,
> UFSHCI HW supports mailbox. PH can broadcast mail to other VH at the same time
> with arguments and VH can mail to PH with arguments.
> PH and VH generate interrupts when mails from PH or VH.
> 
> In this structure, the virtual host can't support some feature and need to skip
> the some part of ufshcd code by using quirk.
> This patchs add quirks so that the UIC command is ignored and the ufshcd init
> process can be skipped for VH. Also, according to our UFS-IOV policy,
> we added a quirk to the abort handler or device reset handler to call
> the host reset handler.

More information is needed about how multiple operating systems share a
single UFS device. Are LUNs shared across operating systems, does each
OS access separate LUNs or does each OS access different partitions on
the same LUN? Do you agree that for the latter two it is not necessary
to provide the virtual host access to the UTP layer?

Bart.