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

[George Dunlap <george.dunlap@xxxxxxxxxx>]

On 11/22/2017 11:11 AM, Jan Beulich wrote:
>>>> 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"?

Yes, I was planning doing that.  Sorry for not making my intention clear.

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

Ditto.

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

But not ones wired into xl or libxl.

On the other hand, it looks like the actual value you put in the xl
config file is 'ovmf', so that probably makes more sense.

 -George

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