| Message ID | 20171113154126.13038-8-george.dunlap@citrix.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
>>> On 13.11.17 at 16:41, <george.dunlap@citrix.com> 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
On 11/21/2017 08:39 AM, Jan Beulich wrote: >>>> On 13.11.17 at 16:41, <george.dunlap@citrix.com> 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
>>> On 21.11.17 at 19:02, <george.dunlap@citrix.com> wrote: > On 11/21/2017 08:39 AM, Jan Beulich wrote: >>>>> On 13.11.17 at 16:41, <george.dunlap@citrix.com> 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
On 11/22/2017 11:11 AM, Jan Beulich wrote: >>>> On 21.11.17 at 19:02, <george.dunlap@citrix.com> wrote: >> On 11/21/2017 08:39 AM, Jan Beulich wrote: >>>>>> On 13.11.17 at 16:41, <george.dunlap@citrix.com> 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
On 11/22/2017 11:11 AM, Jan Beulich wrote: >>>> +### 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. I've put the following: --- ### x86/HVM OVMF Status: Supported OVMF firmware implements the UEFI boot protocol. --- -George
On 11/22/2017 11:11 AM, Jan Beulich wrote: >>>> On 21.11.17 at 19:02, <george.dunlap@citrix.com> wrote: >> On 11/21/2017 08:39 AM, Jan Beulich wrote: >>>>>> On 13.11.17 at 16:41, <george.dunlap@citrix.com> 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. I've changed this to "Status, x86 Xen HVM: Tech Preview", and noted that it may work for other hypervisors but we haven't received any concrete reports. -George
diff --git a/SUPPORT.md b/SUPPORT.md index 20c58377a5..b95ee0ebe7 100644 --- a/SUPPORT.md +++ b/SUPPORT.md @@ -376,6 +376,112 @@ there is currently no xl support. Status: Supported +## Virtual Hardware, Hypervisor + +### 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. + +### 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). + +### x86/Advanced Vector eXtension + + Status: Supported + +### vPMU + + Status, x86: Supported, Not security supported + +Virtual Performance Management Unit for HVM guests + +Disabled by default (enable with hypervisor command line option). +This feature is not security supported: see http://xenbits.xen.org/xsa/advisory-163.html + +## Virtual Hardware, QEMU + +These are devices available in HVM mode using a qemu devicemodel (the default). +Note that other devices are available but not security supported. + +### x86/Emulated platform devices (QEMU): + + Status, piix3: Supported + +### x86/Emulated network (QEMU): + + Status, e1000: Supported + Status, rtl8193: Supported + Status, virtio-net: Supported + +### x86/Emulated storage (QEMU): + + Status, piix3 ide: Supported + Status, ahci: Supported + +### x86/Emulated graphics (QEMU): + + Status, cirrus-vga: Supported + Status, stgvga: Supported + +### x86/Emulated audio (QEMU): + + Status, sb16: Supported + Status, es1370: Supported + Status, ac97: Supported + +### x86/Emulated input (QEMU): + + Status, usbmouse: Supported + Status, usbtablet: Supported + Status, ps/2 keyboard: Supported + Status, ps/2 mouse: Supported + +### x86/Emulated serial card (QEMU): + + Status, UART 16550A: Supported + +### x86/Host USB passthrough (QEMU): + + Status: Supported, not security supported + +## Virtual Firmware + +### x86/HVM iPXE + + Status: Supported, with caveats + +Booting a guest via PXE. +PXE inherently places full trust of the guest in the network, +and so should only be used +when the guest network is under the same administrative control +as the guest itself. + +### x86/HVM BIOS + + Status: Supported + +Booting a guest via guest BIOS firmware + +### x86/HVM EFI + + Status: Supported + +Booting a guest via guest EFI firmware + # Format and definitions This file contains prose, and machine-readable fragments.
x86-specific virtual hardware provided by the hypervisor, toolstack, or QEMU. Signed-off-by: George Dunlap <george.dunlap@citrix.com> --- Added emulated QEMU support, to replace docs/misc/qemu-xen-security. Need to figure out what to do with the "backing storage image format" section of that document. CC: Ian Jackson <ian.jackson@citrix.com> CC: Wei Liu <wei.liu2@citrix.com> CC: Andrew Cooper <andrew.cooper3@citrix.com> CC: Jan Beulich <jbeulich@suse.com> CC: Stefano Stabellini <sstabellini@kernel.org> CC: Konrad Wilk <konrad.wilk@oracle.com> CC: Tim Deegan <tim@xen.org> CC: Roger Pau Monne <roger.pau@citrix.com> CC: Anthony Perard <anthony.perard@citrix.com> CC: Paul Durrant <paul.durrant@citrix.com> --- SUPPORT.md | 106 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 106 insertions(+)