From mboxrd@z Thu Jan  1 00:00:00 1970
From: Julien Grall <julien.grall@citrix.com>
Subject: Re: [Xen-devel] [XEN][RFC PATCH 01/15] hvm: Modify
 interface to support multiple ioreq server
Date: Thu, 12 Apr 2012 20:33:25 +0100
Message-ID: <4F872E05.8090808@citrix.com>
References: <cover.1332430810.git.julien.grall@citrix.com>	
	<2187e535bf91f5f650401a4e08e0e795003ad2aa.1332430810.git.julien.grall@citrix.com>
	<1332502403.30916.23.camel@zakaz.uk.xensource.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: 7bit
Return-path: <qemu-devel-bounces+gceq-qemu-devel=gmane.org@nongnu.org>
In-Reply-To: <1332502403.30916.23.camel@zakaz.uk.xensource.com>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
Errors-To: qemu-devel-bounces+gceq-qemu-devel=gmane.org@nongnu.org
Sender: qemu-devel-bounces+gceq-qemu-devel=gmane.org@nongnu.org
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: Julian Pidancet <julian.pidancet@citrix.com>, "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, "qemu-devel@nongnu.org" <qemu-devel@nongnu.org>, Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
List-Id: xen-devel@lists.xenproject.org

On 03/23/2012 11:33 AM, Ian Campbell wrote:
> On Thu, 2012-03-22 at 15:59 +0000, Julien Grall wrote:
>    
>> Add structure to handle ioreq server. It's server which can
>> handle a range of IO (MMIO and/or PIO) and emulate a PCI.
>> Each server as its own shared page to receive ioreq. So
>> we have introduced to HVM PARAM to set/get the first and
>> the last shared used for ioreq.
>> With it's id, the server knows which page it must use.
>>      
> So id is always the page offset with the range? Why not just call it
> iobuf_offset then? Is the additional layer of abstraction from calling
> it "id" useful if we are just going to peek around it?
>    
Indeed, but this parameter is also used to register bdf/io range.
So can we call it server_id or server_offset ?

>> diff --git a/xen/include/public/hvm/hvm_op.h b/xen/include/public/hvm/hvm_op.h
>> index 6a78f75..1e0e27b 100644
>> --- a/xen/include/public/hvm/hvm_op.h
>> +++ b/xen/include/public/hvm/hvm_op.h
>> @@ -24,6 +24,8 @@
>>   #include "../xen.h"
>>   #include "../trace.h"
>>
>> +#include "hvm_info_table.h" /* HVM_MAX_VCPUS */
>>      
> You don't appear to use HVM_MAX_VCPUS anywhere in your additions?
>
>    
I use it in xen-all.c in QEMU. It permits to check that smp_cpus is lower
that the maximum of vpcus. It avoids page overflow.