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

[Sheng Yang <sheng@xxxxxxxxxxxxxxx>]

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've used this way on MSI support for hybrid guest several months ago, and the 
kernel code impact is very small(of course, at that time, the intercept is in 
QEmu rather than Xen).

I think it's not easy for a hook in the whole PCI subsystem to be accepted by 
upstream Linux. Anyway, it's my estimation. 

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... 

Thanks!

-- 
regards
Yang, Sheng

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