|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH v11 07/11] x86/hvm: Introduce viridian_save_vcpu_ctxt_one() func
On Vi, 2018-07-13 at 04:34 -0600, Jan Beulich wrote:
> >
> > >
> > > >
> > > > On 13.07.18 at 11:04, <aisaila@xxxxxxxxxxxxxxx> wrote:
> > --- a/xen/arch/x86/hvm/viridian.c
> > +++ b/xen/arch/x86/hvm/viridian.c
> > @@ -1026,20 +1026,26 @@ static int viridian_load_domain_ctxt(struct
> > domain *d, hvm_domain_context_t *h)
> > HVM_REGISTER_SAVE_RESTORE(VIRIDIAN_DOMAIN,
> > viridian_save_domain_ctxt,
> > viridian_load_domain_ctxt, 1,
> > HVMSR_PER_DOM);
> >
> > -static int viridian_save_vcpu_ctxt(struct domain *d,
> > hvm_domain_context_t *h)
> > +static int viridian_save_vcpu_ctxt_one(struct vcpu *v,
> > hvm_domain_context_t *h)
> > {
> > - struct vcpu *v;
> > + struct hvm_viridian_vcpu_context ctxt;
> >
> > - if ( !is_viridian_domain(d) )
> > + if ( !is_viridian_domain(v->domain) )
> > return 0;
> >
> > - for_each_vcpu( d, v ) {
> > - struct hvm_viridian_vcpu_context ctxt = {
> > - .vp_assist_msr = v-
> > >arch.hvm_vcpu.viridian.vp_assist.msr.raw,
> > - .vp_assist_pending = v-
> > >arch.hvm_vcpu.viridian.vp_assist.pending,
> > - };
> > + memset(&ctxt, 0, sizeof(ctxt));
> > + ctxt.vp_assist_msr = v-
> > >arch.hvm_vcpu.viridian.vp_assist.msr.raw;
> > + ctxt.vp_assist_pending = v-
> > >arch.hvm_vcpu.viridian.vp_assist.pending;
> >
> > - if ( hvm_save_entry(VIRIDIAN_VCPU, v->vcpu_id, h, &ctxt)
> > != 0 )
> > + return hvm_save_entry(VIRIDIAN_VCPU, v->vcpu_id, h, &ctxt);
> So you now hand on the return value here, but just to ...
>
> >
> > +}
> > +
> > +static int viridian_save_vcpu_ctxt(struct domain *d,
> > hvm_domain_context_t *h)
> > +{
> > + struct vcpu *v;
> > +
> > + for_each_vcpu( d, v ) {
> > + if ( viridian_save_vcpu_ctxt_one(v, h) != 0 )
> > return 1;
> ... not pass it on here. Is that really what we want? The vMCE case
> does
> it differently, for example. Which means - there are certainly
> inconsistencies right now, but since you have to touch all of this
> anyway,
> couldn't you make things end in a more consistent shape after this
> rework?
In the past there where either returning the value
from hvm_save_entry()(like in the hvm_save_tsc_adjust) or check the
return value(like in the hvm_save_cpu_ctxt ) like it did here. I made
all the save_one funcs return the value from hvm_save_entry() and then
check it in the save func so that they all return in the same way.
I don't say that the old way was bad but it was not consistent.
And yes I have missed the if() check int he save func in the vmce but I
think it's better to have the check in place there and have all the
save / save_one funcs consistent.
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |