WARNING - OLD ARCHIVES

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/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: [Xen-devel] Re: Xen/ia64 presentation

To: Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>
Subject: Re: [Xen-devel] Re: Xen/ia64 presentation
From: Hollis Blanchard <hollisb@xxxxxxxxxx>
Date: Wed, 27 Apr 2005 15:08:53 -0500
Cc: "Magenheimer, Dan \(HP Labs Fort Collins\)" <dan.magenheimer@xxxxxx>, Xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Wed, 27 Apr 2005 20:10:39 +0000
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <46747f931d038af6b7606bf02b93c216@xxxxxxxxxxxx>
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/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <516F50407E01324991DD6D07B0531AD535AFC4@xxxxxxxxxxxxxxxxxxxxxxxxxxxxx> <426FE40C.60102@xxxxxxxxxx> <fc7f187f35a21cfa7933a2b66afbd7b6@xxxxxxxxxxxx> <426FE884.2010904@xxxxxxxxxx> <46747f931d038af6b7606bf02b93c216@xxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mozilla Thunderbird 1.0.2 (X11/20050404)
Keir Fraser wrote:
> 
> On 27 Apr 2005, at 20:31, Hollis Blanchard wrote:
>>
>> On this subject, I'd also like to ask about full_execution_context_t.
>> execution_context_t is used in a fair number of places in the Xen core;
>> however full_execution_context_t seems to only be used in the dom0
>> interface.
>>
>> The in-Xen analog to full_execution_context_t is arch_exec_domain, with
>> many fields duplicated between the two. Could we consolidate these, or
>> at least give full_execution_context_t a name that better describes its
>> purpose?
> 
> Yes, that's another one that's gross. Maybe rename
> full_execution_context_t to execution_context_t, and rename existing
> execution_context_t to something else (cpu_reg_t, or something like that)?

execution_context_t is also struct xen_regs, so if we like typedefs then
xen_regs_t would be consistent. Right now, lots of code uses xen_regs
and lots uses execution_context_t... should that be made consistent?

xen_regs/execution_context_t seems to mean "state which xen code could
alter", so something to distinguish it from "all CPU state" would be
nice. Maybe something like this:

struct xen_state:  (now xen_regs) state which xen C/asm code could alter
struct vcpu_state: (now exec_domain) all virtual CPU state
struct arch_vcpu_state

("vcpu_regs" might not be good, since we could need to save other
context like software-controlled TLBs, and so "xen_state" would match
"vcpu_state".)

I guess you want to keep a separate virtual CPU struct for the dom0
interface to preserve the ABI? Calling that "execution_context_t" could
work; I don't know what else to call it.

-- 
Hollis Blanchard
IBM Linux Technology Center

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel