Re: [Xen-devel] [PATCH v2 04/12] x86/altp2m: basic data structures and support routines.

[Ed White <edmund.h.white@xxxxxxxxx>]

On 06/29/2015 06:00 AM, Andrew Cooper wrote:
> On 26/06/15 22:17, Ed White wrote:
>> On 06/24/2015 03:29 AM, Andrew Cooper wrote:
>>> On 22/06/15 19:56, Ed White wrote:
>>>> diff --git a/xen/include/asm-x86/hvm/vcpu.h 
>>>> b/xen/include/asm-x86/hvm/vcpu.h
>>>> index 3d8f4dc..a1529c0 100644
>>>> --- a/xen/include/asm-x86/hvm/vcpu.h
>>>> +++ b/xen/include/asm-x86/hvm/vcpu.h
>>>> @@ -118,6 +118,13 @@ struct nestedvcpu {
>>>>  
>>>>  #define vcpu_nestedhvm(v) ((v)->arch.hvm_vcpu.nvcpu)
>>>>  
>>>> +struct altp2mvcpu {
>>>> +    uint16_t    p2midx;         /* alternate p2m index */
>>>> +    uint64_t    veinfo_gfn;     /* #VE information page guest pfn */
>>> Please use the recently-introduced pfn_t here.  pfn is a more
>>> appropriate term than gfn in this case.
>> Did you mean pfn_t, or xen_pfn_t?
> 
> Actually I meant gfn_t, per the followup I sent shortly afterwards.
> 
>> I'm having a hard time
>> figuring out how to use a pfn_t, I can't even assign
>> INVALID_PFN to one.
> 
> Documentation in c/s 177bd5f, example in c/s 24036a5.  The point of this
> 
> For now, it will require copious use of _gfn() and gfn_x() until the
> rest of the mm subsystem has been updated to use the new typesafe types.
> 

Understood. I am finding that the re-work to use gfn_t in this and patch 9
is making for very messy code, but I am doing it.

Ed


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