Re: [Xen-devel] [PATCH 1/8] viridian: add init hooks

[Paul Durrant <Paul.Durrant@xxxxxxxxxx>]

> -----Original Message-----
> From: Andrew Cooper
> Sent: 02 January 2019 17:37
> To: Paul Durrant <Paul.Durrant@xxxxxxxxxx>; xen-devel@xxxxxxxxxxxxxxxxxxxx
> Cc: Wei Liu <wei.liu2@xxxxxxxxxx>; Jan Beulich <jbeulich@xxxxxxxx>; Roger
> Pau Monne <roger.pau@xxxxxxxxxx>
> Subject: Re: [Xen-devel] [PATCH 1/8] viridian: add init hooks
> 
> On 02/01/2019 16:08, Andrew Cooper wrote:
> > On 20/12/2018 16:33, Paul Durrant wrote:
> >> This patch adds domain and vcpu init hooks for viridian features. The
> init
> >> hooks do not yet do anything; they will be added to by subsequent
> patches.
> >>
> >> Signed-off-by: Paul Durrant <paul.durrant@xxxxxxxxxx>
> > Please can we start by fixing the current, broken, initialisation and
> > destruction logic ?
> >
> > To get rid of DOMCTL_setmaxvcpus, we need the *_destroy() logic to be
> > fully idempotent.  Also, viridian_domain_deinit() should not call into
> > viridian_vcpu_deinit(), and viridian_vcpu_deinit() shouldn't be faking
> > up a write to the assist page.
> >
> > AFAICT, the deinit path is all entirely pointless at the moment and can
> > be deleted.
> 
> Given that we are now going to be allocating non-trivial structures for
> viridian domains, I'd like to float the idea of changing viridian
> initialisation to be a domaincreate flag, rather than blindly assuming
> that all HVM guests want it.

That would certainly be cleaner but sounds non-trivial.

> 
> I think this is going to be necessary part of fixing CPUID policy
> derivation in the longterm, because regenerating the policy when
> HVM_PARAM_VIRIDIAN changes isn't viable.
> 

Indeed, but again it's 'longterm'.

  Paul

> ~Andrew
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel