From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:49751) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z4Xce-0007fB-6x for qemu-devel@nongnu.org; Mon, 15 Jun 2015 12:52:33 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Z4Xca-0005B5-MH for qemu-devel@nongnu.org; Mon, 15 Jun 2015 12:52:32 -0400 Received: from mx0b-0016f401.pphosted.com ([67.231.156.173]:16574) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z4Xca-0005Aq-HB for qemu-devel@nongnu.org; Mon, 15 Jun 2015 12:52:28 -0400 From: Yehuda Yitschak Date: Mon, 15 Jun 2015 16:52:15 +0000 Message-ID: <1434387134955.13544@marvell.com> References: , <557ED62A.8050409@linaro.org> In-Reply-To: <557ED62A.8050409@linaro.org> 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: Eric Auger , "qemu-devel@nongnu.org" Cc: "alex.williamson@redhat.com" , Shadi Ammouri , Yuval Caduri =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 Ethernet= port=0A= >>> to a guest VM=0A= >>>=0A= >>> The eth port's HW partially supports virtualization since the data path= 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 ne= ed to=0A= >>> access control path registers which are shared for all guests.=0A= >>> AFAIK this is usually done with HW emulation using trap & emulate with= =0A= >>> QEMU.=0A= >>> So, to the best of my knowledge I need a mix of VFIO and HW emulation t= o=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 virtual = function (VF) gets =0A= a set of registers enabling it to perform data path but most of the configu= ration and management=0A= operations are controlled by the host using the Physical Function PF driver= . =0A= Are you familiar with that ?=0A= i know SR-IOV is not related to VFIO-PLATFORM but if the mixed of direct ac= cess and emulation=0A= exists there as well then maybe i can borrow some concepts =0A= =0A= Best regards=0A= =0A= Yehuda=0A= =0A= > Best Regards=0A= >=0A= > Eric=0A= >>>=0A= >>> Thanks=0A= >>>=0A= >>> Yehuda Yitschak=0A=