ARM: KVM/XEN: how should we support virt-what?

ARM: KVM/XEN: how should we support virt-what?

[Andrew Jones]

Hello ARM virt maintainers,

I'd like to start a discussion about supporting virt-what[1]. virt-what
allows userspace to determine if the system it's running on is running
in a guest, and of what type (KVM, Xen, etc.). Despite it being a best
effort tool, see the Caveat emptor in [1], it has become quite a useful
tool, and is showing up in different places, such as OpenStack. If you
look at the code[2], specifically [3], then you'll see how it works on
x86, which is to use the dedicated hypervisor cpuid leaves. I'm
wondering what equivalent we have, or can develop, for arm.
Here are some thoughts;
0) there's already something we can use, and I just need to be told
   about it.
1) be as similar as possible to x86 by dedicating some currently
   undefined sysreg bits. This would take buy-in from lots of parties,
   so is not likely the way to go.
2) create a specific DT node that will get exposed through sysfs, or
   somewhere.
3) same as (2), but just use the nodes currently in mach-virt's DT
   as the indication we're a guest. This would just be a heuristic,
   i.e. "have virtio mmio" && psci.method == hvc, or something,
   and we'd still need a way to know if we're kvm vs. xen vs. ??.

Thanks,
drew 

[1] http://people.redhat.com/~rjones/virt-what/
[2] http://git.annexia.org/?p=virt-what.git;a=summary
[3] http://git.annexia.org/?p=virt-what.git;a=blob_plain;f=virt-what-cpuid-helper.c;hb=HEAD

ARM: KVM/XEN: how should we support virt-what?

[Andrew Jones]

Hello ARM virt maintainers,

I'd like to start a discussion about supporting virt-what[1]. virt-what
allows userspace to determine if the system it's running on is running
in a guest, and of what type (KVM, Xen, etc.). Despite it being a best
effort tool, see the Caveat emptor in [1], it has become quite a useful
tool, and is showing up in different places, such as OpenStack. If you
look at the code[2], specifically [3], then you'll see how it works on
x86, which is to use the dedicated hypervisor cpuid leaves. I'm
wondering what equivalent we have, or can develop, for arm.
Here are some thoughts;
0) there's already something we can use, and I just need to be told
   about it.
1) be as similar as possible to x86 by dedicating some currently
   undefined sysreg bits. This would take buy-in from lots of parties,
   so is not likely the way to go.
2) create a specific DT node that will get exposed through sysfs, or
   somewhere.
3) same as (2), but just use the nodes currently in mach-virt's DT
   as the indication we're a guest. This would just be a heuristic,
   i.e. "have virtio mmio" && psci.method == hvc, or something,
   and we'd still need a way to know if we're kvm vs. xen vs. ??.

Thanks,
drew 

[1] http://people.redhat.com/~rjones/virt-what/
[2] http://git.annexia.org/?p=virt-what.git;a=summary
[3] http://git.annexia.org/?p=virt-what.git;a=blob_plain;f=virt-what-cpuid-helper.c;hb=HEAD

Re: ARM: KVM/XEN: how should we support virt-what?

[Paolo Bonzini]

On 25/03/2015 10:44, Andrew Jones wrote:
> 2) create a specific DT node that will get exposed through sysfs, or
>    somewhere.

Looking at custom DT nodes is what PowerPC does.

Paolo

Re: ARM: KVM/XEN: how should we support virt-what?

[Paolo Bonzini]

On 25/03/2015 10:44, Andrew Jones wrote:
> 2) create a specific DT node that will get exposed through sysfs, or
>    somewhere.

Looking at custom DT nodes is what PowerPC does.

Paolo

ARM: KVM/XEN: how should we support virt-what?

[Paolo Bonzini]

On 25/03/2015 10:44, Andrew Jones wrote:
> 2) create a specific DT node that will get exposed through sysfs, or
>    somewhere.

Looking at custom DT nodes is what PowerPC does.

Paolo

Re: [Xen-devel] ARM: KVM/XEN: how should we support virt-what?

[Ian Campbell]

On Wed, 2015-03-25 at 10:44 +0100, Andrew Jones wrote:
> Hello ARM virt maintainers,
> 
> I'd like to start a discussion about supporting virt-what[1]. virt-what
> allows userspace to determine if the system it's running on is running
> in a guest, and of what type (KVM, Xen, etc.). Despite it being a best
> effort tool, see the Caveat emptor in [1], it has become quite a useful
> tool, and is showing up in different places, such as OpenStack. If you
> look at the code[2], specifically [3], then you'll see how it works on
> x86, which is to use the dedicated hypervisor cpuid leaves. I'm
> wondering what equivalent we have, or can develop, for arm.
> Here are some thoughts;
> 0) there's already something we can use, and I just need to be told
>    about it.
> 1) be as similar as possible to x86 by dedicating some currently
>    undefined sysreg bits. This would take buy-in from lots of parties,
>    so is not likely the way to go.
> 2) create a specific DT node that will get exposed through sysfs, or
>    somewhere.
> 3) same as (2), but just use the nodes currently in mach-virt's DT
>    as the indication we're a guest. This would just be a heuristic,
>    i.e. "have virtio mmio" && psci.method == hvc, or something,
>    and we'd still need a way to know if we're kvm vs. xen vs. ??.

FWIW Xen has a specific node,
https://git.kernel.org/cgit/linux/kernel/git/devicetree/devicetree-rebasing.git/tree/Bindings/arm/xen.txt

Doesn't help you with ACPI systems though. IIRC there will be a Xen
table of some sort.

Ian.

[Xen-devel] ARM: KVM/XEN: how should we support virt-what?

[Ian Campbell]

On Wed, 2015-03-25 at 10:44 +0100, Andrew Jones wrote:
> Hello ARM virt maintainers,
> 
> I'd like to start a discussion about supporting virt-what[1]. virt-what
> allows userspace to determine if the system it's running on is running
> in a guest, and of what type (KVM, Xen, etc.). Despite it being a best
> effort tool, see the Caveat emptor in [1], it has become quite a useful
> tool, and is showing up in different places, such as OpenStack. If you
> look at the code[2], specifically [3], then you'll see how it works on
> x86, which is to use the dedicated hypervisor cpuid leaves. I'm
> wondering what equivalent we have, or can develop, for arm.
> Here are some thoughts;
> 0) there's already something we can use, and I just need to be told
>    about it.
> 1) be as similar as possible to x86 by dedicating some currently
>    undefined sysreg bits. This would take buy-in from lots of parties,
>    so is not likely the way to go.
> 2) create a specific DT node that will get exposed through sysfs, or
>    somewhere.
> 3) same as (2), but just use the nodes currently in mach-virt's DT
>    as the indication we're a guest. This would just be a heuristic,
>    i.e. "have virtio mmio" && psci.method == hvc, or something,
>    and we'd still need a way to know if we're kvm vs. xen vs. ??.

FWIW Xen has a specific node,
https://git.kernel.org/cgit/linux/kernel/git/devicetree/devicetree-rebasing.git/tree/Bindings/arm/xen.txt

Doesn't help you with ACPI systems though. IIRC there will be a Xen
table of some sort.

Ian.

Re: [Xen-devel] ARM: KVM/XEN: how should we support virt-what?

[Ian Campbell]

On Wed, 2015-03-25 at 10:44 +0100, Andrew Jones wrote:
> Hello ARM virt maintainers,
> 
> I'd like to start a discussion about supporting virt-what[1]. virt-what
> allows userspace to determine if the system it's running on is running
> in a guest, and of what type (KVM, Xen, etc.). Despite it being a best
> effort tool, see the Caveat emptor in [1], it has become quite a useful
> tool, and is showing up in different places, such as OpenStack. If you
> look at the code[2], specifically [3], then you'll see how it works on
> x86, which is to use the dedicated hypervisor cpuid leaves. I'm
> wondering what equivalent we have, or can develop, for arm.
> Here are some thoughts;
> 0) there's already something we can use, and I just need to be told
>    about it.
> 1) be as similar as possible to x86 by dedicating some currently
>    undefined sysreg bits. This would take buy-in from lots of parties,
>    so is not likely the way to go.
> 2) create a specific DT node that will get exposed through sysfs, or
>    somewhere.
> 3) same as (2), but just use the nodes currently in mach-virt's DT
>    as the indication we're a guest. This would just be a heuristic,
>    i.e. "have virtio mmio" && psci.method == hvc, or something,
>    and we'd still need a way to know if we're kvm vs. xen vs. ??.

FWIW Xen has a specific node,
https://git.kernel.org/cgit/linux/kernel/git/devicetree/devicetree-rebasing.git/tree/Bindings/arm/xen.txt

Doesn't help you with ACPI systems though. IIRC there will be a Xen
table of some sort.

Ian.

Re: ARM: KVM/XEN: how should we support virt-what?

[Stefano Stabellini]

