From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:39891) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WzjlM-0008Ds-SA for qemu-devel@nongnu.org; Wed, 25 Jun 2014 05:45:16 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WzjlC-0002rh-S1 for qemu-devel@nongnu.org; Wed, 25 Jun 2014 05:45:08 -0400 Received: from mx1.redhat.com ([209.132.183.28]:60899) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WzjlC-0002rX-IV for qemu-devel@nongnu.org; Wed, 25 Jun 2014 05:44:58 -0400 Date: Wed, 25 Jun 2014 12:44:55 +0300 From: "Michael S. Tsirkin" Message-ID: <20140625094455.GB6357@redhat.com> References: <20140625064545.GB25563@redhat.com> <53AA8404.8040708@intel.com> <20140625082850.GB32652@redhat.com> <53AA8AAB.30100@intel.com> <20140625084347.GE32652@redhat.com> <53AA8CC2.7090406@intel.com> <20140625090420.GG32652@redhat.com> <53AA92F6.1090803@intel.com> <20140625092141.GL32652@redhat.com> <53AA9650.1060503@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <53AA9650.1060503@intel.com> Subject: Re: [Qemu-devel] [v5][PATCH 2/5] xen, gfx passthrough: create pseudo intel isa bridge List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Chen, Tiejun" Cc: peter.maydell@linaro.org, xen-devel@lists.xensource.com, stefano.stabellini@eu.citrix.com, allen.m.kay@intel.com, qemu-devel@nongnu.org, Kelly.Zytaruk@amd.com, yang.z.zhang@intel.com, anthony@codemonkey.ws, anthony.perard@citrix.com, pbonzini@redhat.com On Wed, Jun 25, 2014 at 05:28:48PM +0800, Chen, Tiejun wrote: > On 2014/6/25 17:21, Michael S. Tsirkin wrote: > >On Wed, Jun 25, 2014 at 05:14:30PM +0800, Chen, Tiejun wrote: > >>On 2014/6/25 17:04, Michael S. Tsirkin wrote: > >>>On Wed, Jun 25, 2014 at 04:48:02PM +0800, Chen, Tiejun wrote: > >>>>On 2014/6/25 16:43, Michael S. Tsirkin wrote: > >>>>>On Wed, Jun 25, 2014 at 04:39:07PM +0800, Chen, Tiejun wrote: > >>>>>>>In fact it's exactly what passthrough does. > >>>>>>>I wonder if more bits from ./hw/i386/kvm/pci-assign.c > >>>>>>>can be reused. How do you poke at the host device? sysfs? > >>>>>> > >>>>>>Yes, sysfs. > >>>>>> > >>>>>>Thanks > >>>>>>Tiejun > >>>>> > >>>>>Then you should be able to re-use large chunks of > >>>>>./hw/i386/kvm/pci-assign.c: basically everything > >>>>>that deals with emulation. > >>>> > >>>>Do you mean those hooks to get info from the real device? Xen have its own > >>>>wrapper, xen_host_pci_get_block(), so we always go there in xen scenario. > >>>> > >>>>Thanks > >>>>Tiejun > >>> > >>>Yes and that's not good. We have two pieces of code doing mostly > >>>identical things slightly differently. > >>>hw/i386/kvm/pci-assign.c is a bit younger so it's cleaner, > >>>but these really need to be unified. > >>> > >> > >>Sorry, take a look at this again, > >> > >>xen_host_pci_get_block(XenHostPCIDevice *d, int pos, uint8_t *buf, int len) > >> | > >> + xen_host_pci_config_read(d, pos, buf, len) > >> | > >> + pread(d->config_fd, buf, len, pos) > >> > >>I thinks this should be same as kvm. > >> > >>Thanks > >>Tiejun > > > >get_block is trivial. > > > >I really mean the whole PT infrastructure for > >- discovering host devices through sysfs > >- virtualizing devices > > > >rom, bars, msi ... > >the list goes on. > > > >logic is mostly the same. > > > > Looks you mean we can unify the entire PT infrastructure between kvm and xen > inside qemu. But I'm afraid its not easy to do in a short time, so maybe we > can queue this as next phase. > > Thanks > Tiejun I'm afraid once we merge your code, you'll lose interest :) At least, don't add duplicate code for ROM. -- MST From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Michael S. Tsirkin" Subject: Re: [v5][PATCH 2/5] xen, gfx passthrough: create pseudo intel isa bridge Date: Wed, 25 Jun 2014 12:44:55 +0300 Message-ID: <20140625094455.GB6357@redhat.com> References: <20140625064545.GB25563@redhat.com> <53AA8404.8040708@intel.com> <20140625082850.GB32652@redhat.com> <53AA8AAB.30100@intel.com> <20140625084347.GE32652@redhat.com> <53AA8CC2.7090406@intel.com> <20140625090420.GG32652@redhat.com> <53AA92F6.1090803@intel.com> <20140625092141.GL32652@redhat.com> <53AA9650.1060503@intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Content-Disposition: inline In-Reply-To: <53AA9650.1060503@intel.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: qemu-devel-bounces+gceq-qemu-devel=gmane.org@nongnu.org Sender: qemu-devel-bounces+gceq-qemu-devel=gmane.org@nongnu.org To: "Chen, Tiejun" Cc: peter.maydell@linaro.org, xen-devel@lists.xensource.com, stefano.stabellini@eu.citrix.com, allen.m.kay@intel.com, qemu-devel@nongnu.org, Kelly.Zytaruk@amd.com, yang.z.zhang@intel.com, anthony@codemonkey.ws, anthony.perard@citrix.com, pbonzini@redhat.com List-Id: xen-devel@lists.xenproject.org On Wed, Jun 25, 2014 at 05:28:48PM +0800, Chen, Tiejun wrote: > On 2014/6/25 17:21, Michael S. Tsirkin wrote: > >On Wed, Jun 25, 2014 at 05:14:30PM +0800, Chen, Tiejun wrote: > >>On 2014/6/25 17:04, Michael S. Tsirkin wrote: > >>>On Wed, Jun 25, 2014 at 04:48:02PM +0800, Chen, Tiejun wrote: > >>>>On 2014/6/25 16:43, Michael S. Tsirkin wrote: > >>>>>On Wed, Jun 25, 2014 at 04:39:07PM +0800, Chen, Tiejun wrote: > >>>>>>>In fact it's exactly what passthrough does. > >>>>>>>I wonder if more bits from ./hw/i386/kvm/pci-assign.c > >>>>>>>can be reused. How do you poke at the host device? sysfs? > >>>>>> > >>>>>>Yes, sysfs. > >>>>>> > >>>>>>Thanks > >>>>>>Tiejun > >>>>> > >>>>>Then you should be able to re-use large chunks of > >>>>>./hw/i386/kvm/pci-assign.c: basically everything > >>>>>that deals with emulation. > >>>> > >>>>Do you mean those hooks to get info from the real device? Xen have its own > >>>>wrapper, xen_host_pci_get_block(), so we always go there in xen scenario. > >>>> > >>>>Thanks > >>>>Tiejun > >>> > >>>Yes and that's not good. We have two pieces of code doing mostly > >>>identical things slightly differently. > >>>hw/i386/kvm/pci-assign.c is a bit younger so it's cleaner, > >>>but these really need to be unified. > >>> > >> > >>Sorry, take a look at this again, > >> > >>xen_host_pci_get_block(XenHostPCIDevice *d, int pos, uint8_t *buf, int len) > >> | > >> + xen_host_pci_config_read(d, pos, buf, len) > >> | > >> + pread(d->config_fd, buf, len, pos) > >> > >>I thinks this should be same as kvm. > >> > >>Thanks > >>Tiejun > > > >get_block is trivial. > > > >I really mean the whole PT infrastructure for > >- discovering host devices through sysfs > >- virtualizing devices > > > >rom, bars, msi ... > >the list goes on. > > > >logic is mostly the same. > > > > Looks you mean we can unify the entire PT infrastructure between kvm and xen > inside qemu. But I'm afraid its not easy to do in a short time, so maybe we > can queue this as next phase. > > Thanks > Tiejun I'm afraid once we merge your code, you'll lose interest :) At least, don't add duplicate code for ROM. -- MST