From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:37201) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z5GxD-0008Kb-11 for qemu-devel@nongnu.org; Wed, 17 Jun 2015 13:16:48 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Z5Gx7-00084U-UL for qemu-devel@nongnu.org; Wed, 17 Jun 2015 13:16:46 -0400 Received: from mx0b-0016f401.pphosted.com ([67.231.156.173]:56991) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z5Gx7-000842-Lz for qemu-devel@nongnu.org; Wed, 17 Jun 2015 13:16:41 -0400 From: Yehuda Yitschak Date: Wed, 17 Jun 2015 17:16:33 +0000 Message-ID: <1434561393271.4638@marvell.com> References: ,<557ED62A.8050409@linaro.org> <1434387134955.13544@marvell.com> , <1434388545.4927.411.camel@redhat.com> <1434390323396.66541@marvell.com> <1434393099.4927.427.camel@redhat.com> , <1434465801.4927.465.camel@redhat.com> In-Reply-To: <1434465801.4927.465.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= > >=0A= > > Eric, Alex, Thank you very much for all your answers and details.=0A= > > From your answers it sounds like I need to extended vfio's resource que= ry mechanism to enable flagging=0A= > > certain resources as NO_MAP and then make VFIO in QEMU act accordingly.= =0A= > > That looks like the easier part. The more complex part in my view is to= manage the trap to vfio-platform driver and emulate the access.=0A= > >=0A= > > In any way, I will take some time to process all this into a solution a= nd fill in some gaps in my knowledge.=0A= > =0A= > TBH, I don't see any need to extend VFIO based on your needs so far.=0A= > VFIO already has the ability to describe whether a region supports mmap.= =0A= > If it doesn't support mmap, QEMU has no choice but to use an I/O memory= =0A= > region and translate VM accesses into reads and writes. vfio-pci=0A= > already makes extensive use of this capability today. I/O port regions= =0A= > don't support mmap on x86, so those regions never expose an mmap capable= =0A= > flag. We also require page alignment for mmap, so regions that are not= =0A= > page aligned don't expose mmap for MMIO regions. PCI config space also= =0A= > does not support mmap because of the emulation and virtualization we do= =0A= > in that space. So not supporting mmap is really not uncommon. You=0A= > might want to look at my slides from KVM Forum 2013 [1] which shows how= =0A= > VFIO can really be thought of as a conduit for decomposing a device=0A= > through a file descriptor. QEMU then recomposes it back into a device=0A= > through the QEMU driver model. Since platform devices have no standard= =0A= > like PCI to provide self discovery, there are device specific drivers on= =0A= > both ends with vfio-platform. Thanks,=0A= =0A= Ok...it looks like i need dig in some more into the code :)=0A= This is very helpful.=0A= Thanks =0A= =0A= Yehuda =0A= =0A= > =0A= > Alex=0A= > =0A= > [1] http://www.linux-kvm.org/images/e/ed/Kvm-forum-2013-VFIO-VGA.pdf=0A= =0A=