Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Subject: Re: [PATCH v12 4/4] Documentation: add debugfs description for vfio
To:     Alex Williamson <alex.williamson@redhat.com>
CC:     Jason Gunthorpe <jgg@nvidia.com>,
        <shameerali.kolothum.thodi@huawei.com>,
        <jonathan.cameron@huawei.com>, <cohuck@redhat.com>,
        <linux-kernel@vger.kernel.org>, <linuxarm@openeuler.org>
References: <20230728072104.64834-1-liulongfang@huawei.com>
 <20230728072104.64834-5-liulongfang@huawei.com> <ZM0SAfIHnMHndm8h@nvidia.com>
 <3c557239-447f-116d-3687-cc6e419f2dcc@huawei.com>
 <20230807160352.0b7a57bf.alex.williamson@redhat.com>
From:   liulongfang <liulongfang@huawei.com>
Message-ID: <02d72031-6d09-19a4-6c6d-0e43141e66d0@huawei.com>
Date:   Thu, 10 Aug 2023 14:10:20 +0800
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101
 Thunderbird/60.8.0
MIME-Version: 1.0
In-Reply-To: <20230807160352.0b7a57bf.alex.williamson@redhat.com>
Content-Type: text/plain; charset="gbk"
Content-Transfer-Encoding: 7bit
Precedence: bulk

On 2023/8/8 6:03, Alex Williamson wrote:
> The vfio/<device>/migration/state file can provide useful monitoring of
> the device progress during a migration, but I think the point Jason is
> trying to make is that these hisi_acc seqfiles aren't really doing
> anything that couldn't be done by a simple userspace test driver.
>The state file was originally used to provide a migration state.
When the migration fails, it is used to locate the problem.
For it, we have no other functional demands.

> Based on my review of the previous patch, we're playing pretty loose
> with concurrency and data buffers.  Access to the migration data of
> the device outside of the process that owns the device is also a
> concern.
> 
> The value-add here needs to be that there's something useful about the
> kernel being able to dump this data rather than either a simple
> userspace program or instrumenting a userspace driver like QEMU, where
> we can avoid the complexity that's going to be required to resolve the
> issues in the previous patch and ensure that sensitive data from the
> device isn't available through debugfs.
The question of whether the migrated data is sensitive data.
It is up to the device driver to choose which data can be output.
Currently, the data that can be output through debugfs in this
HiSilicon device driver does not involve sensitive data.

Thanks,
Longfang.