From mboxrd@z Thu Jan 1 00:00:00 1970 From: Gleb Natapov Subject: Re: [PATCH 2/2] x86, apicv: Add Posted Interrupt supporting Date: Fri, 8 Feb 2013 14:18:11 +0200 Message-ID: <20130208121811.GC19412@redhat.com> References: <20130204095553.GK23213@redhat.com> <20130204144345.GA11328@amt.cnet> <20130204171301.GB10756@redhat.com> <20130204195952.GA15856@amt.cnet> <20130204204729.GA16442@amt.cnet> <20130205073250.GT23213@redhat.com> <20130206224923.GA12266@amt.cnet> <20130207002406.GA16493@amt.cnet> <20130207135223.GK7837@redhat.com> <20130208020736.GA10109@amt.cnet> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: "Zhang, Yang Z" , "kvm@vger.kernel.org" , "Shan, Haitao" , "Zhang, Xiantao" , "Nakajima, Jun" , "Anvin, H Peter" To: Marcelo Tosatti Return-path: Received: from mx1.redhat.com ([209.132.183.28]:36616 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1946345Ab3BHMSO (ORCPT ); Fri, 8 Feb 2013 07:18:14 -0500 Content-Disposition: inline In-Reply-To: <20130208020736.GA10109@amt.cnet> Sender: kvm-owner@vger.kernel.org List-ID: On Fri, Feb 08, 2013 at 12:07:36AM -0200, Marcelo Tosatti wrote: > On Thu, Feb 07, 2013 at 03:52:24PM +0200, Gleb Natapov wrote: > > > Its not a bad idea to have a new KVM_REQ_ bit for PIR processing (just > > > as the current patches do). > > Without the numbers I do not see why. > > KVM_REQ_EVENT already means... counting... many things. Its a well Exactly my point. KVM_REQ_EVENT means many things, all of them event injection related. It can be split may be to 2/3 smaller request, but it will complicate the code and why would we do that without actually able to show performance improvements that split provides? > defined request, to sync PIR->VIRR, don't see your point about > performance. And it is just one more things that needs to be done during event injection. Without providing a good reason no need to handle it specially. Performance is convincing enough reason, but I what to see numbers. -- Gleb.