From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Gabriel L. Somlo" Subject: Re: RFC: ioapic polarity vs. qemu os-x guest Date: Mon, 17 Feb 2014 19:58:34 -0500 Message-ID: <20140218005833.GA7676@crash.ini.cmu.edu> References: <20140214220600.GI29329@ERROL.INI.CMU.EDU> <2CEB9F8C-E983-4182-A514-44EC568E18D8@suse.de> <20140216114151.GB30056@redhat.com> <1392562020.15608.437.camel@ul30vt.home> <20140216162300.GI30056@redhat.com> <20140217175659.GP29329@ERROL.INI.CMU.EDU> <20140217180136.GQ29329@ERROL.INI.CMU.EDU> <53024F93.3040709@redhat.com> <20140217193808.GR29329@ERROL.INI.CMU.EDU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: "Michael S. Tsirkin" , Alex Williamson , Alexander Graf , "kvm@vger.kernel.org" , "qemu-devel@nongnu.org" , "eddie.dong@intel.com" To: Paolo Bonzini Return-path: Received: from mail-qa0-f41.google.com ([209.85.216.41]:54467 "EHLO mail-qa0-f41.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753811AbaBRA6l (ORCPT ); Mon, 17 Feb 2014 19:58:41 -0500 Received: by mail-qa0-f41.google.com with SMTP id w8so22890979qac.28 for ; Mon, 17 Feb 2014 16:58:41 -0800 (PST) Content-Disposition: inline In-Reply-To: <20140217193808.GR29329@ERROL.INI.CMU.EDU> Sender: kvm-owner@vger.kernel.org List-ID: On Mon, Feb 17, 2014 at 02:38:09PM -0500, Gabriel L. Somlo wrote: > Oh, I think I'm starting to comprehend the problem here. The bits of > "*irq_state" are indexed by "irq_source_id", which is dynamically > assigned by kvm_request_irq_source_id(). > > So, doing the OR thing when assuming always-active-high makes > sense. Doing AND based on an active-low assumption doesn't make > sense, because there could ALWAYS be 0 bits that just weren't > allocated (yet), and I'm having trouble imagining how I'd keep > track of where the current allocation boundary is in a sane way :) Hmm, I thought maybe I could use kvm->arch.irq_sources_bitmap, but that's global across the whole VM, whereas irq_state belongs to one given GSI. So, the per-GSI bitmap is sparse, so it's at least as bad as I thought earlier, if not worse :) Am I missing anything that would put this in a better light ? Thanks, --Gabriel From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:58043) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WFZ1P-00007W-PI for qemu-devel@nongnu.org; Mon, 17 Feb 2014 19:59:01 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WFZ1E-0002kz-O8 for qemu-devel@nongnu.org; Mon, 17 Feb 2014 19:58:51 -0500 Received: from mail-qg0-x22f.google.com ([2607:f8b0:400d:c04::22f]:56430) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WFZ1E-0002kv-Io for qemu-devel@nongnu.org; Mon, 17 Feb 2014 19:58:40 -0500 Received: by mail-qg0-f47.google.com with SMTP id 63so5962322qgz.6 for ; Mon, 17 Feb 2014 16:58:40 -0800 (PST) Date: Mon, 17 Feb 2014 19:58:34 -0500 From: "Gabriel L. Somlo" Message-ID: <20140218005833.GA7676@crash.ini.cmu.edu> References: <20140214220600.GI29329@ERROL.INI.CMU.EDU> <2CEB9F8C-E983-4182-A514-44EC568E18D8@suse.de> <20140216114151.GB30056@redhat.com> <1392562020.15608.437.camel@ul30vt.home> <20140216162300.GI30056@redhat.com> <20140217175659.GP29329@ERROL.INI.CMU.EDU> <20140217180136.GQ29329@ERROL.INI.CMU.EDU> <53024F93.3040709@redhat.com> <20140217193808.GR29329@ERROL.INI.CMU.EDU> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140217193808.GR29329@ERROL.INI.CMU.EDU> Subject: Re: [Qemu-devel] RFC: ioapic polarity vs. qemu os-x guest List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini Cc: "kvm@vger.kernel.org" , "Michael S. Tsirkin" , "eddie.dong@intel.com" , "qemu-devel@nongnu.org" , Alexander Graf , Alex Williamson On Mon, Feb 17, 2014 at 02:38:09PM -0500, Gabriel L. Somlo wrote: > Oh, I think I'm starting to comprehend the problem here. The bits of > "*irq_state" are indexed by "irq_source_id", which is dynamically > assigned by kvm_request_irq_source_id(). > > So, doing the OR thing when assuming always-active-high makes > sense. Doing AND based on an active-low assumption doesn't make > sense, because there could ALWAYS be 0 bits that just weren't > allocated (yet), and I'm having trouble imagining how I'd keep > track of where the current allocation boundary is in a sane way :) Hmm, I thought maybe I could use kvm->arch.irq_sources_bitmap, but that's global across the whole VM, whereas irq_state belongs to one given GSI. So, the per-GSI bitmap is sparse, so it's at least as bad as I thought earlier, if not worse :) Am I missing anything that would put this in a better light ? Thanks, --Gabriel