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

[George Dunlap <george.dunlap@xxxxxxxxxx>]

On 11/21/2017 08:39 AM, Jan Beulich wrote:
>>>> 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.

Yes, that's true.  But I forget: Can a Xen dom0 use virtio guest
drivers?  I'm pretty sure Stefano tried it at some point but I don't
remember what the result was.

>> +### 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.

Yes, I mean any sort of nested guest support here.

>> +### 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.

Adding a section for CPUID bits supported (and to what level) sounds
like a useful thing to do, perhaps in the next release.

>> +### x86/HVM EFI
>> +
>> +    Status: Supported
>> +
>> +Booting a guest via guest EFI firmware
> 
> Shouldn't this say OVMF, to avoid covering possible other
> implementations?

I don't expect that we'll ever need more than one EFI implementation in
the tree.  If a time comes when it makes sense to have two, we can
adjust the entry accordingly.

 -George


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