Re: [virtio-dev] Re: [PATCH 0/5] virtio: introduce SUSPEND bit and vq state

On 9/20/2023 6:36 PM, Michael S. Tsirkin wrote:
> On Wed, Sep 20, 2023 at 02:06:13PM +0800, Zhu, Lingshan wrote:
>>
>> On 9/19/2023 2:49 AM, Michael S. Tsirkin wrote:
>>> On Mon, Sep 18, 2023 at 06:41:55PM +0000, Parav Pandit wrote:
>>>>> Please refer to the code for setting FEATURES_OK.
>>>> It wont work when one needs to suspend the device.
>>>> There is no point of doing such work over registers as fundamental framework is over the AQ.
>>> Well not really. It's over admin commands. When these were built the
>>> intent always was that it's possible to use admin commands through
>>> another interface, other than admin queue. Is there a problem
>>> implementing admin commands over a memory BAR? For example, I can see
>>> an "admin command" capability pointing at a BAR where
>>> commands are supplied, and using a new group type referring to
>>> device itself.
>> I am not sure, if a bar cap would be implemented as a proxy for the admin vq
>> based live migration.
> Not a proxy for a vq in that there's no vq then.
I think if the driver sends admin commands through a VF's bar, then
VF forwards the admin commands to the PF, it acts like a proxy,
or an agent. Anyway it takes admin commands.

So the problems we have discussed still exist.
>
>> then the problems of admin vq LM that we have
>> discussed
>> still exist.
> I freely admit the finer points of this extended flamewar have been lost
> on me, and I wager I'm not the only one. I thought you wanted to migrate
> the device just by accessing the device itself (e.g. the VF) without
> accessing other devices (e.g. the PF), while Parav wants it in a
> separate device so the whole of the device itself can passed through to
> guest. Isn't this, fundamentally, the issue?
we are implementing basic facilities for live migration.

We have pointed out lots of issues, there are many discussions with
Jason and Parav about the problems in migration by admin vq, for example:
security, QOS and nested.
>
>> the bar is only a proxy, doesn't fix anything. and even larger
>> side channel attacking surface: vf-->pf-->vf
> In this model there's no pf. BAR belongs to vf itself
> and you submit commands for the VF through its BAR.
> Just separate from the pci config space.
If using the bar to process admin commands,
is this solution too heavy compared to my proposal in this series?
>
> The whole attacking surface discussion is also puzzling.  We either are
> or are not discussing confidential computing/TDI.  I couldn't figure
> it out. This needs a separate thread I think.
I agree confidential computing is out of spec. Parva mentioned TDISP and 
even
in TDISP spec, it explicitly defined some attacking model, and PF is an 
example.

It is out of spec anyway.
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]