Re: [Xen-devel] per-domain configuration and inappropriate use of globals

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 19.10.18 at 18:57, <andrew.cooper3@xxxxxxxxxx> wrote:
> Hello,
> 
> I noticed this most recently in the AVIC series from Janakarajan.  The
> global svm_avic boolean was left off-by-default because it doesn't work
> with nested virt yet.  The code in question was actually inherited from
> the VT-x side, and the general problem is systemic with how Xen has been
> developed in the past.
> 
> Nested virt is the easiest way to spot why this is an issue.  How to
> correctly inject an interrupt into a VM depends on the current
> configuration in the VMCB/VMCS, and in the case of nested virt, this is
> chosen (at least in part) by the L1 hypervisor.  Therefore, a global
> boolean isn't correct, because it cannot account for the fact that two
> VMCBs/VMCSs might be configured differently.
> 
> Other settings I've noticed recently are hap/iommu PT sharing, and
> unrestricted_guest, both of which would be more convenient for
> development if they were configurable per domain rather than requiring a
> host reboot to change.
> 
> In practice, having fine grain control of all the features like would be
> excellent for testing purposes, because it allows you to boot two
> otherwise-identical VMs with one configuration difference between them.
> 
> In the spirit of the already in progress domaincreate work, options like
> these should be selectable at domain creation time, and immutable
> thereafter.
> 
> That said, there is a plethora of tweakables, and I'm not sure how best
> to expose them.  While most (all?) of these options are inherently
> supported (as playing with them simulates what Xen would chose on
> different hardware), I expect there will be ample opportunity for people
> to break their systems if they tweak too much.

Wouldn't this be the case with globals as well? I'd prefer such choice
to be done through generic or arch-specific flags to domain creation.

Jan



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