| Message ID | 20171113154126.13038-3-george.dunlap@citrix.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
>>> On 13.11.17 at 16:41, <george.dunlap@citrix.com> wrote: > +### Host ACPI (via Domain 0) > + > + Status, x86 PV: Supported > + Status, x86 PVH: Tech preview Are we this far already? Preview implies functional completeness, but I'm not sure about all ACPI related parts actually having been implemented (and see also below). But perhaps things like P and C state handling come as individual features later on. > +### x86/PVH guest > + > + Status: Supported > + > +PVH is a next-generation paravirtualized mode > +designed to take advantage of hardware virtualization support when possible. > +During development this was sometimes called HVMLite or PVHv2. > + > +Requires hardware virtualisation support (Intel VMX / AMD SVM) I think it needs to be said that only DomU is considered supported. Dom0 is perhaps not even experimental at this point, considering the panic() in dom0_construct_pvh(). Jan
On 11/21/2017 08:09 AM, Jan Beulich wrote: >>>> On 13.11.17 at 16:41, <george.dunlap@citrix.com> wrote: >> +### x86/PVH guest >> + >> + Status: Supported >> + >> +PVH is a next-generation paravirtualized mode >> +designed to take advantage of hardware virtualization support when possible. >> +During development this was sometimes called HVMLite or PVHv2. >> + >> +Requires hardware virtualisation support (Intel VMX / AMD SVM) > > I think it needs to be said that only DomU is considered supported. > Dom0 is perhaps not even experimental at this point, considering > the panic() in dom0_construct_pvh(). Indeed, that's why dom0 PVH isn't in the list, and why this says 'PVH guest', and is in the 'Guest Type' section. We generally don't say, "Oh, and we don't have this feature at all". If you think it's important we could add a sentence here explicitly stating that dom0 PVH isn't supported, but I sort of feel like it isn't necessary. >> +### Host ACPI (via Domain 0) >> + >> + Status, x86 PV: Supported >> + Status, x86 PVH: Tech preview > > Are we this far already? Preview implies functional completeness, > but I'm not sure about all ACPI related parts actually having been > implemented (and see also below). But perhaps things like P and C > state handling come as individual features later on. Hmm, yeah, it doesn't make much sense to say that we have "Tech preview" status for a feature with a PVH dom0, when PVH dom0 itself isn't even 'experimental' yet. I'll remove this (unless Roger or Wei want to object). -George
>>> On 21.11.17 at 11:42, <george.dunlap@citrix.com> wrote: > On 11/21/2017 08:09 AM, Jan Beulich wrote: >>>>> On 13.11.17 at 16:41, <george.dunlap@citrix.com> wrote: >>> +### x86/PVH guest >>> + >>> + Status: Supported >>> + >>> +PVH is a next-generation paravirtualized mode >>> +designed to take advantage of hardware virtualization support when possible. >>> +During development this was sometimes called HVMLite or PVHv2. >>> + >>> +Requires hardware virtualisation support (Intel VMX / AMD SVM) >> >> I think it needs to be said that only DomU is considered supported. >> Dom0 is perhaps not even experimental at this point, considering >> the panic() in dom0_construct_pvh(). > > Indeed, that's why dom0 PVH isn't in the list, and why this says 'PVH > guest', and is in the 'Guest Type' section. We generally don't say, > "Oh, and we don't have this feature at all". > > If you think it's important we could add a sentence here explicitly > stating that dom0 PVH isn't supported, but I sort of feel like it isn't > necessary. Much depends on whether you think "guest" == "DomU". To me Dom0 is a guest, too. Jan
On Nov 21, 2017, at 11:35 AM, Jan Beulich <JBeulich@suse.com<mailto:JBeulich@suse.com>> wrote: On 21.11.17 at 11:42, <george.dunlap@citrix.com<mailto:george.dunlap@citrix.com>> wrote: On 11/21/2017 08:09 AM, Jan Beulich wrote: On 13.11.17 at 16:41, <george.dunlap@citrix.com<mailto:george.dunlap@citrix.com>> wrote: +### x86/PVH guest + + Status: Supported + +PVH is a next-generation paravirtualized mode +designed to take advantage of hardware virtualization support when possible. +During development this was sometimes called HVMLite or PVHv2. + +Requires hardware virtualisation support (Intel VMX / AMD SVM) I think it needs to be said that only DomU is considered supported. Dom0 is perhaps not even experimental at this point, considering the panic() in dom0_construct_pvh(). Indeed, that's why dom0 PVH isn't in the list, and why this says 'PVH guest', and is in the 'Guest Type' section. We generally don't say, "Oh, and we don't have this feature at all". If you think it's important we could add a sentence here explicitly stating that dom0 PVH isn't supported, but I sort of feel like it isn't necessary. Much depends on whether you think "guest" == "DomU". To me Dom0 is a guest, too. That’s not how I’ve ever understood those terms. A guest at a hotel is someone who is served, and who does not have (legal) access to the internals of the system. The maids who clean the room and the janitors who sweep the floors are hosts, because they have (to various degrees) extra access designed to help them serve the guests. A “guest” is a virtual machine that does not have access to the internals of the system; that is the “target” of virtualization. As such, the dom0 kernel and all the toolstack / emulation code running in domain 0 are part of the “host”. Domain 0 is a domain and a VM, but only domUs are guests. Any other opinions on this? Do we need to add these to the terms defined at the bottom? -George
Jan Beulich writes ("Re: [PATCH 03/16] SUPPORT.md: Add some x86 features"):
> Much depends on whether you think "guest" == "DomU". To me
> Dom0 is a guest, too.
Not to me. I'm with George. (As far as I can make out his message,
which I think was sent with HTML-style quoting which some Citrix thing
has stripped out, so I can't see who said what.)
But I don't think this is important and I would like to see this
document go in.
Ian.
>>> On 21.11.17 at 13:24, <George.Dunlap@citrix.com> wrote: >> On Nov 21, 2017, at 11:35 AM, Jan Beulich >> Much depends on whether you think "guest" == "DomU". To me >> Dom0 is a guest, too. > > That’s not how I’ve ever understood those terms. > > A guest at a hotel is someone who is served, and who does not have (legal) > access to the internals of the system. The maids who clean the room and the > janitors who sweep the floors are hosts, because they have (to various > degrees) extra access designed to help them serve the guests. > > A “guest” is a virtual machine that does not have access to the internals of > the system; that is the “target” of virtualization. As such, the dom0 kernel > and all the toolstack / emulation code running in domain 0 are part of the > “host”. > > Domain 0 is a domain and a VM, but only domUs are guests. Okay then; just FTR I've always been considering "domain" == "guest" == "VM". Jan
diff --git a/SUPPORT.md b/SUPPORT.md index 064a2f43e9..6b09f98331 100644 --- a/SUPPORT.md +++ b/SUPPORT.md @@ -16,6 +16,59 @@ for the definitions of the support status levels etc. # Feature Support +## Host Architecture + +### x86-64 + + Status: Supported + +## Host hardware support + +### Physical CPU Hotplug + + Status, x86: Supported + +### Physical Memory Hotplug + + Status, x86: Supported + +### Host ACPI (via Domain 0) + + Status, x86 PV: Supported + Status, x86 PVH: Tech preview + +### x86/Intel Platform QoS Technologies + + Status: Tech Preview + +## Guest Type + +### x86/PV + + Status: Supported + +Traditional Xen PV guest + +No hardware requirements + +### x86/HVM + + Status: Supported + +Fully virtualised guest using hardware virtualisation extensions + +Requires hardware virtualisation support (Intel VMX / AMD SVM) + +### x86/PVH guest + + Status: Supported + +PVH is a next-generation paravirtualized mode +designed to take advantage of hardware virtualization support when possible. +During development this was sometimes called HVMLite or PVHv2. + +Requires hardware virtualisation support (Intel VMX / AMD SVM) + ## Memory Management ### Memory Ballooning
Including host architecture support and guest types. Signed-off-by: George Dunlap <george.dunlap@citrix.com> --- 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> --- SUPPORT.md | 53 +++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 53 insertions(+)