From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:43266) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z4YRz-0000UA-A0 for qemu-devel@nongnu.org; Mon, 15 Jun 2015 13:45:36 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Z4YRw-0003Ud-4B for qemu-devel@nongnu.org; Mon, 15 Jun 2015 13:45:35 -0400 Received: from mx0a-0016f401.pphosted.com ([67.231.148.174]:40717) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z4YRv-0003U5-I9 for qemu-devel@nongnu.org; Mon, 15 Jun 2015 13:45:31 -0400 From: Yehuda Yitschak Date: Mon, 15 Jun 2015 17:45:23 +0000 Message-ID: <1434390323396.66541@marvell.com> References: ,<557ED62A.8050409@linaro.org> <1434387134955.13544@marvell.com>, <1434388545.4927.411.camel@redhat.com> In-Reply-To: <1434388545.4927.411.camel@redhat.com> Content-Language: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 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: Alex Williamson Cc: Shadi Ammouri , "qemu-devel@nongnu.org" , Yuval Caduri , Eric Auger =0A= ________________________________________=0A= From: Alex Williamson =0A= Sent: Monday, June 15, 2015 8:15 PM=0A= To: Yehuda Yitschak=0A= Cc: Eric Auger; qemu-devel@nongnu.org; Yuval Caduri; Shadi Ammouri=0A= Subject: Re: Assigning an eth port to a guest VM=0A= =0A= On Mon, 2015-06-15 at 16:52 +0000, Yehuda Yitschak wrote:=0A= >> ________________________________________=0A= >> From: Eric Auger =0A= >> Sent: Monday, June 15, 2015 4:42 PM=0A= >> To: Yehuda Yitschak; qemu-devel@nongnu.org=0A= >> Cc: Yuval Caduri; Shadi Ammouri=0A= >> Subject: Re: Assigning an eth port to a guest VM=0A= >>=0A= >> Hi Yehuda,=0A= >> On 06/15/2015 01:01 PM, Yehuda Yitschak wrote:=0A= >> >> Cc: Eric Auger=0A= >> >>=0A= >> >>> -----Original Message-----=0A= >> >>> From: Yehuda Yitschak=0A= >> >>> Sent: Monday, June 15, 2015 9:35=0A= >> >>> To: qemu-devel@nongnu.org=0A= >> >>> Cc: Yuval Caduri; Shadi Ammouri=0A= >> >>> Subject: Assigning an eth port to a guest VM=0A= >> >>>=0A= >> >>> Hello=0A= >> >>>=0A= >> >>> I would to ask your advice on how to assign a semi-virtualized Ether= net port=0A= >> >>> to a guest VM=0A= >> >>>=0A= >> >>> The eth port's HW partially supports virtualization since the data p= ath MMIO=0A= >> >>> registers (which controls rx/tx operation) are duplicated per VM.=0A= >> >>> So for the run-time operation the guest can directly access the MMIO= =0A= >> >>> registers, using VFIO-PLATFORM, and enjoy the performance benefit.= =0A= >> >>>=0A= >> >>> However for the initial setup and occasional configuration the guest= need to=0A= >> >>> access control path registers which are shared for all guests.=0A= >> >>> AFAIK this is usually done with HW emulation using trap & emulate wi= th=0A= >> >>> QEMU.=0A= >> >>> So, to the best of my knowledge I need a mix of VFIO and HW emulatio= n to=0A= >> >>> get the port to work with device assignment , right ?=0A= >> > Yes to me you're correct.=0A= >> >>>=0A= >> >>> Are there any standard methods for achieving this ?=0A= >> >>> Is there an example for such an existing HW in QEMU ?=0A= >> > Not yet unfortunately. To my knowledge the only platform devices that= =0A= >> > were assigned with QEMU VFIO platform were standalone duplicated=0A= >> > devices, PL330, Calxeda Xgmac, SATA. So you are a trailblazer on that= =0A= >> > track.=0A= >>=0A= >> Thanks. It's good to know the diagnosis :-)=0A= >>=0A= >> BTW - i thought SR-IOV uses a somewhat similar concept. AFAIK each virtu= al function (VF) gets=0A= >> a set of registers enabling it to perform data path but most of the conf= iguration and management=0A= >> operations are controlled by the host using the Physical Function PF dri= ver.=0A= >> Are you familiar with that ?=0A= >> i know SR-IOV is not related to VFIO-PLATFORM but if the mixed of direct= access and emulation=0A= >> exists there as well then maybe i can borrow some concepts=0A= =0A= > The difference for SR-IOV is that emulation of shared resources is done= =0A= > almost entirely in the hardware. the PF configures the VFs and may=0A= >interact with them to some degree at runtime, but VFs are largely=0A= >separate devices from a software perspective.=0A= =0A= > The first question I would have for your device is whether there is=0A= > IOMMU isolation between the individual "functions". =0A= =0A= Yes. IOMMU isolation is possible. =0A= =0A= > If not, there's really nothing vfio can help with and they probably ought= to be used=0A= > more as a macvtap interface. If there is isolation, then I'd assume=0A= > we'd configure the device for direct access to the duplicated registers= =0A= > and trap to QEMU for the emulation portion. For things were the=0A= > emulation portion needs to interact with the "PF", interfaces would need= =0A= > to be created in the kernel.=0A= =0A= Can you give a short example of such an interface ? =0A= Do you mean a special device or ioctl to handle the emulation request from = QEMU/VFIO ?=0A= =0A= > The vfio-platform pieces specific to your=0A= > device might be the logical place for that interaction with the PF to=0A= > occur, ie. emulation at the vfio-platform interface rather than in QEMU= =0A= > itself. Thanks,=0A= =0A= That sounds simpler than adding QEMU to the mix. =0A= However for that to happen we need to trap into the vfio-platfrom driver, r= ight ? =0A= is that possible ? =0A= =0A= Thanks a lot =0A= =0A= Yehuda =0A= =0A= >=0A= > Alex=0A=