On Wed, 25 Mar 2015, Ian Campbell wrote:
> On Wed, 2015-03-25 at 10:44 +0100, Andrew Jones wrote:
> > Hello ARM virt maintainers,
> > 
> > I'd like to start a discussion about supporting virt-what[1]. virt-what
> > allows userspace to determine if the system it's running on is running
> > in a guest, and of what type (KVM, Xen, etc.). Despite it being a best
> > effort tool, see the Caveat emptor in [1], it has become quite a useful
> > tool, and is showing up in different places, such as OpenStack. If you
> > look at the code[2], specifically [3], then you'll see how it works on
> > x86, which is to use the dedicated hypervisor cpuid leaves. I'm
> > wondering what equivalent we have, or can develop, for arm.
> > Here are some thoughts;
> > 0) there's already something we can use, and I just need to be told
> >    about it.
> > 1) be as similar as possible to x86 by dedicating some currently
> >    undefined sysreg bits. This would take buy-in from lots of parties,
> >    so is not likely the way to go.
> > 2) create a specific DT node that will get exposed through sysfs, or
> >    somewhere.
> > 3) same as (2), but just use the nodes currently in mach-virt's DT
> >    as the indication we're a guest. This would just be a heuristic,
> >    i.e. "have virtio mmio" && psci.method == hvc, or something,
> >    and we'd still need a way to know if we're kvm vs. xen vs. ??.
> 
> FWIW Xen has a specific node,
> https://git.kernel.org/cgit/linux/kernel/git/devicetree/devicetree-rebasing.git/tree/Bindings/arm/xen.txt
> 
> Doesn't help you with ACPI systems though. IIRC there will be a Xen
> table of some sort.

This is the Xen specific ACPI table:

http://wiki.xenproject.org/mediawiki/images/c/c4/Xen-environment-table.pdf

Re: [Xen-devel] ARM: KVM/XEN: how should we support virt-what?

[Stefano Stabellini]

On Wed, 25 Mar 2015, Ian Campbell wrote:
> On Wed, 2015-03-25 at 10:44 +0100, Andrew Jones wrote:
> > Hello ARM virt maintainers,
> > 
> > I'd like to start a discussion about supporting virt-what[1]. virt-what
> > allows userspace to determine if the system it's running on is running
> > in a guest, and of what type (KVM, Xen, etc.). Despite it being a best
> > effort tool, see the Caveat emptor in [1], it has become quite a useful
> > tool, and is showing up in different places, such as OpenStack. If you
> > look at the code[2], specifically [3], then you'll see how it works on
> > x86, which is to use the dedicated hypervisor cpuid leaves. I'm
> > wondering what equivalent we have, or can develop, for arm.
> > Here are some thoughts;
> > 0) there's already something we can use, and I just need to be told
> >    about it.
> > 1) be as similar as possible to x86 by dedicating some currently
> >    undefined sysreg bits. This would take buy-in from lots of parties,
> >    so is not likely the way to go.
> > 2) create a specific DT node that will get exposed through sysfs, or
> >    somewhere.
> > 3) same as (2), but just use the nodes currently in mach-virt's DT
> >    as the indication we're a guest. This would just be a heuristic,
> >    i.e. "have virtio mmio" && psci.method == hvc, or something,
> >    and we'd still need a way to know if we're kvm vs. xen vs. ??.
> 
> FWIW Xen has a specific node,
> https://git.kernel.org/cgit/linux/kernel/git/devicetree/devicetree-rebasing.git/tree/Bindings/arm/xen.txt
> 
> Doesn't help you with ACPI systems though. IIRC there will be a Xen
> table of some sort.

This is the Xen specific ACPI table:

http://wiki.xenproject.org/mediawiki/images/c/c4/Xen-environment-table.pdf

[Xen-devel] ARM: KVM/XEN: how should we support virt-what?

[Stefano Stabellini]

On Wed, 25 Mar 2015, Ian Campbell wrote:
> On Wed, 2015-03-25 at 10:44 +0100, Andrew Jones wrote:
> > Hello ARM virt maintainers,
> > 
> > I'd like to start a discussion about supporting virt-what[1]. virt-what
> > allows userspace to determine if the system it's running on is running
> > in a guest, and of what type (KVM, Xen, etc.). Despite it being a best
> > effort tool, see the Caveat emptor in [1], it has become quite a useful
> > tool, and is showing up in different places, such as OpenStack. If you
> > look at the code[2], specifically [3], then you'll see how it works on
> > x86, which is to use the dedicated hypervisor cpuid leaves. I'm
> > wondering what equivalent we have, or can develop, for arm.
> > Here are some thoughts;
> > 0) there's already something we can use, and I just need to be told
> >    about it.
> > 1) be as similar as possible to x86 by dedicating some currently
> >    undefined sysreg bits. This would take buy-in from lots of parties,
> >    so is not likely the way to go.
> > 2) create a specific DT node that will get exposed through sysfs, or
> >    somewhere.
> > 3) same as (2), but just use the nodes currently in mach-virt's DT
> >    as the indication we're a guest. This would just be a heuristic,
> >    i.e. "have virtio mmio" && psci.method == hvc, or something,
> >    and we'd still need a way to know if we're kvm vs. xen vs. ??.
> 
> FWIW Xen has a specific node,
> https://git.kernel.org/cgit/linux/kernel/git/devicetree/devicetree-rebasing.git/tree/Bindings/arm/xen.txt
> 
> Doesn't help you with ACPI systems though. IIRC there will be a Xen
> table of some sort.

This is the Xen specific ACPI table:

http://wiki.xenproject.org/mediawiki/images/c/c4/Xen-environment-table.pdf

Re: [Xen-devel] ARM: KVM/XEN: how should we support virt-what?

[Stefano Stabellini]

On Wed, 25 Mar 2015, Ian Campbell wrote:
> On Wed, 2015-03-25 at 10:44 +0100, Andrew Jones wrote:
> > Hello ARM virt maintainers,
> > 
> > I'd like to start a discussion about supporting virt-what[1]. virt-what
> > allows userspace to determine if the system it's running on is running
> > in a guest, and of what type (KVM, Xen, etc.). Despite it being a best
> > effort tool, see the Caveat emptor in [1], it has become quite a useful
> > tool, and is showing up in different places, such as OpenStack. If you
> > look at the code[2], specifically [3], then you'll see how it works on
> > x86, which is to use the dedicated hypervisor cpuid leaves. I'm
> > wondering what equivalent we have, or can develop, for arm.
> > Here are some thoughts;
> > 0) there's already something we can use, and I just need to be told
> >    about it.
> > 1) be as similar as possible to x86 by dedicating some currently
> >    undefined sysreg bits. This would take buy-in from lots of parties,
> >    so is not likely the way to go.
> > 2) create a specific DT node that will get exposed through sysfs, or
> >    somewhere.
> > 3) same as (2), but just use the nodes currently in mach-virt's DT
> >    as the indication we're a guest. This would just be a heuristic,
> >    i.e. "have virtio mmio" && psci.method == hvc, or something,
> >    and we'd still need a way to know if we're kvm vs. xen vs. ??.
> 
> FWIW Xen has a specific node,
> https://git.kernel.org/cgit/linux/kernel/git/devicetree/devicetree-rebasing.git/tree/Bindings/arm/xen.txt
> 
> Doesn't help you with ACPI systems though. IIRC there will be a Xen
> table of some sort.

This is the Xen specific ACPI table:

http://wiki.xenproject.org/mediawiki/images/c/c4/Xen-environment-table.pdf

Re: ARM: KVM/XEN: how should we support virt-what?

[Ian Campbell]

On Wed, 2015-03-25 at 10:44 +0100, Andrew Jones wrote:
> Hello ARM virt maintainers,
> 
> I'd like to start a discussion about supporting virt-what[1]. virt-what
> allows userspace to determine if the system it's running on is running
> in a guest, and of what type (KVM, Xen, etc.). Despite it being a best
> effort tool, see the Caveat emptor in [1], it has become quite a useful
> tool, and is showing up in different places, such as OpenStack. If you
> look at the code[2], specifically [3], then you'll see how it works on
> x86, which is to use the dedicated hypervisor cpuid leaves. I'm
> wondering what equivalent we have, or can develop, for arm.
> Here are some thoughts;
> 0) there's already something we can use, and I just need to be told
>    about it.
> 1) be as similar as possible to x86 by dedicating some currently
>    undefined sysreg bits. This would take buy-in from lots of parties,
>    so is not likely the way to go.
> 2) create a specific DT node that will get exposed through sysfs, or
>    somewhere.
> 3) same as (2), but just use the nodes currently in mach-virt's DT
>    as the indication we're a guest. This would just be a heuristic,
>    i.e. "have virtio mmio" && psci.method == hvc, or something,
>    and we'd still need a way to know if we're kvm vs. xen vs. ??.

