On Monday 15 November 2010 16:03:53 Michael S. Tsirkin wrote: > On Mon, Nov 15, 2010 at 03:48:46PM +0800, Sheng Yang wrote: > > On Monday 15 November 2010 15:42:50 Michael S. Tsirkin wrote: > > > On Mon, Nov 15, 2010 at 03:37:21PM +0800, Sheng Yang wrote: > > > > > > We can back to them if there is someone really did it in that > > > > > > way. But for all hypervisors using QEmu, I think we haven't seen > > > > > > such kind of behavior yet. > > > > > > > > > > I would rather stick to the spec than go figure out what do > > > > > BSD/Sun/Mac do, or will do. > > > > > > > > Sure, but no hurry for that. It doesn't similar to the API case, so > > > > we can achieve it incrementally. > > > > > > Isn't the proposed way to solve this to move vector address/data > > > handling into kernel too? If yes it does affect the API. > > > > It didn't afffect the API used by this patch. So the code can still be > > modified after later. > > Then won't we have to support two APIs, forever? In fact for this patch, the logic is pretty straightforward. I don't think this patch would trouble us if we really have to support two APIs(userspace and in- kernel routing table) in the end. Just check msix_mmio_write(), you would find it just cost few lines(maybe just one line "r = -EOPNOTSUPP") to get the modification handled in userspace. All other logic mostly remained the same as in the this patch. IMO Mask bit support and irq routing are two separate things. It make no sense to block mask bit support patch due to the one idea of possible irq routing change in the future. -- regards Yang, Sheng > > > -- > > regards > > Yang, Sheng -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
