From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: Mask bit support's API Date: Tue, 23 Nov 2010 16:06:20 +0200 Message-ID: <4CEBCA5C.8040504@redhat.com> References: <201011231409.52666.sheng.yang@intel.com> <201011231630.36895.sheng.yang@intel.com> <4CEBB7E5.5030601@redhat.com> <201011232157.05130.sheng.yang@intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Marcelo Tosatti , "Michael S. Tsirkin" , "kvm@vger.kernel.org" To: "Yang, Sheng" Return-path: Received: from mx1.redhat.com ([209.132.183.28]:15743 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752711Ab0KWOGY (ORCPT ); Tue, 23 Nov 2010 09:06:24 -0500 In-Reply-To: <201011232157.05130.sheng.yang@intel.com> Sender: kvm-owner@vger.kernel.org List-ID: On 11/23/2010 03:57 PM, Yang, Sheng wrote: > > > > > > Yeah, but won't be included in this patchset. > > > > What API changes are needed? I'd like to see the complete API. > > I am not sure about it. But I suppose the structure should be the same? In fact > it's pretty hard for me to image what's needed for virtio in the future, > especially there is no such code now. I really prefer to deal with assigned device > and virtio separately, which would make the work much easier. But seems you won't > agree on that. First, I don't really see why the two cases are different (but I don't do a lot in this space). Surely between you and Michael, you have all the information? Second, my worry is a huge number of ABI variants that come from incrementally adding features. I want to implement bigger chunks of functionality. So I'd like to see all potential users addressed, at least from the ABI point of view if not the implementation. > > The API needs to be compatible with the pending bit, even if we don't > > implement it now. I want to reduce the rate of API changes. > > This can be implemented by this API, just adding a flag for it. And I would still > take this into consideration in the next API purposal. Shouldn't kvm also service reads from the pending bitmask? > > > > So instead of > > > > - guest reads/writes msix > > - kvm filters mmio, implements some, passes others to userspace > > > > we have > > > > - guest reads/writes msix > > - kvm implements all > > - some writes generate an additional notification to userspace > > I suppose we don't need to generate notification to userspace? Because every > read/write is handled by kernel, and userspace just need interface to kernel to > get/set the entry - and well, does userspace need to do it when kernel can handle > all of them? Maybe not... We could have the kernel handle addr/data writes by setting up an internal interrupt routing. A disadvantage is that more work is needed if we emulator interrupt remapping in qemu. -- error compiling committee.c: too many arguments to function