Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1247873
| From | Christoffer Dall <christoffer.dall@linaro.org> |
|---|---|
| Newsgroups | linux.kernel |
| Subject | Re: [PATCH] VFIO: platform: AMD xgbe reset module |
| Date | 2015-10-15 17:10 +0200 |
| Message-ID | <qjSkh-1BA-1@gated-at.bofh.it> (permalink) |
| References | <qjwjL-2JS-15@gated-at.bofh.it> <qjRof-dR-17@gated-at.bofh.it> <qjS0W-Yf-29@gated-at.bofh.it> <qjSaB-19v-5@gated-at.bofh.it> |
| Organization | linux.* mail to news gateway |
On Thu, Oct 15, 2015 at 04:55:13PM +0200, Arnd Bergmann wrote: > On Thursday 15 October 2015 16:46:09 Eric Auger wrote: > > > > > > This is where we'd need a little more changes for this approach. Instead > > > of unbinding the device from its driver, the idea would be that the > > > driver remains bound as far as the driver model is concerned, but > > > it would be in a quiescent state where no other subsystem interacts with > > > it (i.e. it gets unregistered from networking core or whichever it uses). > > > > Currently we use the same mechanism as for PCI, ie. unbind the native > > driver and then bind VFIO platform driver in its place. Don't you think > > changing this may be a pain for user-space tools that are designed to > > work that way for PCI? > > > > My personal preference would be to start with your first proposal since > > it looks (to me) less complex and "unknown" that the 2d approach. > > We certainly can't easily change from one approach to the other without > breaking user expectations, so the decision needs to be made carefully. > > The main observation here is that platform devices are unlike PCI in this > regard because they need extra per-device code. I have argued in the > past that we should not reuse the "VFIO" name here because it's actually > something else. I've adjusted to consider VFIO a general purpose framework for mapping device resources into userspace/VMs, and there are certainly a lot of commonality with both PCI, platform, and potentially other devices for that to make sense. > On the other hand, there are a lot of commonalities, > we just have to make sure we don't try to force the code into one model > that doesn't really work just to make it look more like PCI VFIO. > But given that we now have code for platform device passthrough that works in both QEMU and the kernel side and is actually useful for people, is there a clear technical advantage to go back and rework thaat at this point? Don't get me wrong, I like the idea of having a single driver bound to a platform device, and then that's it, but it just feels like that discussion doesn't necessarily belong in the context of a patch that 'just' seeks to add reset functionality for a specific device for VFIO? -Christoffer -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Back to linux.kernel | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
[PATCH] VFIO: platform: AMD xgbe reset module Eric Auger <eric.auger@linaro.org> - 2015-10-14 17:40 +0200
Re: [PATCH] VFIO: platform: AMD xgbe reset module Arnd Bergmann <arnd@arndb.de> - 2015-10-14 17:40 +0200
Re: [PATCH] VFIO: platform: AMD xgbe reset module Eric Auger <eric.auger@linaro.org> - 2015-10-15 10:10 +0200
Re: [PATCH] VFIO: platform: AMD xgbe reset module Arnd Bergmann <arnd@arndb.de> - 2015-10-15 13:30 +0200
Re: [PATCH] VFIO: platform: AMD xgbe reset module Christoffer Dall <christoffer.dall@linaro.org> - 2015-10-15 14:20 +0200
Re: [PATCH] VFIO: platform: AMD xgbe reset module Arnd Bergmann <arnd@arndb.de> - 2015-10-15 16:10 +0200
Re: [PATCH] VFIO: platform: AMD xgbe reset module Eric Auger <eric.auger@linaro.org> - 2015-10-15 16:50 +0200
Re: [PATCH] VFIO: platform: AMD xgbe reset module Arnd Bergmann <arnd@arndb.de> - 2015-10-15 17:00 +0200
Re: [PATCH] VFIO: platform: AMD xgbe reset module Christoffer Dall <christoffer.dall@linaro.org> - 2015-10-15 17:10 +0200
Re: [PATCH] VFIO: platform: AMD xgbe reset module Arnd Bergmann <arnd@arndb.de> - 2015-10-15 18:00 +0200
Re: [PATCH] VFIO: platform: AMD xgbe reset module Christoffer Dall <christoffer.dall@linaro.org> - 2015-10-15 18:40 +0200
Re: [PATCH] VFIO: platform: AMD xgbe reset module Alex Williamson <alex.williamson@redhat.com> - 2015-10-15 19:00 +0200
Re: [PATCH] VFIO: platform: AMD xgbe reset module Christoffer Dall <christoffer.dall@linaro.org> - 2015-10-15 21:50 +0200
Re: [PATCH] VFIO: platform: AMD xgbe reset module Alex Williamson <alex.williamson@redhat.com> - 2015-10-15 22:30 +0200
Re: [PATCH] VFIO: platform: AMD xgbe reset module Eric Auger <eric.auger@linaro.org> - 2015-10-16 15:10 +0200
Re: [PATCH] VFIO: platform: AMD xgbe reset module Arnd Bergmann <arnd@arndb.de> - 2015-10-16 15:30 +0200
Re: [PATCH] VFIO: platform: AMD xgbe reset module Eric Auger <eric.auger@linaro.org> - 2015-10-16 16:00 +0200
Re: [PATCH] VFIO: platform: AMD xgbe reset module Arnd Bergmann <arnd@arndb.de> - 2015-10-15 16:30 +0200
Re: [PATCH] VFIO: platform: AMD xgbe reset module Eric Auger <eric.auger@linaro.org> - 2015-10-15 16:30 +0200
csiph-web