FWIW Xen has a specific node,
https://git.kernel.org/cgit/linux/kernel/git/devicetree/devicetree-rebasing.git/tree/Bindings/arm/xen.txt

Doesn't help you with ACPI systems though. IIRC there will be a Xen
table of some sort.

Ian.

Re: ARM: KVM/XEN: how should we support virt-what?

[Marc Zyngier]

On 25/03/15 09:44, Andrew Jones wrote:
> Hello ARM virt maintainers,
> 
> I'd like to start a discussion about supporting virt-what[1]. virt-what
> allows userspace to determine if the system it's running on is running
> in a guest, and of what type (KVM, Xen, etc.). Despite it being a best
> effort tool, see the Caveat emptor in [1], it has become quite a useful
> tool, and is showing up in different places, such as OpenStack. If you
> look at the code[2], specifically [3], then you'll see how it works on
> x86, which is to use the dedicated hypervisor cpuid leaves. I'm
> wondering what equivalent we have, or can develop, for arm.
> Here are some thoughts;
> 0) there's already something we can use, and I just need to be told
>    about it.
> 1) be as similar as possible to x86 by dedicating some currently
>    undefined sysreg bits. This would take buy-in from lots of parties,
>    so is not likely the way to go.
> 2) create a specific DT node that will get exposed through sysfs, or
>    somewhere.
> 3) same as (2), but just use the nodes currently in mach-virt's DT
>    as the indication we're a guest. This would just be a heuristic,
>    i.e. "have virtio mmio" && psci.method == hvc, or something,
>    and we'd still need a way to know if we're kvm vs. xen vs. ??.

KVM doesn't have any specific DT node so far (at least kvmtool doesn't
expose anything, and QEMU doesn't seem to do it either).

You could define KVM as being !Xen by looking for the Xen hypervisor
node, but that's quite a heuristic.

Overall, I'm quite reluctant to introduce things that would immediately
become an ABI (cue the recent bogomips flame wars), forming a contract
between the host userspace and the guest userspace.

	M.
-- 
Jazz is not dead. It just smells funny...

Re: ARM: KVM/XEN: how should we support virt-what?

[Marc Zyngier]

On 25/03/15 09:44, Andrew Jones wrote:
> Hello ARM virt maintainers,
> 
> I'd like to start a discussion about supporting virt-what[1]. virt-what
> allows userspace to determine if the system it's running on is running
> in a guest, and of what type (KVM, Xen, etc.). Despite it being a best
> effort tool, see the Caveat emptor in [1], it has become quite a useful
> tool, and is showing up in different places, such as OpenStack. If you
> look at the code[2], specifically [3], then you'll see how it works on
> x86, which is to use the dedicated hypervisor cpuid leaves. I'm
> wondering what equivalent we have, or can develop, for arm.
> Here are some thoughts;
> 0) there's already something we can use, and I just need to be told
>    about it.
> 1) be as similar as possible to x86 by dedicating some currently
>    undefined sysreg bits. This would take buy-in from lots of parties,
>    so is not likely the way to go.
> 2) create a specific DT node that will get exposed through sysfs, or
>    somewhere.
> 3) same as (2), but just use the nodes currently in mach-virt's DT
>    as the indication we're a guest. This would just be a heuristic,
>    i.e. "have virtio mmio" && psci.method == hvc, or something,
>    and we'd still need a way to know if we're kvm vs. xen vs. ??.

KVM doesn't have any specific DT node so far (at least kvmtool doesn't
expose anything, and QEMU doesn't seem to do it either).

You could define KVM as being !Xen by looking for the Xen hypervisor
node, but that's quite a heuristic.

Overall, I'm quite reluctant to introduce things that would immediately
become an ABI (cue the recent bogomips flame wars), forming a contract
between the host userspace and the guest userspace.

	M.
-- 
Jazz is not dead. It just smells funny...

ARM: KVM/XEN: how should we support virt-what?

[Marc Zyngier]

On 25/03/15 09:44, Andrew Jones wrote:
> Hello ARM virt maintainers,
> 
> I'd like to start a discussion about supporting virt-what[1]. virt-what
> allows userspace to determine if the system it's running on is running
> in a guest, and of what type (KVM, Xen, etc.). Despite it being a best
> effort tool, see the Caveat emptor in [1], it has become quite a useful
> tool, and is showing up in different places, such as OpenStack. If you
> look at the code[2], specifically [3], then you'll see how it works on
> x86, which is to use the dedicated hypervisor cpuid leaves. I'm
> wondering what equivalent we have, or can develop, for arm.
> Here are some thoughts;
> 0) there's already something we can use, and I just need to be told
>    about it.
> 1) be as similar as possible to x86 by dedicating some currently
>    undefined sysreg bits. This would take buy-in from lots of parties,
>    so is not likely the way to go.
> 2) create a specific DT node that will get exposed through sysfs, or
>    somewhere.
> 3) same as (2), but just use the nodes currently in mach-virt's DT
>    as the indication we're a guest. This would just be a heuristic,
>    i.e. "have virtio mmio" && psci.method == hvc, or something,
>    and we'd still need a way to know if we're kvm vs. xen vs. ??.

KVM doesn't have any specific DT node so far (at least kvmtool doesn't
expose anything, and QEMU doesn't seem to do it either).

You could define KVM as being !Xen by looking for the Xen hypervisor
node, but that's quite a heuristic.

Overall, I'm quite reluctant to introduce things that would immediately
become an ABI (cue the recent bogomips flame wars), forming a contract
between the host userspace and the guest userspace.

	M.
-- 
Jazz is not dead. It just smells funny...

Re: ARM: KVM/XEN: how should we support virt-what?

[Andrew Jones]

On Wed, Mar 25, 2015 at 10:44:42AM +0100, Andrew Jones wrote:
> Hello ARM virt maintainers,
> 
> I'd like to start a discussion about supporting virt-what[1]. virt-what
> allows userspace to determine if the system it's running on is running
> in a guest, and of what type (KVM, Xen, etc.). Despite it being a best
> effort tool, see the Caveat emptor in [1], it has become quite a useful
> tool, and is showing up in different places, such as OpenStack. If you
> look at the code[2], specifically [3], then you'll see how it works on
> x86, which is to use the dedicated hypervisor cpuid leaves. I'm
> wondering what equivalent we have, or can develop, for arm.
> Here are some thoughts;
> 0) there's already something we can use, and I just need to be told
>    about it.
> 1) be as similar as possible to x86 by dedicating some currently
>    undefined sysreg bits. This would take buy-in from lots of parties,
>    so is not likely the way to go.
> 2) create a specific DT node that will get exposed through sysfs, or
>    somewhere.
> 3) same as (2), but just use the nodes currently in mach-virt's DT
>    as the indication we're a guest. This would just be a heuristic,
>    i.e. "have virtio mmio" && psci.method == hvc, or something,
>    and we'd still need a way to know if we're kvm vs. xen vs. ??.
> 
> Thanks,
> drew 
> 
> [1] http://people.redhat.com/~rjones/virt-what/
> [2] http://git.annexia.org/?p=virt-what.git;a=summary
> [3] http://git.annexia.org/?p=virt-what.git;a=blob_plain;f=virt-what-cpuid-helper.c;hb=HEAD

Thanks everyone for their responses. So, the current summary seems to
be;
1) Xen has both a DT node and an ACPI table, virt-what can learn how
   to probe those.
2) We don't have anything yet for KVM, and we're reluctant to create a
   specific DT node. Anyway, we'd still need to address ACPI booted
   guests some other way.

For a short-term, DT-only, approach we could go with a heuristic, one
that includes Marc's "if hypervisor node exists, then xen, else kvm"
condition.

How about SMBIOS for a long-term solution that works for both DT and
ACPI? We're not populating SMBIOS for arm guests yet in qemu, but now
that AAVMF has fw_cfg, we should be able to. On x86 we already have
smbios populated from qemu, although not in a way that allows us to
determine kvm vs. xen vs. tcg.

Any other suggestions?

drew

Re: ARM: KVM/XEN: how should we support virt-what?

[Andrew Jones]

