From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Michael S. Tsirkin" Subject: Re: [PATCH 2/2][RFC] KVM: Emulate MSI-X table and PBA in kernel Date: Thu, 30 Dec 2010 12:03:02 +0200 Message-ID: <20101230100302.GA6441@redhat.com> References: <1293007495-32325-1-git-send-email-sheng@linux.intel.com> <201012291655.19535.sheng@linux.intel.com> <20101229092824.GA2876@redhat.com> <201012301532.42341.sheng@linux.intel.com> <4D1C50B4.4020907@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Sheng Yang , Marcelo Tosatti , kvm@vger.kernel.org, Alex Williamson To: Avi Kivity Return-path: Received: from mx1.redhat.com ([209.132.183.28]:64043 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753184Ab0L3KDX (ORCPT ); Thu, 30 Dec 2010 05:03:23 -0500 Content-Disposition: inline In-Reply-To: <4D1C50B4.4020907@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: On Thu, Dec 30, 2010 at 11:28:20AM +0200, Avi Kivity wrote: > On 12/30/2010 09:32 AM, Sheng Yang wrote: > >> > >> I don't think it's going to work: we are not > >> in the context of the right process. Further > >> I think we should keep the option of > >> reading the PBA status from the device or host kernel open. > >> And generally having an interface > >> for functionality we don't implement is not a good idea: > >> you don't know whether you really can support the interface you promised. > > > >Well, I don't know if we want to read PBA from device directly. To me it's not a > >good idea because the real device has nothing to do with the one we show to the > >guest. > > Right. vPBA.bit = pPBA.bit | > recorded_pending_bit_from_lazy_masked_interrupt. At some level, this is correct. However both are *not* in userspace memory so an interface that assumes that pending bits in userspace are correct at all times is not going to work. There is also the spec requirement that the device clears the pending bit if the interrupt was not served but the condition that caused the event no longer applies, so that a driver can work just by polling pending bits. Personally I don't think this requirement works in real life - Seems more like a vague idea on behalf of spec authors - so hopefully guests do not use this. > > At least direct accessing the mask bits of real device would be very > >dangerous. Avi? > > Agree. > > -- > error compiling committee.c: too many arguments to function