This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


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

To: Jeremy Fitzhardinge <jeremy@xxxxxxxx>
Subject: Re: MSI proposal and work transfer...(was: Re: [Xen-devel] [PATCH 0 of 5] PV on HVM Xen)
From: Sheng Yang <sheng@xxxxxxxxxxxxxxx>
Date: Wed, 24 Mar 2010 16:19:09 +0800
Cc: "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>, Don Dutile <ddutile@xxxxxxxxxx>, Keir Fraser <keir.fraser@xxxxxxxxxxxxx>, "Zhang, Xiantao" <xiantao.zhang@xxxxxxxxx>, Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>
Delivery-date: Wed, 24 Mar 2010 01:19:51 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <4BA928FE.9000200@xxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Organization: Intel Opensource Technology Center
References: <alpine.DEB.2.00.1003101457100.28412@kaball-desktop> <201003221426.34562.sheng@xxxxxxxxxxxxxxx> <4BA928FE.9000200@xxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: KMail/1.12.2 (Linux/2.6.31-20-generic; KDE/4.3.2; x86_64; ; )
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 

Anyway, it's up to you...

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

<Prev in Thread] Current Thread [Next in Thread>