Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1247873

Re: [PATCH] VFIO: platform: AMD xgbe reset module

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

Show all headers | View raw


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 | NextPrevious in thread | Next in thread | Find similar | Unroll thread


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