>>> On 20.03.17 at 14:42, <paul.durr...@citrix.com> wrote: >> From: Xen-devel [mailto:xen-devel-boun...@lists.xen.org] On Behalf Of Paul >> Durrant >> Sent: 20 March 2017 11:50 >> > From: Jan Beulich [mailto:jbeul...@suse.com] >> > Sent: 20 March 2017 11:36 >> > >>> On 17.03.17 at 10:57, <paul.durr...@citrix.com> wrote: >> > > --- a/xen/include/asm-x86/hvm/viridian.h >> > > +++ b/xen/include/asm-x86/hvm/viridian.h >> > > @@ -23,6 +23,7 @@ struct viridian_vcpu >> > > { >> > > struct { >> > > union viridian_vp_assist msr; >> > > + unsigned long gmfn; >> > >> > gfn_t ? >> > >> >> Yes, you're right. I should probably precede this with a patch fixing up the >> gmfn stack variables in viridian.c to use gfn_t for consistency though. > > Actually, looking at this again, I'm not sure there's any point in making > this a gfn_t. It's only stored for the purposes of an identity match and the > thing it matches with is an unsigned long extracted from an MSR bit-field.
Well, hence the question mark in my original reply: I did realize this, yet our mid term goal is to have all GFN variables properly typed, and I'm not sure we should make exceptions in cases like this one. (But then the question is still open whether what you use the field for is valid to do in the first place.) Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel