RE: CXL mailbox background command

["Dai WeiBin \(David Dai\)" <david.dai@montage-tech.com>]

Thanks, Dan, your direction is important for us, this will help our software/hardware design.

David


-----Original Message-----
From: Dan Williams (dan.j.williams@intel.com) [mailto:dan.j.williams@intel.com] 
Sent: 2021年4月30日 4:32
To: Dai WeiBin (David Dai)
Cc: Ben Widawsky; linux-cxl@vger.kernel.org; Jin LiZhi (Lynn Jin)
Subject: Re: CXL mailbox background command


CAUTION: This email 
originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.


On Wed, Apr 28, 2021 at 9:30 PM Dai WeiBin (David Dai)
<david.dai@montage-tech.com> wrote:
>
> Hi Ben,
>
> When we think of cxl mailbox background command, we met a difficult issue, how to handle switching between a background command end and another background command start?
>
> The flow is as below:
> 1. Host/caller sends a command to cxl device.
> 2. CXL device identifies the command as a background command, then cxl device returns background command started, background Operation is set to 1.
> 3. CXL device start to handle background command.
> 4. Host/caller can send other commands to cxl device when background command is ongoing on device side.
> 5. At a special point host/caller is sending a command to device when the background command just is finished, the new command will be handled as a background command by device.
> 6. That means the old background command ends, background Operation is set to 0, immediately the new background command is started, background Operation is set to 1 again at once.
> 7. So Host driver doesn’t have a chance to check the old background command has been finished, it still see “background Operation == 1”.
> 8. Mailbox Status Register and Background Command Status Register are both read-only, that results there is not a handshake between host and device.
> 9.How to guarantee exclusion between two background commands.
>
> Do you have any suggestion about this?

Background commands are not suitable to be exposed directly to
userspace, they can lockout critical driver access. They need to be
mediated by the kernel, so they each need a kernel managed state
machine and those state machines need to cooperate with each other.
Userspace can not be trusted to get this right on its own, so
userspace should be disallowed from issuing such commands by default.
Luckily Linux distributions can get this safety policy with minimal
effort by leaving CONFIG_CXL_MEM_RAW_COMMANDS default disabled.