On Wed, Mar 25, 2015 at 10:44:42AM +0100, Andrew Jones wrote:
> Hello ARM virt maintainers,
> 
> I'd like to start a discussion about supporting virt-what[1]. virt-what
> allows userspace to determine if the system it's running on is running
> in a guest, and of what type (KVM, Xen, etc.). Despite it being a best
> effort tool, see the Caveat emptor in [1], it has become quite a useful
> tool, and is showing up in different places, such as OpenStack. If you
> look at the code[2], specifically [3], then you'll see how it works on
> x86, which is to use the dedicated hypervisor cpuid leaves. I'm
> wondering what equivalent we have, or can develop, for arm.
> Here are some thoughts;
> 0) there's already something we can use, and I just need to be told
>    about it.
> 1) be as similar as possible to x86 by dedicating some currently
>    undefined sysreg bits. This would take buy-in from lots of parties,
>    so is not likely the way to go.
> 2) create a specific DT node that will get exposed through sysfs, or
>    somewhere.
> 3) same as (2), but just use the nodes currently in mach-virt's DT
>    as the indication we're a guest. This would just be a heuristic,
>    i.e. "have virtio mmio" && psci.method == hvc, or something,
>    and we'd still need a way to know if we're kvm vs. xen vs. ??.
> 
> Thanks,
> drew 
> 
> [1] http://people.redhat.com/~rjones/virt-what/
> [2] http://git.annexia.org/?p=virt-what.git;a=summary
> [3] http://git.annexia.org/?p=virt-what.git;a=blob_plain;f=virt-what-cpuid-helper.c;hb=HEAD

Thanks everyone for their responses. So, the current summary seems to
be;
1) Xen has both a DT node and an ACPI table, virt-what can learn how
   to probe those.
2) We don't have anything yet for KVM, and we're reluctant to create a
   specific DT node. Anyway, we'd still need to address ACPI booted
   guests some other way.

For a short-term, DT-only, approach we could go with a heuristic, one
that includes Marc's "if hypervisor node exists, then xen, else kvm"
condition.

How about SMBIOS for a long-term solution that works for both DT and
ACPI? We're not populating SMBIOS for arm guests yet in qemu, but now
that AAVMF has fw_cfg, we should be able to. On x86 we already have
smbios populated from qemu, although not in a way that allows us to
determine kvm vs. xen vs. tcg.

Any other suggestions?

drew

ARM: KVM/XEN: how should we support virt-what?

[Andrew Jones]

On Wed, Mar 25, 2015 at 10:44:42AM +0100, Andrew Jones wrote:
> Hello ARM virt maintainers,
> 
> I'd like to start a discussion about supporting virt-what[1]. virt-what
> allows userspace to determine if the system it's running on is running
> in a guest, and of what type (KVM, Xen, etc.). Despite it being a best
> effort tool, see the Caveat emptor in [1], it has become quite a useful
> tool, and is showing up in different places, such as OpenStack. If you
> look at the code[2], specifically [3], then you'll see how it works on
> x86, which is to use the dedicated hypervisor cpuid leaves. I'm
> wondering what equivalent we have, or can develop, for arm.
> Here are some thoughts;
> 0) there's already something we can use, and I just need to be told
>    about it.
> 1) be as similar as possible to x86 by dedicating some currently
>    undefined sysreg bits. This would take buy-in from lots of parties,
>    so is not likely the way to go.
> 2) create a specific DT node that will get exposed through sysfs, or
>    somewhere.
> 3) same as (2), but just use the nodes currently in mach-virt's DT
>    as the indication we're a guest. This would just be a heuristic,
>    i.e. "have virtio mmio" && psci.method == hvc, or something,
>    and we'd still need a way to know if we're kvm vs. xen vs. ??.
> 
> Thanks,
> drew 
> 
> [1] http://people.redhat.com/~rjones/virt-what/
> [2] http://git.annexia.org/?p=virt-what.git;a=summary
> [3] http://git.annexia.org/?p=virt-what.git;a=blob_plain;f=virt-what-cpuid-helper.c;hb=HEAD

Thanks everyone for their responses. So, the current summary seems to
be;
1) Xen has both a DT node and an ACPI table, virt-what can learn how
   to probe those.
2) We don't have anything yet for KVM, and we're reluctant to create a
   specific DT node. Anyway, we'd still need to address ACPI booted
   guests some other way.

For a short-term, DT-only, approach we could go with a heuristic, one
that includes Marc's "if hypervisor node exists, then xen, else kvm"
condition.

How about SMBIOS for a long-term solution that works for both DT and
ACPI? We're not populating SMBIOS for arm guests yet in qemu, but now
that AAVMF has fw_cfg, we should be able to. On x86 we already have
smbios populated from qemu, although not in a way that allows us to
determine kvm vs. xen vs. tcg.

Any other suggestions?

drew

Re: ARM: KVM/XEN: how should we support virt-what?

[Stefano Stabellini]

On Thu, 26 Mar 2015, Andrew Jones wrote:
> On Wed, Mar 25, 2015 at 10:44:42AM +0100, Andrew Jones wrote:
> > Hello ARM virt maintainers,
> > 
> > I'd like to start a discussion about supporting virt-what[1]. virt-what
> > allows userspace to determine if the system it's running on is running
> > in a guest, and of what type (KVM, Xen, etc.). Despite it being a best
> > effort tool, see the Caveat emptor in [1], it has become quite a useful
> > tool, and is showing up in different places, such as OpenStack. If you
> > look at the code[2], specifically [3], then you'll see how it works on
> > x86, which is to use the dedicated hypervisor cpuid leaves. I'm
> > wondering what equivalent we have, or can develop, for arm.
> > Here are some thoughts;
> > 0) there's already something we can use, and I just need to be told
> >    about it.
> > 1) be as similar as possible to x86 by dedicating some currently
> >    undefined sysreg bits. This would take buy-in from lots of parties,
> >    so is not likely the way to go.
> > 2) create a specific DT node that will get exposed through sysfs, or
> >    somewhere.
> > 3) same as (2), but just use the nodes currently in mach-virt's DT
> >    as the indication we're a guest. This would just be a heuristic,
> >    i.e. "have virtio mmio" && psci.method == hvc, or something,
> >    and we'd still need a way to know if we're kvm vs. xen vs. ??.
> > 
> > Thanks,
> > drew 
> > 
> > [1] http://people.redhat.com/~rjones/virt-what/
> > [2] http://git.annexia.org/?p=virt-what.git;a=summary
> > [3] http://git.annexia.org/?p=virt-what.git;a=blob_plain;f=virt-what-cpuid-helper.c;hb=HEAD
> 
> Thanks everyone for their responses. So, the current summary seems to
> be;
> 1) Xen has both a DT node and an ACPI table, virt-what can learn how
>    to probe those.
> 2) We don't have anything yet for KVM, and we're reluctant to create a
>    specific DT node. Anyway, we'd still need to address ACPI booted
>    guests some other way.
> 
> For a short-term, DT-only, approach we could go with a heuristic, one
> that includes Marc's "if hypervisor node exists, then xen, else kvm"
> condition.
> 
> How about SMBIOS for a long-term solution that works for both DT and
> ACPI? We're not populating SMBIOS for arm guests yet in qemu, but now
> that AAVMF has fw_cfg, we should be able to. On x86 we already have
> smbios populated from qemu, although not in a way that allows us to
> determine kvm vs. xen vs. tcg.

I don't think that SMBIOS works with DT.


> Any other suggestions?
> 
> drew
> 

Re: ARM: KVM/XEN: how should we support virt-what?

[Stefano Stabellini]

On Thu, 26 Mar 2015, Andrew Jones wrote:
> On Wed, Mar 25, 2015 at 10:44:42AM +0100, Andrew Jones wrote:
> > Hello ARM virt maintainers,
> > 
> > I'd like to start a discussion about supporting virt-what[1]. virt-what
> > allows userspace to determine if the system it's running on is running
> > in a guest, and of what type (KVM, Xen, etc.). Despite it being a best
> > effort tool, see the Caveat emptor in [1], it has become quite a useful
> > tool, and is showing up in different places, such as OpenStack. If you
> > look at the code[2], specifically [3], then you'll see how it works on
> > x86, which is to use the dedicated hypervisor cpuid leaves. I'm
> > wondering what equivalent we have, or can develop, for arm.
> > Here are some thoughts;
> > 0) there's already something we can use, and I just need to be told
> >    about it.
> > 1) be as similar as possible to x86 by dedicating some currently
> >    undefined sysreg bits. This would take buy-in from lots of parties,
> >    so is not likely the way to go.
> > 2) create a specific DT node that will get exposed through sysfs, or
> >    somewhere.
> > 3) same as (2), but just use the nodes currently in mach-virt's DT
> >    as the indication we're a guest. This would just be a heuristic,
> >    i.e. "have virtio mmio" && psci.method == hvc, or something,
> >    and we'd still need a way to know if we're kvm vs. xen vs. ??.
> > 
> > Thanks,
> > drew 
> > 
> > [1] http://people.redhat.com/~rjones/virt-what/
> > [2] http://git.annexia.org/?p=virt-what.git;a=summary
> > [3] http://git.annexia.org/?p=virt-what.git;a=blob_plain;f=virt-what-cpuid-helper.c;hb=HEAD
> 
> Thanks everyone for their responses. So, the current summary seems to
> be;
> 1) Xen has both a DT node and an ACPI table, virt-what can learn how
>    to probe those.
> 2) We don't have anything yet for KVM, and we're reluctant to create a
>    specific DT node. Anyway, we'd still need to address ACPI booted
>    guests some other way.
> 
> For a short-term, DT-only, approach we could go with a heuristic, one
> that includes Marc's "if hypervisor node exists, then xen, else kvm"
> condition.
> 
> How about SMBIOS for a long-term solution that works for both DT and
> ACPI? We're not populating SMBIOS for arm guests yet in qemu, but now
> that AAVMF has fw_cfg, we should be able to. On x86 we already have
> smbios populated from qemu, although not in a way that allows us to
> determine kvm vs. xen vs. tcg.

