[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20210420145514.GB1370958@nvidia.com>
Date: Tue, 20 Apr 2021 11:55:14 -0300
From: Jason Gunthorpe <jgg@...dia.com>
To: liulongfang <liulongfang@...wei.com>
Cc: alex.williamson@...hat.com, cohuck@...hat.com,
linux-kernel@...r.kernel.org, linuxarm@...neuler.org
Subject: Re: [RFC PATCH 2/3] vfio/hisilicon: register the driver to vfio
On Tue, Apr 20, 2021 at 09:28:46PM +0800, liulongfang wrote:
> >> So, I still don't understand what the security risk you are talking about is,
> >> and what do you think the security design should look like?
> >> Can you elaborate on it?
> >
> > Each security domain must have its own PCI BDF.
> >
> The basic unit to perform the live migration function is the VF, and the basic
> function of the VF is the business function of the device. If the live migration
> function and the business function are completely separated, and they are bound
> to their respective VFs, it will result in the ability to execute the business
> in the guest A functional VF cannot perform live migration, and a VF with a live
> migration function cannot perform business functions in the guest.
>
> In fact, the scenario that requires live migration is to migrate its business
> functions to the VFs of other hosts when the VF's business functions are heavily
> loaded.
> This usage scenario itself requires that the VF needs to have these two functions
> at the same time.
Other vendors are managing, it is not an unsolvable problem.
I think these patches can't advance in any form without somehow
addressing the isolation issue.
Jason
Powered by blists - more mailing lists