From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Michael S. Tsirkin" Subject: Re: [PATCH v4] kvm: Use a bitmap for tracking used GSIs Date: Mon, 18 May 2009 18:01:30 +0300 Message-ID: <20090518150130.GC23940@redhat.com> References: <1242256055.9456.326.camel@lappy> <4A1077F9.8040604@redhat.com> <20090518111246.GB3037@redhat.com> <4A114849.604@redhat.com> <20090518121952.GA14327@redhat.com> <4A115590.6030500@redhat.com> <20090518134504.GB23296@redhat.com> <4A1168D2.7090709@redhat.com> <20090518144020.GB23940@redhat.com> <4A1174B1.9080201@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Alex Williamson , kvm@vger.kernel.org, sheng.yang@intel.com To: Avi Kivity Return-path: Received: from mx2.redhat.com ([66.187.237.31]:55878 "EHLO mx2.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751798AbZERPCb (ORCPT ); Mon, 18 May 2009 11:02:31 -0400 Content-Disposition: inline In-Reply-To: <4A1174B1.9080201@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: On Mon, May 18, 2009 at 05:46:09PM +0300, Avi Kivity wrote: > Michael S. Tsirkin wrote: >>> If it generates the interrupt after masking it in the msi-x entry, >>> we'll see it. If it generates the interrupt before masking it, it >>> may or may not receive the interrupt, even on real hardware. >>> >> >> Yes but in the later case, real hardware must re-send the pending >> interrupt after it is unmasked (that's the spec). We would just lose it. >> > > That's a different matter. We need to buffer the interrupt pending bit, > and a way for userspace to either query that buffer or have a > conditional injection (inject_if_pending). Here's the race as I see it: we discussed the possibility of making kernel and user share and actual memory page, and using that for MSI-X tables. host kernel want to send msi x message host kernel test mask bit: unmasked guest sets mask bit guest does read to flash msi writes guest does sync irq and makes sure there are no outstanging interrupts ---> at this stage guest expects not to get interrupts guest starts editing msix entry host kernel never saw mask so it sends message to the old address or even a corrupted address which the guest is in the middle of editing bad things happen This race is not easy to solve, except by catching writes to msix table, and syncronising them with interrupt delivery. -- MST