I don't think that SMBIOS works with DT.


> Any other suggestions?
> 
> drew
> 

ARM: KVM/XEN: how should we support virt-what?

[Stefano Stabellini]

On Thu, 26 Mar 2015, Andrew Jones wrote:
> On Wed, Mar 25, 2015 at 10:44:42AM +0100, Andrew Jones wrote:
> > Hello ARM virt maintainers,
> > 
> > I'd like to start a discussion about supporting virt-what[1]. virt-what
> > allows userspace to determine if the system it's running on is running
> > in a guest, and of what type (KVM, Xen, etc.). Despite it being a best
> > effort tool, see the Caveat emptor in [1], it has become quite a useful
> > tool, and is showing up in different places, such as OpenStack. If you
> > look at the code[2], specifically [3], then you'll see how it works on
> > x86, which is to use the dedicated hypervisor cpuid leaves. I'm
> > wondering what equivalent we have, or can develop, for arm.
> > Here are some thoughts;
> > 0) there's already something we can use, and I just need to be told
> >    about it.
> > 1) be as similar as possible to x86 by dedicating some currently
> >    undefined sysreg bits. This would take buy-in from lots of parties,
> >    so is not likely the way to go.
> > 2) create a specific DT node that will get exposed through sysfs, or
> >    somewhere.
> > 3) same as (2), but just use the nodes currently in mach-virt's DT
> >    as the indication we're a guest. This would just be a heuristic,
> >    i.e. "have virtio mmio" && psci.method == hvc, or something,
> >    and we'd still need a way to know if we're kvm vs. xen vs. ??.
> > 
> > Thanks,
> > drew 
> > 
> > [1] http://people.redhat.com/~rjones/virt-what/
> > [2] http://git.annexia.org/?p=virt-what.git;a=summary
> > [3] http://git.annexia.org/?p=virt-what.git;a=blob_plain;f=virt-what-cpuid-helper.c;hb=HEAD
> 
> Thanks everyone for their responses. So, the current summary seems to
> be;
> 1) Xen has both a DT node and an ACPI table, virt-what can learn how
>    to probe those.
> 2) We don't have anything yet for KVM, and we're reluctant to create a
>    specific DT node. Anyway, we'd still need to address ACPI booted
>    guests some other way.
> 
> For a short-term, DT-only, approach we could go with a heuristic, one
> that includes Marc's "if hypervisor node exists, then xen, else kvm"
> condition.
> 
> How about SMBIOS for a long-term solution that works for both DT and
> ACPI? We're not populating SMBIOS for arm guests yet in qemu, but now
> that AAVMF has fw_cfg, we should be able to. On x86 we already have
> smbios populated from qemu, although not in a way that allows us to
> determine kvm vs. xen vs. tcg.

I don't think that SMBIOS works with DT.


> Any other suggestions?
> 
> drew
> 

Re: ARM: KVM/XEN: how should we support virt-what?

[Stefano Stabellini]

On Thu, 26 Mar 2015, Andrew Jones wrote:
> On Wed, Mar 25, 2015 at 10:44:42AM +0100, Andrew Jones wrote:
> > Hello ARM virt maintainers,
> > 
> > I'd like to start a discussion about supporting virt-what[1]. virt-what
> > allows userspace to determine if the system it's running on is running
> > in a guest, and of what type (KVM, Xen, etc.). Despite it being a best
> > effort tool, see the Caveat emptor in [1], it has become quite a useful
> > tool, and is showing up in different places, such as OpenStack. If you
> > look at the code[2], specifically [3], then you'll see how it works on
> > x86, which is to use the dedicated hypervisor cpuid leaves. I'm
> > wondering what equivalent we have, or can develop, for arm.
> > Here are some thoughts;
> > 0) there's already something we can use, and I just need to be told
> >    about it.
> > 1) be as similar as possible to x86 by dedicating some currently
> >    undefined sysreg bits. This would take buy-in from lots of parties,
> >    so is not likely the way to go.
> > 2) create a specific DT node that will get exposed through sysfs, or
> >    somewhere.
> > 3) same as (2), but just use the nodes currently in mach-virt's DT
> >    as the indication we're a guest. This would just be a heuristic,
> >    i.e. "have virtio mmio" && psci.method == hvc, or something,
> >    and we'd still need a way to know if we're kvm vs. xen vs. ??.
> > 
> > Thanks,
> > drew 
> > 
> > [1] http://people.redhat.com/~rjones/virt-what/
> > [2] http://git.annexia.org/?p=virt-what.git;a=summary
> > [3] http://git.annexia.org/?p=virt-what.git;a=blob_plain;f=virt-what-cpuid-helper.c;hb=HEAD
> 
> Thanks everyone for their responses. So, the current summary seems to
> be;
> 1) Xen has both a DT node and an ACPI table, virt-what can learn how
>    to probe those.
> 2) We don't have anything yet for KVM, and we're reluctant to create a
>    specific DT node. Anyway, we'd still need to address ACPI booted
>    guests some other way.
> 
> For a short-term, DT-only, approach we could go with a heuristic, one
> that includes Marc's "if hypervisor node exists, then xen, else kvm"
> condition.
> 
> How about SMBIOS for a long-term solution that works for both DT and
> ACPI? We're not populating SMBIOS for arm guests yet in qemu, but now
> that AAVMF has fw_cfg, we should be able to. On x86 we already have
> smbios populated from qemu, although not in a way that allows us to
> determine kvm vs. xen vs. tcg.

I don't think that SMBIOS works with DT.


> Any other suggestions?
> 
> drew
> 

Re: ARM: KVM/XEN: how should we support virt-what?

[Ard Biesheuvel]

On 26 March 2015 at 19:45, Stefano Stabellini
<stefano.stabellini@eu.citrix.com> wrote:
> On Thu, 26 Mar 2015, Andrew Jones wrote:
>> On Wed, Mar 25, 2015 at 10:44:42AM +0100, Andrew Jones wrote:
>> > Hello ARM virt maintainers,
>> >
>> > I'd like to start a discussion about supporting virt-what[1]. virt-what
>> > allows userspace to determine if the system it's running on is running
>> > in a guest, and of what type (KVM, Xen, etc.). Despite it being a best
>> > effort tool, see the Caveat emptor in [1], it has become quite a useful
>> > tool, and is showing up in different places, such as OpenStack. If you
>> > look at the code[2], specifically [3], then you'll see how it works on
>> > x86, which is to use the dedicated hypervisor cpuid leaves. I'm
>> > wondering what equivalent we have, or can develop, for arm.
>> > Here are some thoughts;
>> > 0) there's already something we can use, and I just need to be told
>> >    about it.
>> > 1) be as similar as possible to x86 by dedicating some currently
>> >    undefined sysreg bits. This would take buy-in from lots of parties,
>> >    so is not likely the way to go.
>> > 2) create a specific DT node that will get exposed through sysfs, or
>> >    somewhere.
>> > 3) same as (2), but just use the nodes currently in mach-virt's DT
>> >    as the indication we're a guest. This would just be a heuristic,
>> >    i.e. "have virtio mmio" && psci.method == hvc, or something,
>> >    and we'd still need a way to know if we're kvm vs. xen vs. ??.
>> >
>> > Thanks,
>> > drew
>> >
>> > [1] http://people.redhat.com/~rjones/virt-what/
>> > [2] http://git.annexia.org/?p=virt-what.git;a=summary
>> > [3] http://git.annexia.org/?p=virt-what.git;a=blob_plain;f=virt-what-cpuid-helper.c;hb=HEAD
>>
>> Thanks everyone for their responses. So, the current summary seems to
>> be;
>> 1) Xen has both a DT node and an ACPI table, virt-what can learn how
>>    to probe those.
>> 2) We don't have anything yet for KVM, and we're reluctant to create a
>>    specific DT node. Anyway, we'd still need to address ACPI booted
>>    guests some other way.
>>
>> For a short-term, DT-only, approach we could go with a heuristic, one
>> that includes Marc's "if hypervisor node exists, then xen, else kvm"
>> condition.
>>
>> How about SMBIOS for a long-term solution that works for both DT and
>> ACPI? We're not populating SMBIOS for arm guests yet in qemu, but now
>> that AAVMF has fw_cfg, we should be able to. On x86 we already have
>> smbios populated from qemu, although not in a way that allows us to
>> determine kvm vs. xen vs. tcg.
>
> I don't think that SMBIOS works with DT.
>

