From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:57000) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z4XzE-00006S-Ka for qemu-devel@nongnu.org; Mon, 15 Jun 2015 13:15:53 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Z4XzA-0005jA-8u for qemu-devel@nongnu.org; Mon, 15 Jun 2015 13:15:52 -0400 Received: from mx1.redhat.com ([209.132.183.28]:40426) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z4XzA-0005in-14 for qemu-devel@nongnu.org; Mon, 15 Jun 2015 13:15:48 -0400 Message-ID: <1434388545.4927.411.camel@redhat.com> From: Alex Williamson Date: Mon, 15 Jun 2015 11:15:45 -0600 In-Reply-To: <1434387134955.13544@marvell.com> References: ,<557ED62A.8050409@linaro.org> <1434387134955.13544@marvell.com> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] Assigning an eth port to a guest VM List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Yehuda Yitschak Cc: Shadi Ammouri , "qemu-devel@nongnu.org" , Yuval Caduri , Eric Auger On Mon, 2015-06-15 at 16:52 +0000, Yehuda Yitschak wrote: > ________________________________________ > From: Eric Auger > Sent: Monday, June 15, 2015 4:42 PM > To: Yehuda Yitschak; qemu-devel@nongnu.org > Cc: Yuval Caduri; Shadi Ammouri > Subject: Re: Assigning an eth port to a guest VM > > Hi Yehuda, > On 06/15/2015 01:01 PM, Yehuda Yitschak wrote: > >> Cc: Eric Auger > >> > >>> -----Original Message----- > >>> From: Yehuda Yitschak > >>> Sent: Monday, June 15, 2015 9:35 > >>> To: qemu-devel@nongnu.org > >>> Cc: Yuval Caduri; Shadi Ammouri > >>> Subject: Assigning an eth port to a guest VM > >>> > >>> Hello > >>> > >>> I would to ask your advice on how to assign a semi-virtualized Ethernet port > >>> to a guest VM > >>> > >>> The eth port's HW partially supports virtualization since the data path MMIO > >>> registers (which controls rx/tx operation) are duplicated per VM. > >>> So for the run-time operation the guest can directly access the MMIO > >>> registers, using VFIO-PLATFORM, and enjoy the performance benefit. > >>> > >>> However for the initial setup and occasional configuration the guest need to > >>> access control path registers which are shared for all guests. > >>> AFAIK this is usually done with HW emulation using trap & emulate with > >>> QEMU. > >>> So, to the best of my knowledge I need a mix of VFIO and HW emulation to > >>> get the port to work with device assignment , right ? > > Yes to me you're correct. > >>> > >>> Are there any standard methods for achieving this ? > >>> Is there an example for such an existing HW in QEMU ? > > Not yet unfortunately. To my knowledge the only platform devices that > > were assigned with QEMU VFIO platform were standalone duplicated > > devices, PL330, Calxeda Xgmac, SATA. So you are a trailblazer on that > > track. > > Thanks. It's good to know the diagnosis :-) > > BTW - i thought SR-IOV uses a somewhat similar concept. AFAIK each virtual function (VF) gets > a set of registers enabling it to perform data path but most of the configuration and management > operations are controlled by the host using the Physical Function PF driver. > Are you familiar with that ? > i know SR-IOV is not related to VFIO-PLATFORM but if the mixed of direct access and emulation > exists there as well then maybe i can borrow some concepts The difference for SR-IOV is that emulation of shared resources is done almost entirely in the hardware. the PF configures the VFs and may interact with them to some degree at runtime, but VFs are largely separate devices from a software perspective. The first question I would have for your device is whether there is IOMMU isolation between the individual "functions". If not, there's really nothing vfio can help with and they probably ought to be used more as a macvtap interface. If there is isolation, then I'd assume we'd configure the device for direct access to the duplicated registers and trap to QEMU for the emulation portion. For things were the emulation portion needs to interact with the "PF", interfaces would need to be created in the kernel. The vfio-platform pieces specific to your device might be the logical place for that interaction with the PF to occur, ie. emulation at the vfio-platform interface rather than in QEMU itself. Thanks, Alex