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. Is there liable to be any provision in xl/libxl to have "unstable" configuration, which is easily identified as "may stop working / cease to exist / become invalid at any point in the future?" Alternatively, are there any other suggestions for alternative mechanisms? Thanks, ~Andrew _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