SMBIOS works fine with DT

Re: ARM: KVM/XEN: how should we support virt-what?

[Ard Biesheuvel]

On 26 March 2015 at 19:45, Stefano Stabellini
<stefano.stabellini@eu.citrix.com> wrote:
> On Thu, 26 Mar 2015, Andrew Jones wrote:
>> On Wed, Mar 25, 2015 at 10:44:42AM +0100, Andrew Jones wrote:
>> > Hello ARM virt maintainers,
>> >
>> > I'd like to start a discussion about supporting virt-what[1]. virt-what
>> > allows userspace to determine if the system it's running on is running
>> > in a guest, and of what type (KVM, Xen, etc.). Despite it being a best
>> > effort tool, see the Caveat emptor in [1], it has become quite a useful
>> > tool, and is showing up in different places, such as OpenStack. If you
>> > look at the code[2], specifically [3], then you'll see how it works on
>> > x86, which is to use the dedicated hypervisor cpuid leaves. I'm
>> > wondering what equivalent we have, or can develop, for arm.
>> > Here are some thoughts;
>> > 0) there's already something we can use, and I just need to be told
>> >    about it.
>> > 1) be as similar as possible to x86 by dedicating some currently
>> >    undefined sysreg bits. This would take buy-in from lots of parties,
>> >    so is not likely the way to go.
>> > 2) create a specific DT node that will get exposed through sysfs, or
>> >    somewhere.
>> > 3) same as (2), but just use the nodes currently in mach-virt's DT
>> >    as the indication we're a guest. This would just be a heuristic,
>> >    i.e. "have virtio mmio" && psci.method == hvc, or something,
>> >    and we'd still need a way to know if we're kvm vs. xen vs. ??.
>> >
>> > Thanks,
>> > drew
>> >
>> > [1] http://people.redhat.com/~rjones/virt-what/
>> > [2] http://git.annexia.org/?p=virt-what.git;a=summary
>> > [3] http://git.annexia.org/?p=virt-what.git;a=blob_plain;f=virt-what-cpuid-helper.c;hb=HEAD
>>
>> Thanks everyone for their responses. So, the current summary seems to
>> be;
>> 1) Xen has both a DT node and an ACPI table, virt-what can learn how
>>    to probe those.
>> 2) We don't have anything yet for KVM, and we're reluctant to create a
>>    specific DT node. Anyway, we'd still need to address ACPI booted
>>    guests some other way.
>>
>> For a short-term, DT-only, approach we could go with a heuristic, one
>> that includes Marc's "if hypervisor node exists, then xen, else kvm"
>> condition.
>>
>> How about SMBIOS for a long-term solution that works for both DT and
>> ACPI? We're not populating SMBIOS for arm guests yet in qemu, but now
>> that AAVMF has fw_cfg, we should be able to. On x86 we already have
>> smbios populated from qemu, although not in a way that allows us to
>> determine kvm vs. xen vs. tcg.
>
> I don't think that SMBIOS works with DT.
>

SMBIOS works fine with DT

ARM: KVM/XEN: how should we support virt-what?

[Ard Biesheuvel]

On 26 March 2015 at 19:45, Stefano Stabellini
<stefano.stabellini@eu.citrix.com> wrote:
> On Thu, 26 Mar 2015, Andrew Jones wrote:
>> On Wed, Mar 25, 2015 at 10:44:42AM +0100, Andrew Jones wrote:
>> > Hello ARM virt maintainers,
>> >
>> > I'd like to start a discussion about supporting virt-what[1]. virt-what
>> > allows userspace to determine if the system it's running on is running
>> > in a guest, and of what type (KVM, Xen, etc.). Despite it being a best
>> > effort tool, see the Caveat emptor in [1], it has become quite a useful
>> > tool, and is showing up in different places, such as OpenStack. If you
>> > look at the code[2], specifically [3], then you'll see how it works on
>> > x86, which is to use the dedicated hypervisor cpuid leaves. I'm
>> > wondering what equivalent we have, or can develop, for arm.
>> > Here are some thoughts;
>> > 0) there's already something we can use, and I just need to be told
>> >    about it.
>> > 1) be as similar as possible to x86 by dedicating some currently
>> >    undefined sysreg bits. This would take buy-in from lots of parties,
>> >    so is not likely the way to go.
>> > 2) create a specific DT node that will get exposed through sysfs, or
>> >    somewhere.
>> > 3) same as (2), but just use the nodes currently in mach-virt's DT
>> >    as the indication we're a guest. This would just be a heuristic,
>> >    i.e. "have virtio mmio" && psci.method == hvc, or something,
>> >    and we'd still need a way to know if we're kvm vs. xen vs. ??.
>> >
>> > Thanks,
>> > drew
>> >
>> > [1] http://people.redhat.com/~rjones/virt-what/
>> > [2] http://git.annexia.org/?p=virt-what.git;a=summary
>> > [3] http://git.annexia.org/?p=virt-what.git;a=blob_plain;f=virt-what-cpuid-helper.c;hb=HEAD
>>
>> Thanks everyone for their responses. So, the current summary seems to
>> be;
>> 1) Xen has both a DT node and an ACPI table, virt-what can learn how
>>    to probe those.
>> 2) We don't have anything yet for KVM, and we're reluctant to create a
>>    specific DT node. Anyway, we'd still need to address ACPI booted
>>    guests some other way.
>>
>> For a short-term, DT-only, approach we could go with a heuristic, one
>> that includes Marc's "if hypervisor node exists, then xen, else kvm"
>> condition.
>>
>> How about SMBIOS for a long-term solution that works for both DT and
>> ACPI? We're not populating SMBIOS for arm guests yet in qemu, but now
>> that AAVMF has fw_cfg, we should be able to. On x86 we already have
>> smbios populated from qemu, although not in a way that allows us to
>> determine kvm vs. xen vs. tcg.
>
> I don't think that SMBIOS works with DT.
>

SMBIOS works fine with DT

Re: ARM: KVM/XEN: how should we support virt-what?

[Ard Biesheuvel]

On 26 March 2015 at 19:49, Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote:
> On 26 March 2015 at 19:45, Stefano Stabellini
> <stefano.stabellini@eu.citrix.com> wrote:
>> On Thu, 26 Mar 2015, Andrew Jones wrote:
>>> On Wed, Mar 25, 2015 at 10:44:42AM +0100, Andrew Jones wrote:
>>> > Hello ARM virt maintainers,
>>> >
>>> > I'd like to start a discussion about supporting virt-what[1]. virt-what
>>> > allows userspace to determine if the system it's running on is running
>>> > in a guest, and of what type (KVM, Xen, etc.). Despite it being a best
>>> > effort tool, see the Caveat emptor in [1], it has become quite a useful
>>> > tool, and is showing up in different places, such as OpenStack. If you
>>> > look at the code[2], specifically [3], then you'll see how it works on
>>> > x86, which is to use the dedicated hypervisor cpuid leaves. I'm
>>> > wondering what equivalent we have, or can develop, for arm.
>>> > Here are some thoughts;
>>> > 0) there's already something we can use, and I just need to be told
>>> >    about it.
>>> > 1) be as similar as possible to x86 by dedicating some currently
>>> >    undefined sysreg bits. This would take buy-in from lots of parties,
>>> >    so is not likely the way to go.
>>> > 2) create a specific DT node that will get exposed through sysfs, or
>>> >    somewhere.
>>> > 3) same as (2), but just use the nodes currently in mach-virt's DT
>>> >    as the indication we're a guest. This would just be a heuristic,
>>> >    i.e. "have virtio mmio" && psci.method == hvc, or something,
>>> >    and we'd still need a way to know if we're kvm vs. xen vs. ??.
>>> >
>>> > Thanks,
>>> > drew
>>> >
>>> > [1] http://people.redhat.com/~rjones/virt-what/
>>> > [2] http://git.annexia.org/?p=virt-what.git;a=summary
>>> > [3] http://git.annexia.org/?p=virt-what.git;a=blob_plain;f=virt-what-cpuid-helper.c;hb=HEAD
>>>
>>> Thanks everyone for their responses. So, the current summary seems to
>>> be;
>>> 1) Xen has both a DT node and an ACPI table, virt-what can learn how
>>>    to probe those.
>>> 2) We don't have anything yet for KVM, and we're reluctant to create a
>>>    specific DT node. Anyway, we'd still need to address ACPI booted
>>>    guests some other way.
>>>
>>> For a short-term, DT-only, approach we could go with a heuristic, one
>>> that includes Marc's "if hypervisor node exists, then xen, else kvm"
>>> condition.
>>>
>>> How about SMBIOS for a long-term solution that works for both DT and
>>> ACPI? We're not populating SMBIOS for arm guests yet in qemu, but now
>>> that AAVMF has fw_cfg, we should be able to. On x86 we already have
>>> smbios populated from qemu, although not in a way that allows us to
>>> determine kvm vs. xen vs. tcg.
>>
>> I don't think that SMBIOS works with DT.
>>
>
> SMBIOS works fine with DT

