From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753646AbbJOPuB (ORCPT ); Thu, 15 Oct 2015 11:50:01 -0400 Received: from mout.kundenserver.de ([212.227.126.187]:60560 "EHLO mout.kundenserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753605AbbJOPt6 (ORCPT ); Thu, 15 Oct 2015 11:49:58 -0400 From: Arnd Bergmann To: Christoffer Dall Cc: Eric Auger , linux-arm-kernel@lists.infradead.org, eric.auger@st.com, alex.williamson@redhat.com, b.reynal@virtualopensystems.com, kvmarm@lists.cs.columbia.edu, kvm@vger.kernel.org, thomas.lendacky@amd.com, patches@linaro.org, suravee.suthikulpanit@amd.com, linux-kernel@vger.kernel.org Subject: Re: [PATCH] VFIO: platform: AMD xgbe reset module Date: Thu, 15 Oct 2015 17:49:47 +0200 Message-ID: <5029262.xDTo9hAOAF@wuerfel> User-Agent: KMail/4.11.5 (Linux/3.16.0-10-generic; KDE/4.11.5; x86_64; ; ) In-Reply-To: <20151015150321.GA17484@cbox> References: <1444836792-2405-1-git-send-email-eric.auger@linaro.org> <37917545.AP0MxbQBzK@wuerfel> <20151015150321.GA17484@cbox> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Provags-ID: V03:K0:Nv2wsA+jaKHdDu6BWDcieZsjg2Xgyq/hAc62xNAtvO4WF68A0cT 6Jfri2HZnzD8KQXvgY4hdvINm2RTJXb0HO5OAss+mL7kryL3NaJ161ZlTmsN67x8WMWHRQY cIqQQYmUIlE1iEcYsfblAYnjwHtNYFMTJCyRkwjfNrEUyS9xs098wO7ez5E7wZrtbmFF03A yJvn/RdBiMOr+JA3rbsFQ== X-UI-Out-Filterresults: notjunk:1;V01:K0:qfq0w5/ctZM=:+QP5AC+a5eKE/XWdANDUY2 uyutuFQ3KFkK/Y5Zim3DGHQ4yys25gYjaD10bh8mwY6ZWmgocH9NX/YS/D+EFToI6YWz9uIrH 3NkVnYl7cx7wTCbzecLQRxKHL6FgmJ1soDNvwPUt6Yv2MGu1xHDDUvKx9zJ//Bz/YyO6TH6Eu Al+cThzIx3IW3bMuJQ28H1Y1oUL5g5DgzoWIXfPAKgud18+S2Et4jenaUmqHbAScCwTPJiTD+ sns6AImcP9W9aL4Bj2iVu0TX6Sitdjbcqn8AJO7Sb7HFqhufIQttRT0INZQl2aSi6mUfXswda 7V4RoHptoMNund3iQB1IT7l4RKM2XyqqnJi53m1A/YkdyVo+VSmPP7+AONlz8P+6ozWcER5Pr Y1zpDwSzGmV44B/toc55n45xvgPA2Xzv9IPrF8qHm2rzQ3nbWGlV6roEtXZYaJMR5mHqTZsLC gSt6Q4dhC1nBa+DmAIL2Hr1hkNcwAGcVevTwolKAoUSb+tZXLHfrX1sTerEnhJZOjA9ONxWLk TUtzUhGRhrgzWqgALkRXwaSTM4Uri3LrQymoJRtwX53CpNlmyopfbLR6Vb80ztt6Kc0sOW30G ttpsNezwKGsU4SKyqWHOSEAVxrkUpDYHafjRAeJPr7hN6y//iy7TwbMCUQx+Hmbp65VtoS+ra q4hx6R6UiWofmjBOxl0Sx+iOx6C8kZlhIs9otFnqJrh818l9sK5nZWukh+OBpurvaHpfu80v3 cljJfssPqzhceYtu Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thursday 15 October 2015 17:03:21 Christoffer Dall wrote: > 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? Ah, this is for qemu/kvm? If there is already upstream qemu code that finds it easier to use this approach, it's certainly more logical to deal with it in my first approach than the second. I was thinking of ODP as the primary user, and that wouldn't need the interface to be consistent with PCI as much, because the code is inherently device specific there anyway. Arnd