Re: MSI proposal and work transfer...(was: Re: [Xen-devel] [PATCH 0 of 5] PV on HVM Xen)

[Sheng Yang <sheng@xxxxxxxxxxxxxxx>]

On Wednesday 24 March 2010 04:47:58 Jeremy Fitzhardinge wrote:
> On 03/21/2010 11:26 PM, Sheng Yang wrote:
> > On Saturday 20 March 2010 04:38:23 Jeremy Fitzhardinge wrote:
> >> On 03/17/2010 06:30 PM, Sheng Yang wrote:
> >>>> Xiantao has some interesting ideas for this.
> >>>
> >>> Xiantao and I have discussed on this for a month... Basically we have
> >>> got two approaches now, but we can't reach an agreement... I would work
> >>> on it after current hybrid thing settled down. Of course, we want MSI
> >>> support benefit pv_ops dom0 as well as hybrid.
> >>
> >> Xiantao's proposal of a new top-level MSI API for the kernel looks
> >> pretty clean, and I think it has a reasonable chance of being accepted
> >> upstream.
> >>
> >> What's your proposal?
> >
> > My proposal is to do these in the lower level compared to Xiantao's
> > proposal, because I don't think touch PCI subsystem is a good idea for
> > upstream check in.
> >
> > We can take advantage of the fact that MSI data/address formating can be
> > defined by each architecture, and at the same time, trap the accessing in
> > the Xen, passthrough the most PCI configuration space accessing but
> > intercepted MSI data/address accessing, so that we can write the real
> > data to the hardware when guest try to write Xen specific MSI
> > data/address format.
> >
> > The hook position would be arch_setup_msi_irqs(), which would create the
> > vector and write the x86 LAPIC specific format to MSI data/address. By
> > this way, we can limit the impact inside x86 arch. We would write the
> > information contained evtchn/PIRQ in it, so that we can setup the
> > mapping. And this same point works for MSI and MSI-X, and S3 wouldn't be
> > a issue if we trap the accessing.
> 
> I would be interested in seeing what the patches look like for this.
> 
> But to be quite honest, it could well be easier to introduce a new nice,
> clean, self-contained and consistent API at the appropriate level of
> abstraction rather than trying to shoe-horn one into the arch/x86
> layer.  It sounds like your proposal may well save some general kernel
> code changes, but at the expense of being quite complex under the covers.

I think the key for checking in is small footprint and only necessary changes 
allowed. PCI spec is there, define what's is MSI and MSI-X, and how should we 
deal with it. MSI hook is easy for Xen, but not easy for Linux upstream I 
think. 

Anyway, it's up to you...

-- 
regards
Yang, Sheng
 
> > Another thing is, due to some other task assignment to me days ago, I am
> > afraid I have to stop my working on PV extension of HVM guest, as well as
> > MSI work which we considered as a part of PV interrupt delivery mechanism
> > for Hybrid. You know, it's really a hard decision to me, but I have no
> > choice...
> >
> > So I would like to transfer the current work to someone who interested in
> > it. The next step is somehow clear. We would have a PV clocksource for
> > HVM, as well as PIRQ mapped irqchip to speed up interrupt delivery.
> >
> > Stefano, would you like help to take my work and continue it? I think no
> > one is more familiar with these discussion and code than you in the
> > community. The final target is still upstream Linux I hope...
> 
> That's unfortunate; things seem to have been progressing quite well, and
> I'd really like to get something ready to commit (and possibly upstream)
> soon.  Stefano, will you be able to finish things off?
> 
> Thanks,
>      J
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel