Re: [Xen-devel] [PATCH 2/7] x86/viridian: fix xen-hvmcrash when vp_assist page is present

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 20.03.17 at 14:42, <Paul.Durrant@xxxxxxxxxx> wrote:
>> From: Xen-devel [mailto:xen-devel-bounces@xxxxxxxxxxxxx] On Behalf Of Paul 
>> Durrant
>> Sent: 20 March 2017 11:50
>> > From: Jan Beulich [mailto:JBeulich@xxxxxxxx]
>> > Sent: 20 March 2017 11:36
>> > >>> On 17.03.17 at 10:57, <paul.durrant@xxxxxxxxxx> 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@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel