This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


[Xen-devel] RE: One question to compat model

To: Keir Fraser <keir.fraser@xxxxxxxxxxxxx>, Jan Beulich <JBeulich@xxxxxxxxxx>
Subject: [Xen-devel] RE: One question to compat model
From: "Jiang, Yunhong" <yunhong.jiang@xxxxxxxxx>
Date: Thu, 13 May 2010 16:41:37 +0800
Accept-language: en-US
Acceptlanguage: en-US
Cc: "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Thu, 13 May 2010 01:43:42 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <C8102FAE.140A4%keir.fraser@xxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <789F9655DD1B8F43B48D77C5D30659731E5F2177@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> <C8102FAE.140A4%keir.fraser@xxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AcrxrVfRigO4XAJ7T6SYMC9ku2ZslAAAM51QAAFLEugAMG8F4A==
Thread-topic: One question to compat model
>-----Original Message-----
>From: Keir Fraser [mailto:keir.fraser@xxxxxxxxxxxxx]
>Sent: Wednesday, May 12, 2010 5:13 PM
>To: Jiang, Yunhong; Jan Beulich
>Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
>Subject: Re: One question to compat model
>On 12/05/2010 09:50, "Jiang, Yunhong" <yunhong.jiang@xxxxxxxxx> wrote:
>>> You can't disable CONFIG_COMPAT anymore, but I think you should
>>> be able to tweak the CONFIG_COMPAT section in
>>> xen/arch/x86/cpu/mcheck/mce.c in a way to allow your new code to
>>> be built without doing anything compat-related for the new
>>> structures. But maybe removing the domctl.h dependency already
>>> clarifies matters.
>> Yes, it should be ok. But a curios question is, why the xenctl_cpumap has to
>> be defined in domctl.h. It's simply a helper function. Now I have to work 
>> like
>> XENPF_getidletime, passing two parameters (nr_cpus and the bitmap pointer),
>> combine them in hypervisor to xenctl_cpumap and then call the xenctl_cpumap
>> code. And the same to user space tools.
>Whoever implemented XENPF_getidletime decided to stuff a fake xenctl_cpumap
>struct within Xen rather than properly refactor the public headers. There's
>no reason not to move xenctl_cpumap out into xen.h.

A curios question. I checked the code, and notice that the XEN_GUEST_HANDLE_64 
is only defined for __XEN__ or __XEN_TOOLS__. I can understand it is needed for 
tools because 32bit tools can be used in 64bit dom0, but why it is forbidden 
for kernel? To avoid it be passed as hypercall parameter? Sorry for bothering 
if this is a stupid question :$


> -- Keir

Xen-devel mailing list