... but it needs UEFI ...

Re: ARM: KVM/XEN: how should we support virt-what?

[Ard Biesheuvel]

On 26 March 2015 at 19:49, Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote:
> On 26 March 2015 at 19:45, Stefano Stabellini
> <stefano.stabellini@eu.citrix.com> wrote:
>> On Thu, 26 Mar 2015, Andrew Jones wrote:
>>> On Wed, Mar 25, 2015 at 10:44:42AM +0100, Andrew Jones wrote:
>>> > Hello ARM virt maintainers,
>>> >
>>> > I'd like to start a discussion about supporting virt-what[1]. virt-what
>>> > allows userspace to determine if the system it's running on is running
>>> > in a guest, and of what type (KVM, Xen, etc.). Despite it being a best
>>> > effort tool, see the Caveat emptor in [1], it has become quite a useful
>>> > tool, and is showing up in different places, such as OpenStack. If you
>>> > look at the code[2], specifically [3], then you'll see how it works on
>>> > x86, which is to use the dedicated hypervisor cpuid leaves. I'm
>>> > wondering what equivalent we have, or can develop, for arm.
>>> > Here are some thoughts;
>>> > 0) there's already something we can use, and I just need to be told
>>> >    about it.
>>> > 1) be as similar as possible to x86 by dedicating some currently
>>> >    undefined sysreg bits. This would take buy-in from lots of parties,
>>> >    so is not likely the way to go.
>>> > 2) create a specific DT node that will get exposed through sysfs, or
>>> >    somewhere.
>>> > 3) same as (2), but just use the nodes currently in mach-virt's DT
>>> >    as the indication we're a guest. This would just be a heuristic,
>>> >    i.e. "have virtio mmio" && psci.method == hvc, or something,
>>> >    and we'd still need a way to know if we're kvm vs. xen vs. ??.
>>> >
>>> > Thanks,
>>> > drew
>>> >
>>> > [1] http://people.redhat.com/~rjones/virt-what/
>>> > [2] http://git.annexia.org/?p=virt-what.git;a=summary
>>> > [3] http://git.annexia.org/?p=virt-what.git;a=blob_plain;f=virt-what-cpuid-helper.c;hb=HEAD
>>>
>>> Thanks everyone for their responses. So, the current summary seems to
>>> be;
>>> 1) Xen has both a DT node and an ACPI table, virt-what can learn how
>>>    to probe those.
>>> 2) We don't have anything yet for KVM, and we're reluctant to create a
>>>    specific DT node. Anyway, we'd still need to address ACPI booted
>>>    guests some other way.
>>>
>>> For a short-term, DT-only, approach we could go with a heuristic, one
>>> that includes Marc's "if hypervisor node exists, then xen, else kvm"
>>> condition.
>>>
>>> How about SMBIOS for a long-term solution that works for both DT and
>>> ACPI? We're not populating SMBIOS for arm guests yet in qemu, but now
>>> that AAVMF has fw_cfg, we should be able to. On x86 we already have
>>> smbios populated from qemu, although not in a way that allows us to
>>> determine kvm vs. xen vs. tcg.
>>
>> I don't think that SMBIOS works with DT.
>>
>
> SMBIOS works fine with DT

... but it needs UEFI ...

ARM: KVM/XEN: how should we support virt-what?

[Ard Biesheuvel]

On 26 March 2015 at 19:49, Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote:
> On 26 March 2015 at 19:45, Stefano Stabellini
> <stefano.stabellini@eu.citrix.com> wrote:
>> On Thu, 26 Mar 2015, Andrew Jones wrote:
>>> On Wed, Mar 25, 2015 at 10:44:42AM +0100, Andrew Jones wrote:
>>> > Hello ARM virt maintainers,
>>> >
>>> > I'd like to start a discussion about supporting virt-what[1]. virt-what
>>> > allows userspace to determine if the system it's running on is running
>>> > in a guest, and of what type (KVM, Xen, etc.). Despite it being a best
>>> > effort tool, see the Caveat emptor in [1], it has become quite a useful
>>> > tool, and is showing up in different places, such as OpenStack. If you
>>> > look at the code[2], specifically [3], then you'll see how it works on
>>> > x86, which is to use the dedicated hypervisor cpuid leaves. I'm
>>> > wondering what equivalent we have, or can develop, for arm.
>>> > Here are some thoughts;
>>> > 0) there's already something we can use, and I just need to be told
>>> >    about it.
>>> > 1) be as similar as possible to x86 by dedicating some currently
>>> >    undefined sysreg bits. This would take buy-in from lots of parties,
>>> >    so is not likely the way to go.
>>> > 2) create a specific DT node that will get exposed through sysfs, or
>>> >    somewhere.
>>> > 3) same as (2), but just use the nodes currently in mach-virt's DT
>>> >    as the indication we're a guest. This would just be a heuristic,
>>> >    i.e. "have virtio mmio" && psci.method == hvc, or something,
>>> >    and we'd still need a way to know if we're kvm vs. xen vs. ??.
>>> >
>>> > Thanks,
>>> > drew
>>> >
>>> > [1] http://people.redhat.com/~rjones/virt-what/
>>> > [2] http://git.annexia.org/?p=virt-what.git;a=summary
>>> > [3] http://git.annexia.org/?p=virt-what.git;a=blob_plain;f=virt-what-cpuid-helper.c;hb=HEAD
>>>
>>> Thanks everyone for their responses. So, the current summary seems to
>>> be;
>>> 1) Xen has both a DT node and an ACPI table, virt-what can learn how
>>>    to probe those.
>>> 2) We don't have anything yet for KVM, and we're reluctant to create a
>>>    specific DT node. Anyway, we'd still need to address ACPI booted
>>>    guests some other way.
>>>
>>> For a short-term, DT-only, approach we could go with a heuristic, one
>>> that includes Marc's "if hypervisor node exists, then xen, else kvm"
>>> condition.
>>>
>>> How about SMBIOS for a long-term solution that works for both DT and
>>> ACPI? We're not populating SMBIOS for arm guests yet in qemu, but now
>>> that AAVMF has fw_cfg, we should be able to. On x86 we already have
>>> smbios populated from qemu, although not in a way that allows us to
>>> determine kvm vs. xen vs. tcg.
>>
>> I don't think that SMBIOS works with DT.
>>
>
> SMBIOS works fine with DT

... but it needs UEFI ...

Re: ARM: KVM/XEN: how should we support virt-what?

[Andrew Jones]

On Thu, Mar 26, 2015 at 07:50:06PM +0100, Ard Biesheuvel wrote:
> On 26 March 2015 at 19:49, Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote:
> > On 26 March 2015 at 19:45, Stefano Stabellini
> > <stefano.stabellini@eu.citrix.com> wrote:
> >> On Thu, 26 Mar 2015, Andrew Jones wrote:
> >>> On Wed, Mar 25, 2015 at 10:44:42AM +0100, Andrew Jones wrote:
> >>> > Hello ARM virt maintainers,
> >>> >
> >>> > I'd like to start a discussion about supporting virt-what[1]. virt-what
> >>> > allows userspace to determine if the system it's running on is running
> >>> > in a guest, and of what type (KVM, Xen, etc.). Despite it being a best
> >>> > effort tool, see the Caveat emptor in [1], it has become quite a useful
> >>> > tool, and is showing up in different places, such as OpenStack. If you
> >>> > look at the code[2], specifically [3], then you'll see how it works on
> >>> > x86, which is to use the dedicated hypervisor cpuid leaves. I'm
> >>> > wondering what equivalent we have, or can develop, for arm.
> >>> > Here are some thoughts;
> >>> > 0) there's already something we can use, and I just need to be told
> >>> >    about it.
> >>> > 1) be as similar as possible to x86 by dedicating some currently
> >>> >    undefined sysreg bits. This would take buy-in from lots of parties,
> >>> >    so is not likely the way to go.
> >>> > 2) create a specific DT node that will get exposed through sysfs, or
> >>> >    somewhere.
> >>> > 3) same as (2), but just use the nodes currently in mach-virt's DT
> >>> >    as the indication we're a guest. This would just be a heuristic,
> >>> >    i.e. "have virtio mmio" && psci.method == hvc, or something,
> >>> >    and we'd still need a way to know if we're kvm vs. xen vs. ??.
> >>> >
> >>> > Thanks,
> >>> > drew
> >>> >
> >>> > [1] http://people.redhat.com/~rjones/virt-what/
> >>> > [2] http://git.annexia.org/?p=virt-what.git;a=summary
> >>> > [3] http://git.annexia.org/?p=virt-what.git;a=blob_plain;f=virt-what-cpuid-helper.c;hb=HEAD
> >>>
> >>> Thanks everyone for their responses. So, the current summary seems to
> >>> be;
> >>> 1) Xen has both a DT node and an ACPI table, virt-what can learn how
> >>>    to probe those.
> >>> 2) We don't have anything yet for KVM, and we're reluctant to create a
> >>>    specific DT node. Anyway, we'd still need to address ACPI booted
> >>>    guests some other way.
> >>>
> >>> For a short-term, DT-only, approach we could go with a heuristic, one
> >>> that includes Marc's "if hypervisor node exists, then xen, else kvm"
> >>> condition.
> >>>
> >>> How about SMBIOS for a long-term solution that works for both DT and
> >>> ACPI? We're not populating SMBIOS for arm guests yet in qemu, but now
> >>> that AAVMF has fw_cfg, we should be able to. On x86 we already have
> >>> smbios populated from qemu, although not in a way that allows us to
> >>> determine kvm vs. xen vs. tcg.
> >>
> >> I don't think that SMBIOS works with DT.
> >>
> >
> > SMBIOS works fine with DT
> 
> ... but it needs UEFI ...

