Re: [Xen-devel] [PATCH 08/16] SUPPORT.md: Add x86-specific virtual hardware

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 13.11.17 at 16:41, <george.dunlap@xxxxxxxxxx> wrote:
> +### x86/Nested PV
> +
> +    Status, x86 HVM: Tech Preview
> +
> +This means running a Xen hypervisor inside an HVM domain,
> +with support for PV L2 guests only
> +(i.e., hardware virtualization extensions not provided
> +to the guest).
> +
> +This works, but has performance limitations
> +because the L1 dom0 can only access emulated L1 devices.

So is this explicitly meaning Xen-on-Xen? Xen-on-KVM, for example,
could be considered "nested PV", too. IOW I think it needs to be
spelled out whether this means the host side of things here, the
guest one, or both.

> +### x86/Nested HVM
> +
> +    Status, x86 HVM: Experimental
> +
> +This means running a Xen hypervisor inside an HVM domain,
> +with support for running both PV and HVM L2 guests
> +(i.e., hardware virtualization extensions provided
> +to the guest).

"Nested HVM" generally means more than using Xen as the L1
hypervisor. If this is really to mean just L1 Xen, I think the title
should already say so, not just the description.

> +### x86/Advanced Vector eXtension
> +
> +    Status: Supported

As indicated before, I think this either needs to be dropped or
be extended by an entry for virtually every CPUID bit exposed
to guests. Furthermore, in this isolated fashion it is not clear
what derived features (e.g. FMA, FMA4, AVX2, or even AVX-512)
it is meant to imply. If any of them are implied, "with caveats"
would need to be added as long as the instruction emulator isn't
capable of handling the instructions, yet.

> +### x86/HVM EFI
> +
> +    Status: Supported
> +
> +Booting a guest via guest EFI firmware

Shouldn't this say OVMF, to avoid covering possible other
implementations?

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel