From: "Michael S. Tsirkin" <mst@redhat.com>
To: Parav Pandit <parav@nvidia.com>
Cc: Cornelia Huck <cohuck@redhat.com>,
"virtio-dev@lists.oasis-open.org"
<virtio-dev@lists.oasis-open.org>,
Max Gurtovoy <mgurtovoy@nvidia.com>,
Shahaf Shuler <shahafs@nvidia.com>, Oren Duer <oren@nvidia.com>
Subject: Re: [PATCH v2] Add device reset timeout field
Date: Fri, 8 Oct 2021 06:12:11 -0400 [thread overview]
Message-ID: <20211008060329-mutt-send-email-mst@kernel.org> (raw)
In-Reply-To: <PH0PR12MB5481CEA27B18421BB8432AD6DCB19@PH0PR12MB5481.namprd12.prod.outlook.com>
On Thu, Oct 07, 2021 at 05:58:09PM +0000, Parav Pandit wrote:
> > >> > > Third how about making e.g. 0 a special value meaning no limit
> > >> > > wait
> > >> forever?
> > >> > The whole idea is to have some finite/deterministic behavior,
> > >>
> > >> I guess I'm being dense, I just don't yet understand the motivation.
> > >> The cost is difficulty in migration since each and every piece of
> > >> hardware will have a different timeout.
> > >>
> > > Such timeout is already there. Advertising timeout doesn't change the LM
> > > flow.
> > > A migrating device at the destination is anyway out of the reset when
> > > migration occurs.
> >
> > But it introduces values that may be different between different devices of the
> > same type, no? I guess the destination would need to re-read the value to get
> > the current one. Not an insurmountable problem, but still needs some care.
> >
> When a device migrates to destination, it starts from where the device
> left off on the source side. So yes, destination side, device must be
> usable (out of reset), and after that its current state will be
> overwritten by the migrating device.
I get what you are trying to say here but it's a hack. Nothing
prevents a reset for driver's internal reasons at any point,
and in particular reset is used e.g. for driver removal.
> If you ask, does migration
> overwrite the reset timeout register value? I would say no, because
> how long device would take to reset is decided by the destination side
> implementation.
Problem is, driver can cache the value on source. Then it's migrated
and used on destination when driver wants to reset the device.
This can lead to a timeout if the destination does not
finish within the source timeout value.
That's why I ask: why do we bother? What's wrong with just waiting
forever or until user gets tired of this and cancels with CTRL-C?
Is there a use-case where that's not good enough?
> And this is probably yet another good reason to define migratable bits
> of a virtio device in the live migration spec extension.
"migratable bits" being what? non-guest visible device state? Sure, would
be great to have. Don't think it will help in this instance.
--
MST
next prev parent reply other threads:[~2021-10-08 10:12 UTC|newest]
Thread overview: 55+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-10-06 14:10 [PATCH v2] Add device reset timeout field Parav Pandit
2021-10-06 15:22 ` Michael S. Tsirkin
2021-10-06 16:11 ` Parav Pandit
2021-10-06 20:53 ` Michael S. Tsirkin
2021-10-07 3:42 ` Parav Pandit
2021-10-07 16:10 ` [virtio-dev] " Cornelia Huck
2021-10-07 17:58 ` Parav Pandit
2021-10-08 10:00 ` [virtio-dev] " Cornelia Huck
2021-10-08 10:19 ` Parav Pandit
2021-10-08 10:12 ` Michael S. Tsirkin [this message]
2021-10-08 10:51 ` Parav Pandit
2021-10-08 11:18 ` [virtio-dev] " Michael S. Tsirkin
2021-10-08 12:55 ` Parav Pandit
2021-10-08 10:44 ` Michael S. Tsirkin
2021-10-08 10:59 ` Parav Pandit
2021-10-08 11:21 ` Michael S. Tsirkin
2021-10-08 11:45 ` Parav Pandit
2021-10-08 11:47 ` [virtio-dev] " Cornelia Huck
2021-10-08 12:12 ` Parav Pandit
2021-10-08 12:57 ` Michael S. Tsirkin
2021-10-08 13:23 ` Parav Pandit
2021-10-08 23:09 ` Michael S. Tsirkin
2021-10-11 14:29 ` Parav Pandit
2021-10-11 14:59 ` [virtio-dev] " Cornelia Huck
2021-10-11 15:44 ` Parav Pandit
2021-10-11 16:00 ` Michael S. Tsirkin
2021-10-12 8:51 ` Parav Pandit
2021-10-12 9:01 ` Michael S. Tsirkin
2021-10-12 9:12 ` Parav Pandit
2021-10-14 17:35 ` Parav Pandit
2021-10-14 22:28 ` Michael S. Tsirkin
2021-10-15 4:36 ` Parav Pandit
2021-10-15 5:15 ` [virtio-dev] " Jason Wang
2021-10-15 5:20 ` Parav Pandit
2021-10-15 6:40 ` Jason Wang
2021-10-15 6:42 ` Jason Wang
2021-10-15 6:48 ` Parav Pandit
2021-10-15 7:02 ` Jason Wang
2021-10-15 8:21 ` Parav Pandit
2021-10-15 8:42 ` Jason Wang
2021-10-22 7:20 ` Parav Pandit
2021-10-25 5:41 ` Jason Wang
2021-10-25 6:11 ` Parav Pandit
2021-10-26 4:03 ` Jason Wang
2021-10-27 8:04 ` Parav Pandit
2021-10-27 8:26 ` Michael S. Tsirkin
2021-10-28 4:01 ` Parav Pandit
2021-10-28 5:50 ` Michael S. Tsirkin
2021-10-28 6:06 ` Parav Pandit
2021-10-15 6:51 ` Cornelia Huck
2021-10-15 8:09 ` Parav Pandit
2021-10-15 9:25 ` [virtio-dev] " Cornelia Huck
2021-10-22 6:29 ` Parav Pandit
2021-10-11 16:22 ` [virtio-dev] " Cornelia Huck
2021-10-12 10:35 ` Parav Pandit
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=20211008060329-mutt-send-email-mst@kernel.org \
--to=mst@redhat.com \
--cc=cohuck@redhat.com \
--cc=mgurtovoy@nvidia.com \
--cc=oren@nvidia.com \
--cc=parav@nvidia.com \
--cc=shahafs@nvidia.com \
--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