Yes. Perhaps the short-term solution will be a long-term solution for
DT-only, non-UEFI guests, but we can do better for the guests with UEFI,
that may or may not be ACPI, by using SMBIOS.

Unless somebody objects to either/both of these paths, then I guess
we'll start heading down them both.

Thanks,
drew

ARM: KVM/XEN: how should we support virt-what?

[Andrew Jones]

On Thu, Mar 26, 2015 at 07:50:06PM +0100, Ard Biesheuvel wrote:
> On 26 March 2015 at 19:49, Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote:
> > On 26 March 2015 at 19:45, Stefano Stabellini
> > <stefano.stabellini@eu.citrix.com> wrote:
> >> On Thu, 26 Mar 2015, Andrew Jones wrote:
> >>> On Wed, Mar 25, 2015 at 10:44:42AM +0100, Andrew Jones wrote:
> >>> > Hello ARM virt maintainers,
> >>> >
> >>> > I'd like to start a discussion about supporting virt-what[1]. virt-what
> >>> > allows userspace to determine if the system it's running on is running
> >>> > in a guest, and of what type (KVM, Xen, etc.). Despite it being a best
> >>> > effort tool, see the Caveat emptor in [1], it has become quite a useful
> >>> > tool, and is showing up in different places, such as OpenStack. If you
> >>> > look at the code[2], specifically [3], then you'll see how it works on
> >>> > x86, which is to use the dedicated hypervisor cpuid leaves. I'm
> >>> > wondering what equivalent we have, or can develop, for arm.
> >>> > Here are some thoughts;
> >>> > 0) there's already something we can use, and I just need to be told
> >>> >    about it.
> >>> > 1) be as similar as possible to x86 by dedicating some currently
> >>> >    undefined sysreg bits. This would take buy-in from lots of parties,
> >>> >    so is not likely the way to go.
> >>> > 2) create a specific DT node that will get exposed through sysfs, or
> >>> >    somewhere.
> >>> > 3) same as (2), but just use the nodes currently in mach-virt's DT
> >>> >    as the indication we're a guest. This would just be a heuristic,
> >>> >    i.e. "have virtio mmio" && psci.method == hvc, or something,
> >>> >    and we'd still need a way to know if we're kvm vs. xen vs. ??.
> >>> >
> >>> > Thanks,
> >>> > drew
> >>> >
> >>> > [1] http://people.redhat.com/~rjones/virt-what/
> >>> > [2] http://git.annexia.org/?p=virt-what.git;a=summary
> >>> > [3] http://git.annexia.org/?p=virt-what.git;a=blob_plain;f=virt-what-cpuid-helper.c;hb=HEAD
> >>>
> >>> Thanks everyone for their responses. So, the current summary seems to
> >>> be;
> >>> 1) Xen has both a DT node and an ACPI table, virt-what can learn how
> >>>    to probe those.
> >>> 2) We don't have anything yet for KVM, and we're reluctant to create a
> >>>    specific DT node. Anyway, we'd still need to address ACPI booted
> >>>    guests some other way.
> >>>
> >>> For a short-term, DT-only, approach we could go with a heuristic, one
> >>> that includes Marc's "if hypervisor node exists, then xen, else kvm"
> >>> condition.
> >>>
> >>> How about SMBIOS for a long-term solution that works for both DT and
> >>> ACPI? We're not populating SMBIOS for arm guests yet in qemu, but now
> >>> that AAVMF has fw_cfg, we should be able to. On x86 we already have
> >>> smbios populated from qemu, although not in a way that allows us to
> >>> determine kvm vs. xen vs. tcg.
> >>
> >> I don't think that SMBIOS works with DT.
> >>
> >
> > SMBIOS works fine with DT
> 
> ... but it needs UEFI ...

Yes. Perhaps the short-term solution will be a long-term solution for
DT-only, non-UEFI guests, but we can do better for the guests with UEFI,
that may or may not be ACPI, by using SMBIOS.

Unless somebody objects to either/both of these paths, then I guess
we'll start heading down them both.

Thanks,
drew

Re: ARM: KVM/XEN: how should we support virt-what?

[Andrew Jones]

On Thu, Mar 26, 2015 at 07:50:06PM +0100, Ard Biesheuvel wrote:
> On 26 March 2015 at 19:49, Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote:
> > On 26 March 2015 at 19:45, Stefano Stabellini
> > <stefano.stabellini@eu.citrix.com> wrote:
> >> On Thu, 26 Mar 2015, Andrew Jones wrote:
> >>> On Wed, Mar 25, 2015 at 10:44:42AM +0100, Andrew Jones wrote:
> >>> > Hello ARM virt maintainers,
> >>> >
> >>> > I'd like to start a discussion about supporting virt-what[1]. virt-what
> >>> > allows userspace to determine if the system it's running on is running
> >>> > in a guest, and of what type (KVM, Xen, etc.). Despite it being a best
> >>> > effort tool, see the Caveat emptor in [1], it has become quite a useful
> >>> > tool, and is showing up in different places, such as OpenStack. If you
> >>> > look at the code[2], specifically [3], then you'll see how it works on
> >>> > x86, which is to use the dedicated hypervisor cpuid leaves. I'm
> >>> > wondering what equivalent we have, or can develop, for arm.
> >>> > Here are some thoughts;
> >>> > 0) there's already something we can use, and I just need to be told
> >>> >    about it.
> >>> > 1) be as similar as possible to x86 by dedicating some currently
> >>> >    undefined sysreg bits. This would take buy-in from lots of parties,
> >>> >    so is not likely the way to go.
> >>> > 2) create a specific DT node that will get exposed through sysfs, or
> >>> >    somewhere.
> >>> > 3) same as (2), but just use the nodes currently in mach-virt's DT
> >>> >    as the indication we're a guest. This would just be a heuristic,
> >>> >    i.e. "have virtio mmio" && psci.method == hvc, or something,
> >>> >    and we'd still need a way to know if we're kvm vs. xen vs. ??.
> >>> >
> >>> > Thanks,
> >>> > drew
> >>> >
> >>> > [1] http://people.redhat.com/~rjones/virt-what/
> >>> > [2] http://git.annexia.org/?p=virt-what.git;a=summary
> >>> > [3] http://git.annexia.org/?p=virt-what.git;a=blob_plain;f=virt-what-cpuid-helper.c;hb=HEAD
> >>>
> >>> Thanks everyone for their responses. So, the current summary seems to
> >>> be;
> >>> 1) Xen has both a DT node and an ACPI table, virt-what can learn how
> >>>    to probe those.
> >>> 2) We don't have anything yet for KVM, and we're reluctant to create a
> >>>    specific DT node. Anyway, we'd still need to address ACPI booted
> >>>    guests some other way.
> >>>
> >>> For a short-term, DT-only, approach we could go with a heuristic, one
> >>> that includes Marc's "if hypervisor node exists, then xen, else kvm"
> >>> condition.
> >>>
> >>> How about SMBIOS for a long-term solution that works for both DT and
> >>> ACPI? We're not populating SMBIOS for arm guests yet in qemu, but now
> >>> that AAVMF has fw_cfg, we should be able to. On x86 we already have
> >>> smbios populated from qemu, although not in a way that allows us to
> >>> determine kvm vs. xen vs. tcg.
> >>
> >> I don't think that SMBIOS works with DT.
> >>
> >
> > SMBIOS works fine with DT
> 
> ... but it needs UEFI ...

Yes. Perhaps the short-term solution will be a long-term solution for
DT-only, non-UEFI guests, but we can do better for the guests with UEFI,
that may or may not be ACPI, by using SMBIOS.

Unless somebody objects to either/both of these paths, then I guess
we'll start heading down them both.

Thanks,
drew