>>> On 19.10.18 at 18:57, <andrew.coop...@citrix.com> 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@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
