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

[Michael S. Tsirkin]

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