Re: [Xen-devel] [v5][PATCH 2/5] xen, gfx passthrough: create pseudo intel isa bridge

["Chen, Tiejun" <tiejun.chen@xxxxxxxxx>]

On 2014/6/25 17:44, Michael S. Tsirkin wrote:
> 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 :)
Currently we have to push this feature into upstream as our first 
priority, so unless something is really needed to address. Of course I 
hope this point what we're talking is not such a thing :)
But I can promise here I'd like to do this optimization with your guide 
next :)
> At least, don't add duplicate code for ROM.
Let me try this.

Thanks
Tiejun

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel