From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: [RFC][PATCH] qemu-kvm: Introduce writeback scope for cpu_synchronize_state Date: Tue, 17 Nov 2009 18:59:05 +0200 Message-ID: <4B02D659.2040004@redhat.com> References: <4B018542.3020602@siemens.com> <4B01A487.3020808@redhat.com> <4B01C2B0.3000205@web.de> <4B02592C.6060004@redhat.com> <4B025B50.4070505@web.de> <4B0260D7.1060107@redhat.com> <4B026A03.4080600@web.de> <4B0298F0.3080007@redhat.com> <4B029FA8.5080205@web.de> <4B02A4FD.4010802@redhat.com> <4B02AF58.4010407@web.de> <4B02B252.5080207@redhat.com> <4B02D444.6080402@web.de> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Marcelo Tosatti , kvm , Gleb Natapov To: Jan Kiszka Return-path: Received: from mx1.redhat.com ([209.132.183.28]:59548 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755226AbZKQQ7B (ORCPT ); Tue, 17 Nov 2009 11:59:01 -0500 In-Reply-To: <4B02D444.6080402@web.de> Sender: kvm-owner@vger.kernel.org List-ID: On 11/17/2009 06:50 PM, Jan Kiszka wrote: > >> I think we're not on the same page here. As I see it, no interface >> change is needed at all. >> >> It's true that existing kernels don't handle this properly, which is why >> I said I'm willing to treat it as a bug (and thus the -stable treatment >> etc.). I admit it's a stretch since this is not going to be trivial >> (though I think less complex that you believe). >> >> Putting mp_state into the events structure is reasonable regardless of >> this issue (and doable since we haven't pushed it to 2.6.33 yet). But I >> want to understand why you think it's needed. >> >> > That wouldn't be required anymore with the "always queue" policy. > It makes sense from a grouping point of view... maybe. > But what would you queue at all? Only mp_state, nmi_pending and > sipi_vector? INIT, too. > Or also all the relevant PIC and LAPIC states that might be > changed asynchronously? > LAPIC cannot support RMW atm because of the timer counts. We may in the future support LAPIC as well if needed. PIC and IOAPIC need full vm stop due to many async sources (KVM_IRQ_LINE from multiple threads, device assignment interrupts, irqfd, lapic EOI messages). vcpu state has the advantage of being almost completely synchronous. -- error compiling committee.c: too many arguments to function