> -----Original Message----- > From: Xen-devel [mailto:[email protected]] On Behalf > Of Paul Durrant > Sent: 03 January 2019 09:08 > To: Andrew Cooper <[email protected]>; xen- > [email protected] > Cc: Wei Liu <[email protected]>; Jan Beulich <[email protected]>; Roger > Pau Monne <[email protected]> > Subject: Re: [Xen-devel] [PATCH 1/8] viridian: add init hooks > > > -----Original Message----- > > From: Andrew Cooper > > Sent: 02 January 2019 17:37 > > To: Paul Durrant <[email protected]>; xen- > [email protected] > > Cc: Wei Liu <[email protected]>; Jan Beulich <[email protected]>; > Roger > > Pau Monne <[email protected]> > > 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 <[email protected]> > > > 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.
Looking at this a little more... Viridian is an x86 specific thing, so an extra flag in xen_arch_domainconfig would seem most appropriate. This would then need to wired into the appropriate place(s) in libxl. I'll have a look at how much work this is likely to be. Paul > > > > > 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 > [email protected] > https://lists.xenproject.org/mailman/listinfo/xen-devel _______________________________________________ Xen-devel mailing list [email protected] https://lists.xenproject.org/mailman/listinfo/xen-devel
