Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1541639
| From | "Michael S. Tsirkin" <mst@redhat.com> |
|---|---|
| Newsgroups | linux.kernel |
| Subject | Re: [PATCH] vfio/pci: Support error recovery |
| Date | 2016-12-14 03:00 +0100 |
| Message-ID | <sO71n-di-7@gated-at.bofh.it> (permalink) |
| References | (4 earlier) <sNHzX-1CL-7@gated-at.bofh.it> <sNLNf-4oe-1@gated-at.bofh.it> <sNMgi-4ym-9@gated-at.bofh.it> <sNXY5-3ll-27@gated-at.bofh.it> <sNYUa-3UP-49@gated-at.bofh.it> |
| Organization | linux.* mail to news gateway |
On Tue, Dec 13, 2016 at 09:27:59AM -0700, Alex Williamson wrote: > On Tue, 13 Dec 2016 18:12:34 +0200 > "Michael S. Tsirkin" <mst@redhat.com> wrote: > > > On Mon, Dec 12, 2016 at 08:39:48PM -0700, Alex Williamson wrote: > > > On Tue, 13 Dec 2016 05:15:13 +0200 > > > "Michael S. Tsirkin" <mst@redhat.com> wrote: > > > > > > > On Mon, Dec 12, 2016 at 03:43:13PM -0700, Alex Williamson wrote: > > > > > > So just don't do it then. Topology must match between host and guest, > > > > > > except maybe for the case of devices with host driver (e.g. PF) > > > > > > which we might be able to synchronize against. > > > > > > > > > > We're talking about host kernel level handling here. The host kernel > > > > > cannot defer the link reset to the user under the assumption that the > > > > > user is handling the devices in a very specific way. The moment we do > > > > > that, we've lost. > > > > > > > > The way is same as baremetal though, so why not? > > > > > > How do we know this? What if the user is dpdk? The kernel is > > > responsible for maintaining the integrity of the system and devices, > > > not the user. > > > > > > > And if user doesn't do what's expected, we can > > > > do the full link reset on close. > > > > > > That's exactly my point, if we're talking about multiple devices, > > > there's no guarantee that the close() for each is simultaneous. If one > > > function is released before the other we cannot do a bus reset. If > > > that device is then opened by another user before its sibling is > > > released, then we once again cannot perform a link reset. I don't > > > think it would be reasonable to mark the released device quarantined > > > until the sibling is released, that would be a terrible user experience. > > > > Not sure why you find it so terrible, and I don't think there's another way. > > If we can't do it without regressing the support we currently have, > let's not do it at all. Why would we regress? As long as there are no unrecoverable errors, there's no need to change behaviour at all. Alex, do you have a picture of how error recovery can work in your mind? Your answers seem to imply you do, and these patches don't implement this correctly. I'm not sure about others, but I for one am unable to piece it together from the comments you provide. If yes, could you maybe do a short writeup of an architecture you would be comfortable with? Thanks, -- MST
Back to linux.kernel | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
Re: [PATCH] vfio/pci: Support error recovery Cao jin <caoj.fnst@cn.fujitsu.com> - 2016-12-12 14:50 +0100
Re: [PATCH] vfio/pci: Support error recovery Alex Williamson <alex.williamson@redhat.com> - 2016-12-12 20:20 +0100
Re: [PATCH] vfio/pci: Support error recovery "Michael S. Tsirkin" <mst@redhat.com> - 2016-12-12 23:30 +0100
Re: [PATCH] vfio/pci: Support error recovery Alex Williamson <alex.williamson@redhat.com> - 2016-12-12 23:50 +0100
Re: [PATCH] vfio/pci: Support error recovery "Michael S. Tsirkin" <mst@redhat.com> - 2016-12-13 04:20 +0100
Re: [PATCH] vfio/pci: Support error recovery Alex Williamson <alex.williamson@redhat.com> - 2016-12-13 04:50 +0100
Re: [PATCH] vfio/pci: Support error recovery "Michael S. Tsirkin" <mst@redhat.com> - 2016-12-13 17:20 +0100
Re: [PATCH] vfio/pci: Support error recovery Alex Williamson <alex.williamson@redhat.com> - 2016-12-13 18:20 +0100
Re: [PATCH] vfio/pci: Support error recovery "Michael S. Tsirkin" <mst@redhat.com> - 2016-12-14 03:00 +0100
Re: [PATCH] vfio/pci: Support error recovery Alex Williamson <alex.williamson@redhat.com> - 2016-12-14 04:10 +0100
Re: [PATCH] vfio/pci: Support error recovery "Michael S. Tsirkin" <mst@redhat.com> - 2016-12-14 23:30 +0100
Re: [PATCH] vfio/pci: Support error recovery Alex Williamson <alex.williamson@redhat.com> - 2016-12-14 23:50 +0100
Re: [PATCH] vfio/pci: Support error recovery "Michael S. Tsirkin" <mst@redhat.com> - 2016-12-15 00:10 +0100
Re: [PATCH] vfio/pci: Support error recovery Alex Williamson <alex.williamson@redhat.com> - 2016-12-15 00:40 +0100
Re: [PATCH] vfio/pci: Support error recovery Cao jin <caoj.fnst@cn.fujitsu.com> - 2016-12-14 11:30 +0100
Re: [PATCH] vfio/pci: Support error recovery Alex Williamson <alex.williamson@redhat.com> - 2016-12-14 23:20 +0100
Re: [PATCH] vfio/pci: Support error recovery "Michael S. Tsirkin" <mst@redhat.com> - 2016-12-14 23:30 +0100
Re: [PATCH] vfio/pci: Support error recovery Alex Williamson <alex.williamson@redhat.com> - 2016-12-15 00:00 +0100
Re: [PATCH] vfio/pci: Support error recovery Cao jin <caoj.fnst@cn.fujitsu.com> - 2016-12-15 15:00 +0100
Re: [PATCH] vfio/pci: Support error recovery "Michael S. Tsirkin" <mst@redhat.com> - 2016-12-15 16:00 +0100
Re: [PATCH] vfio/pci: Support error recovery Alex Williamson <alex.williamson@redhat.com> - 2016-12-15 23:10 +0100
Re: [PATCH] vfio/pci: Support error recovery Cao jin <caoj.fnst@cn.fujitsu.com> - 2016-12-16 11:20 +0100
Re: [PATCH] vfio/pci: Support error recovery Cao jin <caoj.fnst@cn.fujitsu.com> - 2016-12-16 11:20 +0100
Re: [PATCH] vfio/pci: Support error recovery Alex Williamson <alex.williamson@redhat.com> - 2016-12-15 18:10 +0100
csiph-web