From mboxrd@z Thu Jan  1 00:00:00 1970
From: "Yu, Zhang" <yu.c.zhang@linux.intel.com>
Subject: Re: [PATCH] Refactor ioreq server for better performance
Date: Thu, 02 Jul 2015 20:17:54 +0800
Message-ID: <55952BF2.20001@linux.intel.com>
References: <1435314588-8815-1-git-send-email-yu.c.zhang@linux.intel.com>	<9AAE0902D5BC7E449B7C8E4E778ABCD0259742CB@AMSPEX01CL02.citrite.net>	<5592410B.5040509@linux.intel.com>
	<9AAE0902D5BC7E449B7C8E4E778ABCD02597573A@AMSPEX01CL02.citrite.net>
	<5593AC8B.2090103@linux.intel.com>
	<9AAE0902D5BC7E449B7C8E4E778ABCD025976ACD@AMSPEX01CL02.citrite.net>
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>
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <yu.c.zhang@linux.intel.com>) id 1ZAdXT-0004an-Tp
	for xen-devel@lists.xenproject.org; Thu, 02 Jul 2015 12:24:24 +0000
In-Reply-To: <9AAE0902D5BC7E449B7C8E4E778ABCD025976ACD@AMSPEX01CL02.citrite.net>
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: Paul Durrant <Paul.Durrant@citrix.com>, "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>, Andrew Cooper <Andrew.Cooper3@citrix.com>, "JBeulich@suse.com" <JBeulich@suse.com>, Kevin Tian <kevin.tian@intel.com>, "zhiyuan.lv@intel.com" <zhiyuan.lv@intel.com>
List-Id: xen-devel@lists.xenproject.org

[snip]

>>
>> Thanks, Paul.
>> Well, I agree the former approach would be simpler. But I still doubt
>> if this is more reasonable. :)
>> IIUC, one of the reasons for struct domain to have a rangeset list(and
>> a spinlock - rangesets_lock), is because there are iomem_caps and
>> irq_caps for each domain. These 2 rangeset members of struct domain are
>> platform independent.
>> However, struct rb_rangeset is only supposed to be used in ioreq
>> server, which is only for x86 hvm cases. Adding a rb_rangeset list
>> member(similarly, if so, a rb_rangesets_lock is also required) in
>> struct domain maybe useless for hardware domain and for platforms other
>> than x86.
>
> Fair enough.
>
>> So, I'd like to register a new debug key, to dump the ioreq server
>> informations, just like the keys to dump iommu p2m table or the irq
>> mappings. With a new debug key, we do not need to add a spinlock for
>> rb_rangeset in struct domain, the one in ioreq server would be enough.
>> Does this sound reasonable?
>>
>
> That would be ok with me, but I'm not sure about claiming a whole debug key for this. Is there any other one that you could piggy-back on? If not, then maybe just make it part of the 'q' output.

Thanks, my new implementation uses the 'q' debug key. Will send out the
new version later. :)

Yu
>
>    Paul
>

[snip]

>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Xen-devel mailing list
>>>>> Xen-devel@lists.xen.org
>>>>> http://lists.xen.org/xen-devel
>>>>>
>>>>>
>>>
>>> _______________________________________________
>>> Xen-devel mailing list
>>> Xen-devel@lists.xen.org
>>> http://lists.xen.org/xen-devel
>>>
>>>
>
>