From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Michael S. Tsirkin" Subject: Re: [PATCH 4/6] KVM: Add kvm_get_irq_routing_entry() func Date: Thu, 18 Nov 2010 14:33:16 +0200 Message-ID: <20101118123316.GD31987@redhat.com> References: <1289812532-3227-1-git-send-email-sheng@linux.intel.com> <1289812532-3227-5-git-send-email-sheng@linux.intel.com> <4CE3E045.30500@redhat.com> <201011181022.15853.sheng@linux.intel.com> <4CE4F247.9080203@redhat.com> <20101118094151.GJ16832@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: Avi Kivity , Sheng Yang , Marcelo Tosatti , kvm@vger.kernel.org To: Sheng Yang Return-path: Received: from mx1.redhat.com ([209.132.183.28]:21637 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755568Ab0KRMd3 (ORCPT ); Thu, 18 Nov 2010 07:33:29 -0500 Content-Disposition: inline In-Reply-To: Sender: kvm-owner@vger.kernel.org List-ID: On Thu, Nov 18, 2010 at 07:59:10PM +0800, Sheng Yang wrote: > On Thu, Nov 18, 2010 at 5:41 PM, Michael S. Tsirkin = wrote: > > On Thu, Nov 18, 2010 at 11:30:47AM +0200, Avi Kivity wrote: > >> >> > >> >> =A0*entry may be stale after rcu_read_unlock(). =A0Is this a pr= oblem? > >> > > >> >I suppose not. All MSI-X MMIO accessing would be executed without= delay, so no re- > >> >order issue would happen. If the guest is reading and writing the= field at the same > >> >time(from two cpus), it should got some kinds of sync method for = itself - or it > >> >may not care what's the reading result(like the one after msix_ma= sk_irq()). > >> > >> I guess so. =A0Michael/Alex? > > > > This is kvm_get_irq_routing_entry which is used for table reads, > > correct? =A0Actually, the pci read *is* the sync method that guests= use, > > they rely on reads to flush out all previous writes. >=20 > Michael, I think the *sync* you are talking about is not the one I > meant. I was talking about two cpus case, one is reading and the othe= r > is writing, the order can't be determined if guest doesn't use lock o= r > some other synchronize methods; and you're talking about to flush out > all previous writes of the only one CPU... Yes, but you don't seem to flush out writes on a read, either. > --=20 > regards, > Yang, Sheng