On 22.02.2024 15:33, George Dunlap wrote:
> On Tue, Feb 20, 2024 at 12:25 AM Jan Beulich wrote:
>> On 06.02.2024 02:20, George Dunlap wrote:
>>> --- a/xen/arch/x86/hvm/vmx/vmx.c
>>> +++ b/xen/arch/x86/hvm/vmx/vmx.c
>>> @@ -3021,6 +3021,9 @@ const struct hvm_function_table * __init
>>>
On Tue, Feb 20, 2024 at 12:25 AM Jan Beulich wrote:
>
> On 06.02.2024 02:20, George Dunlap wrote:
> > --- /dev/null
> > +++ b/docs/designs/nested-svm-cpu-features.md
> > @@ -0,0 +1,110 @@
> > +# Nested SVM (AMD) CPUID requirements
> > +
> > +The first step in making nested SVM production-ready is
On 06.02.2024 02:20, George Dunlap wrote:
> --- /dev/null
> +++ b/docs/designs/nested-svm-cpu-features.md
> @@ -0,0 +1,110 @@
> +# Nested SVM (AMD) CPUID requirements
> +
> +The first step in making nested SVM production-ready is to make sure
> +that all features are implemented and well-tested.
On Tue, Feb 6, 2024 at 9:20 AM George Dunlap wrote:
> @@ -655,6 +658,12 @@ static inline bool hvm_altp2m_supported(void)
> return hvm_funcs.caps.altp2m;
> }
>
> +/* Returns true if we have the minimum hardware requirements for nested virt
> */
> +static inline bool
In order to make implementation and testing tractable, we will require
specific host functionality. Add a nested_virt bit to hvm_funcs.caps,
and return an error if a domain is created with nested virt and this
bit isn't set.
For VMX, start with always enabling it if HAP is present; this
