Re: [Xen-devel] [PATCH 03/16] SUPPORT.md: Add some x86 features

2017-11-21 Thread Jan Beulich
>>> On 21.11.17 at 13:24,  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

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


Re: [Xen-devel] [PATCH 03/16] SUPPORT.md: Add some x86 features

2017-11-21 Thread Ian Jackson
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.

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


Re: [Xen-devel] [PATCH 03/16] SUPPORT.md: Add some x86 features

2017-11-21 Thread George Dunlap


On Nov 21, 2017, at 11:35 AM, Jan Beulich 
> wrote:

On 21.11.17 at 11:42, 
> wrote:
On 11/21/2017 08:09 AM, Jan Beulich wrote:
On 13.11.17 at 16:41, 
> 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
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel


Re: [Xen-devel] [PATCH 03/16] SUPPORT.md: Add some x86 features

2017-11-21 Thread Jan Beulich
>>> On 21.11.17 at 11:42,  wrote:
> On 11/21/2017 08:09 AM, Jan Beulich wrote:
> On 13.11.17 at 16:41,  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


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


Re: [Xen-devel] [PATCH 03/16] SUPPORT.md: Add some x86 features

2017-11-21 Thread George Dunlap
On 11/21/2017 08:09 AM, Jan Beulich wrote:
 On 13.11.17 at 16:41,  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


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


Re: [Xen-devel] [PATCH 03/16] SUPPORT.md: Add some x86 features

2017-11-21 Thread Jan Beulich
>>> On 13.11.17 at 16:41,  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


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


[Xen-devel] [PATCH 03/16] SUPPORT.md: Add some x86 features

2017-11-13 Thread George Dunlap
Including host architecture support and guest types.

Signed-off-by: George Dunlap 
---
CC: Ian Jackson 
CC: Wei Liu 
CC: Andrew Cooper 
CC: Jan Beulich 
CC: Stefano Stabellini 
CC: Konrad Wilk 
CC: Tim Deegan 
CC: Roger Pau Monne 
---
 SUPPORT.md | 53 +
 1 file changed, 53 insertions(+)

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
-- 
2.15.0


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