From mboxrd@z Thu Jan  1 00:00:00 1970
From: Zhenzhong Duan <zhenzhong.duan@oracle.com>
Subject: Re: [PATCH 1/2] xen,
 libxc: init msix addr/data with value from qemu via hypercall
Date: Wed, 08 May 2013 18:00:23 +0800
Message-ID: <518A2237.9060709@oracle.com>
References: <518A0A15.60301@oracle.com>
	<518A397F02000078000D44AE@nat28.tlf.novell.com>
Reply-To: zhenzhong.duan@oracle.com
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Content-Transfer-Encoding: 7bit
Return-path: <xen-devel-bounces@lists.xen.org>
In-Reply-To: <518A397F02000078000D44AE@nat28.tlf.novell.com>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org
To: Jan Beulich <JBeulich@suse.com>
Cc: Chien Yen <chien.yen@oracle.com>, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>, Feng Jin <joe.jin@oracle.com>, Yuval Shaia <yuval.shaia@oracle.com>, xen-devel <xen-devel@lists.xen.org>
List-Id: xen-devel@lists.xenproject.org


On 2013-05-08 17:39, Jan Beulich wrote:
>>>> On 08.05.13 at 10:17, Zhenzhong Duan<zhenzhong.duan@oracle.com>  wrote:
>> Accelerated msix entry is initialized to zero when msixtbl_pt_register is
>> called. This doesn't match the value from qemu side, although pirq may
>> already
>> be mapped and binded in qemu side. Kernel will get wrong value when reading
>> msix info.
>>
>> Signed-off-by: Zhenzhong Duan<zhenzhong.duan@oracle.com>
>> Tested-by: Yuval Shaia<yuval.shaia@oracle.com>
> I appreciate this needing to change, but it is a no-go to expose an
> implementation detail of the hypervisor (number of accelerated
> entries being 3) trough a hypercall interface (and even less so by
> scattering around literal 3-s).
I presume you mean msi_ad[3]. msi_ad[3] is addr_lo, addr_high and data.
Not related to accelerated entries count.

or others?
> Please work towards a different solution, leaving the tool stack
> agnostic to the number of accelerated entries. And if at all
> possible, arrange for the patch to be split into tool stack and
> hypervisor pieces, such that they can be applied independently
> (and in either order).
sure, will do it after above question is clear.

Regards
zduan