From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:36388) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1X061V-0000l9-JV for qemu-devel@nongnu.org; Thu, 26 Jun 2014 05:31:25 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1X061O-0003dZ-48 for qemu-devel@nongnu.org; Thu, 26 Jun 2014 05:31:17 -0400 Received: from mail-we0-f178.google.com ([74.125.82.178]:47737) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1X061N-0003dP-VA for qemu-devel@nongnu.org; Thu, 26 Jun 2014 05:31:10 -0400 Received: by mail-we0-f178.google.com with SMTP id x48so3309681wes.37 for ; Thu, 26 Jun 2014 02:31:07 -0700 (PDT) Message-ID: <53ABE849.4070102@linaro.org> Date: Thu, 26 Jun 2014 11:30:49 +0200 From: Eric Auger MIME-Version: 1.0 References: <1401695374-4287-1-git-send-email-eric.auger@linaro.org> <1401695374-4287-7-git-send-email-eric.auger@linaro.org> <53AB3F70.2060603@suse.de> <53ABDF6E.5020002@linaro.org> <53ABE723.8030107@suse.de> In-Reply-To: <53ABE723.8030107@suse.de> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [RFC v3 06/10] virt: Assign a VFIO platform device with -device option List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Alexander Graf , eric.auger@st.com, christoffer.dall@linaro.org, qemu-devel@nongnu.org, kim.phillips@freescale.com, a.rigo@virtualopensystems.com Cc: peter.maydell@linaro.org, patches@linaro.org, stuart.yoder@freescale.com, alex.williamson@redhat.com, christophe.barnichon@st.com, a.motakis@virtualopensystems.com, kvmarm@lists.cs.columbia.edu On 06/26/2014 11:25 AM, Alexander Graf wrote: > > On 26.06.14 10:53, Eric Auger wrote: >> On 06/25/2014 11:30 PM, Alexander Graf wrote: >>> On 02.06.14 09:49, Eric Auger wrote: >>>> This patch aims at allowing the end-user to specify the device he >>>> wants to directly assign to his mach-virt guest in the QEMU command >>>> line. >>>> >>>> The QEMU platform device becomes generic. >>>> >>>> Current choice is to reuse the "-device" option. >>>> >>>> For example when assigning Calxeda Midway xgmac device this option >>>> is used: >>>> -device vfio-platform,vfio_device="fff51000.ethernet",\ >>>> compat="calxeda/hb-xgmac",mmap-timeout-ms=1000 >>> I think we're walking into the right direction, but there is one major >>> nit I have. I don't think we should have a -device vfio-platform. I >>> think we should have a -device vfio-xgmac that maybe inherits from an >>> abstrace vfio-platform class. >>> >>> That way machine code can assemble the device tree according to the >>> device and you can also implement hardware specific hacks or >>> dependencies if you need them - for example the MMIO masking to find an >>> EOI you did earlier. >> I must admit I am lacking experience of other devices than my dear >> xgmac. I can just say that for the time beeing the approach seems to fit >> some ARM Amba devices like PL330 DMA. We need to go further to identity >> the limits of this generic approach. > > No, I think we're better off not faking anything generic at all, because > I'm 99.9% sure it will never be generic in real-world device cases. > > And if we start doing things generically, people will soon want to have > other mad additions to do device specific things in generic code, such > as "take the device tree from the host, but modify property x, y and z". > Better be clear about our limits from the beginning :). > > Imagine vfio-platform as a transport, similar to TCP. We have ports and > moving data from left to right is always the same, but whether you need > to open 2 ports to get a working FTP data transfer is up to the > implementation of the protocol above. Same thing here. OK you convinced me. I will investigate that way then. Eric > > > Alex >