From: "Zhu, Lingshan" <lingshan.zhu@intel.com>
To: "Michael S. Tsirkin" <mst@redhat.com>,
Parav Pandit <parav@nvidia.com>,
"eperezma@redhat.com" <eperezma@redhat.com>,
Cornelia Huck <cohuck@redhat.com>,
Stefan Hajnoczi <stefanha@redhat.com>,
Stefano Garzarella <sgarzare@redhat.com>,
Jason Wang <jasowang@redhat.com>
Cc: "virtio-dev@lists.oasis-open.org"
<virtio-dev@lists.oasis-open.org>,
"virtio-comment@lists.oasis-open.org"
<virtio-comment@lists.oasis-open.org>
Subject: [virtio-comment] Re: [virtio-dev] Re: [PATCH 0/5] virtio: introduce SUSPEND bit and vq state
Date: Thu, 21 Sep 2023 17:06:36 +0800 [thread overview]
Message-ID: <125b664c-096c-09c0-c05c-29b62f020124@intel.com> (raw)
In-Reply-To: <20230921004957-mutt-send-email-mst@kernel.org>
On 9/21/2023 1:41 PM, Michael S. Tsirkin wrote:
> On Thu, Sep 21, 2023 at 03:43:12AM +0000, Parav Pandit wrote:
>>
>>> From: Michael S. Tsirkin <mst@redhat.com>
>>> Sent: Thursday, September 21, 2023 1:34 AM
>>>
>>> On Wed, Sep 20, 2023 at 05:21:52PM +0000, Parav Pandit wrote:
>>>>> OK so with this summary in mind, can you find any advantages to
>>>>> inband+mediation that are real or do you just see disadvantages? And
>>>>> it's a tricky question because I can see some advantages ;)
>>>> inband + mediation may be useful for nested case.
>>> Hint: there's more.
>> Can you please list down?
>>
>> The starting point of discussion is, there is passthrough member device without mediation in virtio interface layers.
>> How shall device migration should work for it?
> I was attempting to have each of you see other's point of view.
> It seems clear I was right, at least one way communication was
> not getting through. Let me try to help.
>
>
> First, clearly Zhu Lingshan cares about the mediation use-case, not the
> un-mediated one. Mediation is clearly heavier but also more powerful
> in many use-cases - is that obvious or do I need to list the reasons?
> To mention one example, it supports cross-vendor migration. Which the unmediated
> variant maybe can in theory support too, and when it does maybe in a better and
> more structured way - but that will require standartization effort that
> didn't happen yet. With mediation it was already demonstrated more than
> once.
>
> 1. For mediation something that works within existing mediation framework -
> e.g. reusing as he does feature bits - will require less support
> than a completely separate facility.
> I think Zhu Lingshan also believes that since there will be less code ->
> less security issues.
>
> 2. With or without mediation, the mapping of commands to VFs is simpler,
> allowing more control - for example, let's say you want to reset a VF -
> you do not need to flush the queue of existing commands, which might
> potentially take a long time because some other VFs are very busy - you
> just reset the VF which any unmap flow will already do.
>
>
Thanks, I agree
> But Zhu Lingshan, all this will be pointless if you also do not try to
> do this and list what are reasonable points that Parav made. Please do
> not mistake what I'm doing here for taking sides I just want the
> communication to start working. And that means everyone tries to take
> all use-cases into account even if working for a vendor that does not
> care about this use-case. Otherwise we will just keep getting into these
> flamewars.
I think admin vq live migration surely work for some scenarios and can
meet specific customers requirements,
that uses cases are reasonable for sure.
Jason, Eugenio and me, et al spent a lot of efforts on this live
migration proposal in the past two years,
this series are based on the joint work, directly carry on previous
series sent by Jason and Eugenio.
This series introduces basic facilities for live migration, and the
implementation is transport specific.
I agree we should cooperate, at least the basic facilities can be used
by admin vq, for example the
dirty page tracking facility and even forward suspend command to device
status.
Thanks,
Zhu Lingshan
This publicly archived list offers a means to provide input to the
OASIS Virtual I/O Device (VIRTIO) TC.
In order to verify user consent to the Feedback License terms and
to minimize spam in the list archive, subscription is required
before posting.
Subscribe: virtio-comment-subscribe@lists.oasis-open.org
Unsubscribe: virtio-comment-unsubscribe@lists.oasis-open.org
List help: virtio-comment-help@lists.oasis-open.org
List archive: https://lists.oasis-open.org/archives/virtio-comment/
Feedback License: https://www.oasis-open.org/who/ipr/feedback_license.pdf
List Guidelines: https://www.oasis-open.org/policies-guidelines/mailing-lists
Committee: https://www.oasis-open.org/committees/virtio/
Join OASIS: https://www.oasis-open.org/join/
next parent reply other threads:[~2023-09-21 9:06 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <PH0PR12MB5481C41D4F32DA26D5831471DCFBA@PH0PR12MB5481.namprd12.prod.outlook.com>
[not found] ` <213a0f94-cee2-d8c5-3c5d-d2d7fc920e75@intel.com>
[not found] ` <PH0PR12MB5481AE8C6E5EAFE9A4ADA6F6DCFBA@PH0PR12MB5481.namprd12.prod.outlook.com>
[not found] ` <f1fe513e-d42d-03a6-348c-5e58aac0a759@intel.com>
[not found] ` <PH0PR12MB5481323A3B4D67EB66328476DCFBA@PH0PR12MB5481.namprd12.prod.outlook.com>
[not found] ` <5f01772f-eb27-bfe0-7f69-b83fbd90dda0@intel.com>
[not found] ` <PH0PR12MB5481ABF4B9BC2082BC54AB1DDCFBA@PH0PR12MB5481.namprd12.prod.outlook.com>
[not found] ` <20230918144312-mutt-send-email-mst@kernel.org>
[not found] ` <bb402c34-ad07-063a-f4f5-d8c6b3a642c7@intel.com>
[not found] ` <20230920054836-mutt-send-email-mst@kernel.org>
[not found] ` <2f67fb85-2238-9c34-a265-b0f97b7ab7e1@intel.com>
[not found] ` <20230920075243-mutt-send-email-mst@kernel.org>
[not found] ` <20230920084058-mutt-send-email-mst@kernel.org>
[not found] ` <PH0PR12MB548110E53C924C984FA24A49DCF9A@PH0PR12MB5481.namprd12.prod.outlook.com>
[not found] ` <20230920101402-mutt-send-email-mst@kernel.org>
[not found] ` <PH0PR12MB54816F8341A77E63831316DBDCF9A@PH0PR12MB5481.namprd12.prod.outlook.com>
[not found] ` <20230920160218-mutt-send-email-mst@kernel.org>
[not found] ` <PH0PR12MB54814A89793CF796412D6A27DCF8A@PH0PR12MB5481.namprd12.prod.outlook.com>
[not found] ` <20230921004957-mutt-send-email-mst@kernel.org>
2023-09-21 9:06 ` Zhu, Lingshan [this message]
2023-09-21 9:18 ` [virtio-comment] Re: [virtio-dev] Re: [PATCH 0/5] virtio: introduce SUSPEND bit and vq state Zhu, Lingshan
2023-09-21 9:26 ` [virtio-comment] " Parav Pandit
2023-09-21 9:55 ` [virtio-comment] " Zhu, Lingshan
2023-09-21 11:28 ` [virtio-comment] " Parav Pandit
2023-09-22 2:40 ` [virtio-comment] " Zhu, Lingshan
[not found] ` <CACGkMEsn+9AqgmurN8-GXkcu8UxAr62_woJn3XZN+oUkTQNPUg@mail.gmail.com>
[not found] ` <PH0PR12MB5481830365A80EF4583A3FFADCF8A@PH0PR12MB5481.namprd12.prod.outlook.com>
[not found] ` <CACGkMEshxAU3Mjo7vczBNRb=P=FnenO4mPb9HJL0Ma3ZRbe-oA@mail.gmail.com>
[not found] ` <PH0PR12MB548172996D62E37714A9776BDCF8A@PH0PR12MB5481.namprd12.prod.outlook.com>
[not found] ` <CACGkMEtW88zJkDQL58NqLzzudq=f+SmzJ8bha55Dd2fd=FRGBQ@mail.gmail.com>
2023-09-22 3:39 ` Zhu, Lingshan
[not found] ` <PH0PR12MB5481573D6EE3BE03FB7C3D70DCFCA@PH0PR12MB5481.namprd12.prod.outlook.com>
[not found] ` <CACGkMEvOxraeVB-5g7dJ-KBN=63kpmDfDdqaiQVyDh8egDjsGw@mail.gmail.com>
[not found] ` <PH0PR12MB5481C11F6D68A892A091E2AFDCC3A@PH0PR12MB5481.namprd12.prod.outlook.com>
2023-09-26 5:36 ` Zhu, Lingshan
2023-09-26 6:03 ` [virtio-comment] " Parav Pandit
2023-09-26 9:25 ` [virtio-comment] " Zhu, Lingshan
2023-09-26 10:48 ` Michael S. Tsirkin
2023-09-27 8:20 ` Zhu, Lingshan
2023-09-27 10:39 ` [virtio-comment] " Parav Pandit
2023-10-09 10:05 ` [virtio-comment] " Zhu, Lingshan
2023-10-09 10:07 ` [virtio-comment] " Parav Pandit
2023-09-27 15:40 ` [virtio-comment] " Michael S. Tsirkin
2023-10-09 10:01 ` Zhu, Lingshan
2023-10-11 10:20 ` Michael S. Tsirkin
2023-10-11 10:38 ` Zhu, Lingshan
2023-10-11 11:52 ` Parav Pandit
2023-10-12 10:57 ` Zhu, Lingshan
2023-10-12 11:13 ` Michael S. Tsirkin
2023-10-12 9:59 ` Michael S. Tsirkin
2023-10-12 10:49 ` Zhu, Lingshan
2023-10-12 11:12 ` Michael S. Tsirkin
2023-10-13 10:18 ` [virtio-comment] Re: [virtio-dev] " Zhu, Lingshan
2023-10-12 14:38 ` Michael S. Tsirkin
2023-10-13 10:23 ` Zhu, Lingshan
2023-09-06 8:16 [virtio-comment] " Zhu Lingshan
2023-09-14 11:37 ` [virtio-comment] " Michael S. Tsirkin
2023-09-15 4:41 ` [virtio-comment] Re: [virtio-dev] " Zhu, Lingshan
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=125b664c-096c-09c0-c05c-29b62f020124@intel.com \
--to=lingshan.zhu@intel.com \
--cc=cohuck@redhat.com \
--cc=eperezma@redhat.com \
--cc=jasowang@redhat.com \
--cc=mst@redhat.com \
--cc=parav@nvidia.com \
--cc=sgarzare@redhat.com \
--cc=stefanha@redhat.com \
--cc=virtio-comment@lists.oasis-open.org \
--cc=virtio-dev@lists.oasis-open.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).