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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 21.11.17 at 19:02, <george.dunlap@xxxxxxxxxx> wrote:
> 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.

I have no idea at all.

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

In which case would you ind inserting "for example"?

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

May I suggest then that until then the section above be dropped?

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

But that's part of my point - you say "in the tree", but this is a
separate tree, and there could be any number of separate ones.

Jan


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