3:01 p.m.
Hypervisor.framework provides a lightweight interface to run a virtual
cpu on macOS without the need to install third-party kernel
extensions (KEXTs).
It's supported since macOS 10.10 on machines with Intel VT-x feature
set that includes Extended Page Tables (EPT) and Unrestricted Mode.
QEMU supports Hypervisor.framework since 2.12.
The patch series adds "hvf" domain that uses Hypevisor.framework.
v1: https://www.redhat.com/archives/libvir-list/2018-October/msg01090.html
Changes since v1:
- [x] Fixed unconditional addition of KVM CPU models into capabilities cache.
That fixed a "make check" issue in qemucapabilitiestest on Linux.
- [x] Fixed missing brace in virQEMUCapsFormatCPUModels in PATCH 6
- [x] Squashed patch 12 into the first patch (second one in the patch series)
- [x] Added hvf domain definition to docs/formatdomain.html.in into the first
patch (second in the patch series)
- [x] Removed redundant argument in virQEMUCapsProbeHVF (patch 3)
- [x] Added separate virQEMUCapsProbeHVF for non-apple platforms (patch 3)
- [x] Added macOS support page
- [x] Marked HVF support for all working domain elements
I wasn't able to resolve the issues below, but I think they should go
into separate patches/patch series:
- [ ] To make qemucapabilitiestests work regardless of OS, accelerator probing
should be done via QMP command.
So, there's a need to add a new generic
command to QEMU "query-accelerator accel=NAME"
- [ ] VIRT_TEST_PRELOAD doesn't work on macOS. There are a few
reasons:
* DYLD_INSERT_LIBRARIES should be used instead of LD_PRELOAD
*
-module flag shouldn't be added to LDFLAGS in tests/Makefile.am.
The flag instructs libtool to creates bundles (MH_BUNDLE) instead of
dynamic libraries (MH_DYLIB) and unlike dylibs they cannot be preloaded.
* Either symbol interposing or flat namespaces should be used to perform
overrides of the calls to the mocks.
I've tried both but neither worked for me, need to make a minimal
example.
I haven't completed the investigation as it looks like a separate work item.
- [ ] Can't retrieve qemucapsprobe replies for macOS because qemucapsprobemock
is not getting injected because of the issue with VIRT_TEST_PRELOAD
- [ ] Can't add to tests/qemuxml2argvtest.c to illustrate the hvf example
because qemucapsprobe doesn't work yet.
Roman Bolshakov (16):
qemu: Add KVM CPUs into cache only if KVM is present
conf: Add hvf domain type
qemu: Define hvf capability
qemu: Query hvf capability on macOS
qemu: Expose hvf domain type if hvf is supported
qemu: Rename kvmCPU to accelCPU
qemu: Introduce virQEMUCapsTypeIsAccelerated
qemu: Introduce virQEMUCapsHaveAccel
qemu: Introduce virQEMUCapsToVirtType
qemu: Introduce virQEMUCapsAccelStr
qemu: Make error message accel-agnostic
qemu: Correct CPU capabilities probing for hvf
news: Mention hvf domain type
docs: Add hvf on QEMU driver page
docs: Note hvf support for domain elements
docs: Add support page for libvirt on macOS
docs/docs.html.in | 3 +
docs/drvqemu.html.in | 49 +++++++-
docs/formatdomain.html.in | 141 ++++++++++++---------
docs/index.html.in | 4 +-
docs/macos.html.in | 229 ++++++++++++++++++++++++++++++++++
docs/news.xml | 12 ++
docs/schemas/domaincommon.rng | 1 +
src/conf/domain_conf.c | 4 +-
src/conf/domain_conf.h | 1 +
src/qemu/qemu_capabilities.c | 201 +++++++++++++++++++++--------
src/qemu/qemu_capabilities.h | 1 +
src/qemu/qemu_command.c | 4 +
12 files changed, 534 insertions(+), 116 deletions(-)
create mode 100644 docs/macos.html.in
--
2.19.1
3:01 p.m.
New subject: [libvirt] [PATCHv2 01/16] qemu: Add KVM CPUs into cache only if KVM is present
From: Roman Bolshakov <roolebo(a)gmail.com>
virQEMUCapsFormatCache/virQEMUCapsLoadCache adds/reads KVM CPUs to/from
capabilities cache regardless of QEMU_CAPS_KVM. That can cause undesired
side-effects when KVM CPUs are present in the cache on a platform that
doesn't support it, e.g. macOS or Linux without KVM support.
Signed-off-by: Daniel P. Berrangé <berrange(a)redhat.com>
Signed-off-by: Roman Bolshakov <roolebo(a)gmail.com>
---
src/qemu/qemu_capabilities.c | 18 ++++++++++++------
1 file changed, 12 insertions(+), 6 deletions(-)
diff --git a/src/qemu/qemu_capabilities.c b/src/qemu/qemu_capabilities.c
index fde27010e4..4ba8369e3a 100644
--- a/src/qemu/qemu_capabilities.c
+++ b/src/qemu/qemu_capabilities.c
@@ -3467,11 +3467,13 @@ virQEMUCapsLoadCache(virArch hostArch,
}
VIR_FREE(str);
- if (virQEMUCapsLoadHostCPUModelInfo(qemuCaps, ctxt, VIR_DOMAIN_VIRT_KVM) < 0 ||
+ if ((virQEMUCapsGet(qemuCaps, QEMU_CAPS_KVM) &&
+ virQEMUCapsLoadHostCPUModelInfo(qemuCaps, ctxt, VIR_DOMAIN_VIRT_KVM) < 0) ||
virQEMUCapsLoadHostCPUModelInfo(qemuCaps, ctxt, VIR_DOMAIN_VIRT_QEMU) < 0)
goto cleanup;
- if (virQEMUCapsLoadCPUModels(qemuCaps, ctxt, VIR_DOMAIN_VIRT_KVM) < 0 ||
+ if ((virQEMUCapsGet(qemuCaps, QEMU_CAPS_KVM) &&
+ virQEMUCapsLoadCPUModels(qemuCaps, ctxt, VIR_DOMAIN_VIRT_KVM) < 0) ||
virQEMUCapsLoadCPUModels(qemuCaps, ctxt, VIR_DOMAIN_VIRT_QEMU) < 0)
goto cleanup;
@@ -3584,7 +3586,8 @@ virQEMUCapsLoadCache(virArch hostArch,
if (virQEMUCapsParseSEVInfo(qemuCaps, ctxt) < 0)
goto cleanup;
- virQEMUCapsInitHostCPUModel(qemuCaps, hostArch, VIR_DOMAIN_VIRT_KVM);
+ if (virQEMUCapsGet(qemuCaps, QEMU_CAPS_KVM))
+ virQEMUCapsInitHostCPUModel(qemuCaps, hostArch, VIR_DOMAIN_VIRT_KVM);
virQEMUCapsInitHostCPUModel(qemuCaps, hostArch, VIR_DOMAIN_VIRT_QEMU);
ret = 0;
@@ -3766,10 +3769,12 @@ virQEMUCapsFormatCache(virQEMUCapsPtr qemuCaps)
virBufferAsprintf(&buf, "<arch>%s</arch>\n",
virArchToString(qemuCaps->arch));
- virQEMUCapsFormatHostCPUModelInfo(qemuCaps, &buf, VIR_DOMAIN_VIRT_KVM);
+ if (virQEMUCapsGet(qemuCaps, QEMU_CAPS_KVM))
+ virQEMUCapsFormatHostCPUModelInfo(qemuCaps, &buf, VIR_DOMAIN_VIRT_KVM);
virQEMUCapsFormatHostCPUModelInfo(qemuCaps, &buf, VIR_DOMAIN_VIRT_QEMU);
- virQEMUCapsFormatCPUModels(qemuCaps, &buf, VIR_DOMAIN_VIRT_KVM);
+ if (virQEMUCapsGet(qemuCaps, QEMU_CAPS_KVM))
+ virQEMUCapsFormatCPUModels(qemuCaps, &buf, VIR_DOMAIN_VIRT_KVM);
virQEMUCapsFormatCPUModels(qemuCaps, &buf, VIR_DOMAIN_VIRT_QEMU);
for (i = 0; i < qemuCaps->nmachineTypes; i++) {
@@ -4566,7 +4571,8 @@ virQEMUCapsNewForBinaryInternal(virArch hostArch,
qemuCaps->libvirtCtime = virGetSelfLastChanged();
qemuCaps->libvirtVersion = LIBVIR_VERSION_NUMBER;
- virQEMUCapsInitHostCPUModel(qemuCaps, hostArch, VIR_DOMAIN_VIRT_KVM);
+ if (virQEMUCapsGet(qemuCaps, QEMU_CAPS_KVM))
+ virQEMUCapsInitHostCPUModel(qemuCaps, hostArch, VIR_DOMAIN_VIRT_KVM);
virQEMUCapsInitHostCPUModel(qemuCaps, hostArch, VIR_DOMAIN_VIRT_QEMU);
if (virQEMUCapsGet(qemuCaps, QEMU_CAPS_KVM)) {
--
2.19.1
5:04 p.m.
New subject: [libvirt] [PATCHv2 01/16] qemu: Add KVM CPUs into cache only if KVM is present
On Wed, Nov 21, 2018 at 17:01:44 +0300, Roman Bolshakov wrote:
From: Roman Bolshakov <roolebo(a)gmail.com>
virQEMUCapsFormatCache/virQEMUCapsLoadCache adds/reads KVM CPUs to/from
capabilities cache regardless of QEMU_CAPS_KVM. That can cause undesired
side-effects when KVM CPUs are present in the cache on a platform that
doesn't support it, e.g. macOS or Linux without KVM support.
Signed-off-by: Daniel P. Berrangé <berrange(a)redhat.com>
Signed-off-by: Roman Bolshakov <roolebo(a)gmail.com>
This doesn't look like a patch written by Daniel so why did you include
the Signed-off-by line? Or did I miss anything?
---
src/qemu/qemu_capabilities.c | 18 ++++++++++++------
1 file changed, 12 insertions(+), 6 deletions(-)
diff --git a/src/qemu/qemu_capabilities.c b/src/qemu/qemu_capabilities.c
index fde27010e4..4ba8369e3a 100644
--- a/src/qemu/qemu_capabilities.c
+++ b/src/qemu/qemu_capabilities.c
@@ -3467,11 +3467,13 @@ virQEMUCapsLoadCache(virArch hostArch,
}
VIR_FREE(str);
- if (virQEMUCapsLoadHostCPUModelInfo(qemuCaps, ctxt, VIR_DOMAIN_VIRT_KVM) < 0 ||
+ if ((virQEMUCapsGet(qemuCaps, QEMU_CAPS_KVM) &&
+ virQEMUCapsLoadHostCPUModelInfo(qemuCaps, ctxt, VIR_DOMAIN_VIRT_KVM) < 0)
||
virQEMUCapsLoadHostCPUModelInfo(qemuCaps, ctxt, VIR_DOMAIN_VIRT_QEMU) < 0)
goto cleanup;
I don't think we should introduce these guards in all the places. All
the loading and formatting functions should return success if the
appropriate info is not available, so you should just make sure the
relevant info is NULL in qemuCaps.
- if (virQEMUCapsLoadCPUModels(qemuCaps, ctxt, VIR_DOMAIN_VIRT_KVM) < 0 ||
+ if ((virQEMUCapsGet(qemuCaps, QEMU_CAPS_KVM) &&
+ virQEMUCapsLoadCPUModels(qemuCaps, ctxt, VIR_DOMAIN_VIRT_KVM) < 0) ||
virQEMUCapsLoadCPUModels(qemuCaps, ctxt, VIR_DOMAIN_VIRT_QEMU) < 0)
goto cleanup;
@@ -3584,7 +3586,8 @@ virQEMUCapsLoadCache(virArch hostArch,
if (virQEMUCapsParseSEVInfo(qemuCaps, ctxt) < 0)
goto cleanup;
- virQEMUCapsInitHostCPUModel(qemuCaps, hostArch, VIR_DOMAIN_VIRT_KVM);
+ if (virQEMUCapsGet(qemuCaps, QEMU_CAPS_KVM))
+ virQEMUCapsInitHostCPUModel(qemuCaps, hostArch, VIR_DOMAIN_VIRT_KVM);
Please, follow our coding style, i.e., indent by 4 spaces.
virQEMUCapsInitHostCPUModel(qemuCaps, hostArch,
VIR_DOMAIN_VIRT_QEMU);
ret = 0;
...
Jirka
6:50 p.m.
New subject: [libvirt] [PATCHv2 01/16] qemu: Add KVM CPUs into cache only if KVM is present
On Wed, Nov 21, 2018 at 05:04:07PM +0100, Jiri Denemark wrote:
On Wed, Nov 21, 2018 at 17:01:44 +0300, Roman Bolshakov wrote:
> From: Roman Bolshakov <roolebo(a)gmail.com>
>
> virQEMUCapsFormatCache/virQEMUCapsLoadCache adds/reads KVM CPUs to/from
> capabilities cache regardless of QEMU_CAPS_KVM. That can cause undesired
> side-effects when KVM CPUs are present in the cache on a platform that
> doesn't support it, e.g. macOS or Linux without KVM support.
>
> Signed-off-by: Daniel P. Berrangé <berrange(a)redhat.com>
> Signed-off-by: Roman Bolshakov <roolebo(a)gmail.com>
This doesn't look like a patch written by Daniel so why did you include
the Signed-off-by line? Or did I miss anything?
Daniel kindly helped to root cause an issue I had with
qemucapabilitiestest in v1:
https://www.redhat.com/archives/libvir-list/2018-November/msg00740.html
and provided a diff that resolves the issue:
https://www.redhat.com/archives/libvir-list/2018-November/msg00767.html
Should I remove his Signed-off-by tag?
> ---
> src/qemu/qemu_capabilities.c | 18 ++++++++++++------
> 1 file changed, 12 insertions(+), 6 deletions(-)
>
> diff --git a/src/qemu/qemu_capabilities.c b/src/qemu/qemu_capabilities.c
> index fde27010e4..4ba8369e3a 100644
> --- a/src/qemu/qemu_capabilities.c
> +++ b/src/qemu/qemu_capabilities.c
> @@ -3467,11 +3467,13 @@ virQEMUCapsLoadCache(virArch hostArch,
> }
> VIR_FREE(str);
>
> - if (virQEMUCapsLoadHostCPUModelInfo(qemuCaps, ctxt, VIR_DOMAIN_VIRT_KVM) < 0
||
> + if ((virQEMUCapsGet(qemuCaps, QEMU_CAPS_KVM) &&
> + virQEMUCapsLoadHostCPUModelInfo(qemuCaps, ctxt, VIR_DOMAIN_VIRT_KVM) <
0) ||
> virQEMUCapsLoadHostCPUModelInfo(qemuCaps, ctxt, VIR_DOMAIN_VIRT_QEMU) <
0)
> goto cleanup;
I don't think we should introduce these guards in all the places. All
the loading and formatting functions should return success if the
appropriate info is not available, so you should just make sure the
relevant info is NULL in qemuCaps.
Do you mean the capabilities checks should be moved inside the
functions? Either way they're needed to avoid loading KVM cpus into QEMU
caps cache on the hosts without KVM support.
> @@ -3584,7 +3586,8 @@ virQEMUCapsLoadCache(virArch hostArch,
> if (virQEMUCapsParseSEVInfo(qemuCaps, ctxt) < 0)
> goto cleanup;
>
> - virQEMUCapsInitHostCPUModel(qemuCaps, hostArch, VIR_DOMAIN_VIRT_KVM);
> + if (virQEMUCapsGet(qemuCaps, QEMU_CAPS_KVM))
> + virQEMUCapsInitHostCPUModel(qemuCaps, hostArch, VIR_DOMAIN_VIRT_KVM);
Please, follow our coding style, i.e., indent by 4 spaces.
> virQEMUCapsInitHostCPUModel(qemuCaps, hostArch, VIR_DOMAIN_VIRT_QEMU);
>
> ret = 0;
...
Will do, thank you for catching this!
Best regards,
Roman
7:43 p.m.
New subject: [libvirt] [PATCHv2 01/16] qemu: Add KVM CPUs into cache only if KVM is present
On Wed, Nov 21, 2018 at 20:50:50 +0300, Roman Bolshakov wrote:
On Wed, Nov 21, 2018 at 05:04:07PM +0100, Jiri Denemark wrote:
> On Wed, Nov 21, 2018 at 17:01:44 +0300, Roman Bolshakov wrote:
> > From: Roman Bolshakov <roolebo(a)gmail.com>
> >
> > virQEMUCapsFormatCache/virQEMUCapsLoadCache adds/reads KVM CPUs to/from
> > capabilities cache regardless of QEMU_CAPS_KVM. That can cause undesired
> > side-effects when KVM CPUs are present in the cache on a platform that
> > doesn't support it, e.g. macOS or Linux without KVM support.
> >
> > Signed-off-by: Daniel P. Berrangé <berrange(a)redhat.com>
> > Signed-off-by: Roman Bolshakov <roolebo(a)gmail.com>
>
> This doesn't look like a patch written by Daniel so why did you include
> the Signed-off-by line? Or did I miss anything?
Daniel kindly helped to root cause an issue I had with
qemucapabilitiestest in v1:
https://www.redhat.com/archives/libvir-list/2018-November/msg00740.html
and provided a diff that resolves the issue:
https://www.redhat.com/archives/libvir-list/2018-November/msg00767.html
I see, I missed the diff.
Should I remove his Signed-off-by tag?
Dunno, I guess it's up to Daniel. But if the final patch is going to
look very differently anyway, I don't see a reason to keep the tag.
>
> > ---
> > src/qemu/qemu_capabilities.c | 18 ++++++++++++------
> > 1 file changed, 12 insertions(+), 6 deletions(-)
> >
> > diff --git a/src/qemu/qemu_capabilities.c b/src/qemu/qemu_capabilities.c
> > index fde27010e4..4ba8369e3a 100644
> > --- a/src/qemu/qemu_capabilities.c
> > +++ b/src/qemu/qemu_capabilities.c
> > @@ -3467,11 +3467,13 @@ virQEMUCapsLoadCache(virArch hostArch,
> > }
> > VIR_FREE(str);
> >
> > - if (virQEMUCapsLoadHostCPUModelInfo(qemuCaps, ctxt, VIR_DOMAIN_VIRT_KVM)
< 0 ||
> > + if ((virQEMUCapsGet(qemuCaps, QEMU_CAPS_KVM) &&
> > + virQEMUCapsLoadHostCPUModelInfo(qemuCaps, ctxt, VIR_DOMAIN_VIRT_KVM)
< 0) ||
> > virQEMUCapsLoadHostCPUModelInfo(qemuCaps, ctxt, VIR_DOMAIN_VIRT_QEMU)
< 0)
> > goto cleanup;
>
> I don't think we should introduce these guards in all the places. All
> the loading and formatting functions should return success if the
> appropriate info is not available, so you should just make sure the
> relevant info is NULL in qemuCaps.
Do you mean the capabilities checks should be moved inside the
functions?
virQEMUCapsLoadHostCPUModelInfo does (not literally, but effectively)
hostCPUNode = virXPathNode("./hostCPU[@type='kvm']", ctxt);
if (!hostCPUNode)
return 0;
virQEMUCapsLoadCPUModels does
n = virXPathNodeSet("./cpu[@type='kvm']", ctxt, &nodes);
if (n == 0)
return 0;
virQEMUCapsInitHostCPUModel always fills in something and your check
should probably remain in place for it
virQEMUCapsFormatHostCPUModelInfo does
virQEMUCapsHostCPUDataPtr cpuData = &qemuCaps->kvmCPU;
qemuMonitorCPUModelInfoPtr model = cpuData->info;
if (!model)
return;
virQEMUCapsFormatCPUModels
cpus = qemuCaps->kvmCPUModels;
if (!cpus)
return;
So to me it looks like all functions are ready to see NULL pointers and
just do nothing if that's the case. Thus the only thing this patch
should need to do is to make sure virQEMUCapsInitHostCPUModel does not
set something non-NULL there.
Jirka
3:16 p.m.
New subject: [libvirt] [PATCHv2 01/16] qemu: Add KVM CPUs into cache only if KVM is present
On Wed, Nov 21, 2018 at 07:43:43PM +0100, Jiri Denemark wrote:
On Wed, Nov 21, 2018 at 20:50:50 +0300, Roman Bolshakov wrote:
> On Wed, Nov 21, 2018 at 05:04:07PM +0100, Jiri Denemark wrote:
> > On Wed, Nov 21, 2018 at 17:01:44 +0300, Roman Bolshakov wrote:
> > > diff --git a/src/qemu/qemu_capabilities.c b/src/qemu/qemu_capabilities.c
> > > index fde27010e4..4ba8369e3a 100644
> > > --- a/src/qemu/qemu_capabilities.c
> > > +++ b/src/qemu/qemu_capabilities.c
> > > @@ -3467,11 +3467,13 @@ virQEMUCapsLoadCache(virArch hostArch,
> > > }
> > > VIR_FREE(str);
> > >
> > > - if (virQEMUCapsLoadHostCPUModelInfo(qemuCaps, ctxt,
VIR_DOMAIN_VIRT_KVM) < 0 ||
> > > + if ((virQEMUCapsGet(qemuCaps, QEMU_CAPS_KVM) &&
> > > + virQEMUCapsLoadHostCPUModelInfo(qemuCaps, ctxt,
VIR_DOMAIN_VIRT_KVM) < 0) ||
> > > virQEMUCapsLoadHostCPUModelInfo(qemuCaps, ctxt,
VIR_DOMAIN_VIRT_QEMU) < 0)
> > > goto cleanup;
> >
> > I don't think we should introduce these guards in all the places. All
> > the loading and formatting functions should return success if the
> > appropriate info is not available, so you should just make sure the
> > relevant info is NULL in qemuCaps.
>
> Do you mean the capabilities checks should be moved inside the
> functions?
virQEMUCapsLoadHostCPUModelInfo does (not literally, but effectively)
hostCPUNode = virXPathNode("./hostCPU[@type='kvm']", ctxt);
if (!hostCPUNode)
return 0;
virQEMUCapsLoadCPUModels does
n = virXPathNodeSet("./cpu[@type='kvm']", ctxt, &nodes);
if (n == 0)
return 0;
I agree, virQEMUCapsLoadHostCPUModelInfo and virQEMUCapsLoadCPUModels
don't need the check.
virQEMUCapsInitHostCPUModel always fills in something and your check
should probably remain in place for it
virQEMUCapsFormatHostCPUModelInfo does
virQEMUCapsHostCPUDataPtr cpuData = &qemuCaps->kvmCPU;
qemuMonitorCPUModelInfoPtr model = cpuData->info;
if (!model)
return;
virQEMUCapsFormatCPUModels
cpus = qemuCaps->kvmCPUModels;
if (!cpus)
return;
So to me it looks like all functions are ready to see NULL pointers and
just do nothing if that's the case. Thus the only thing this patch
should need to do is to make sure virQEMUCapsInitHostCPUModel does not
set something non-NULL there.
Unfortunately, that won't work for the patch series. kvmCPUModels is renamed to
accelCPUModels and kvmCPU is renamed to accelCPU in PATCH 6.
So, virQEMUCapsFormatHostCPUModelInfo looks like:
if (virQEMUCapsTypeIsAccelerated(type))
cpuData = qemuCaps->accelCPU;
else
cpuData = qemuCaps->tcgCPU;
and virQEMUCapsFormatCPUModels looks like:
if (virQEMUCapsTypeIsAccelerated(type))
cpus = qemuCaps->accelCPUModels;
else
cpus = qemuCaps->tcgCPUModels;
Without the check we'd return CPUs for KVM domain on the platform that doesn't
support it.
Thank you,
Roman
4:30 p.m.
New subject: [libvirt] [PATCHv2 01/16] qemu: Add KVM CPUs into cache only if KVM is present
On Fri, Nov 23, 2018 at 17:16:12 +0300, Roman Bolshakov wrote:
On Wed, Nov 21, 2018 at 07:43:43PM +0100, Jiri Denemark wrote:
> On Wed, Nov 21, 2018 at 20:50:50 +0300, Roman Bolshakov wrote:
> > On Wed, Nov 21, 2018 at 05:04:07PM +0100, Jiri Denemark wrote:
> > > On Wed, Nov 21, 2018 at 17:01:44 +0300, Roman Bolshakov wrote:
> > > > diff --git a/src/qemu/qemu_capabilities.c
b/src/qemu/qemu_capabilities.c
> > > > index fde27010e4..4ba8369e3a 100644
> > > > --- a/src/qemu/qemu_capabilities.c
> > > > +++ b/src/qemu/qemu_capabilities.c
> > > > @@ -3467,11 +3467,13 @@ virQEMUCapsLoadCache(virArch hostArch,
> > > > }
> > > > VIR_FREE(str);
> > > >
> > > > - if (virQEMUCapsLoadHostCPUModelInfo(qemuCaps, ctxt,
VIR_DOMAIN_VIRT_KVM) < 0 ||
> > > > + if ((virQEMUCapsGet(qemuCaps, QEMU_CAPS_KVM) &&
> > > > + virQEMUCapsLoadHostCPUModelInfo(qemuCaps, ctxt,
VIR_DOMAIN_VIRT_KVM) < 0) ||
> > > > virQEMUCapsLoadHostCPUModelInfo(qemuCaps, ctxt,
VIR_DOMAIN_VIRT_QEMU) < 0)
> > > > goto cleanup;
> > >
> > > I don't think we should introduce these guards in all the places. All
> > > the loading and formatting functions should return success if the
> > > appropriate info is not available, so you should just make sure the
> > > relevant info is NULL in qemuCaps.
> >
> > Do you mean the capabilities checks should be moved inside the
> > functions?
>
> virQEMUCapsLoadHostCPUModelInfo does (not literally, but effectively)
>
> hostCPUNode = virXPathNode("./hostCPU[@type='kvm']", ctxt);
> if (!hostCPUNode)
> return 0;
>
> virQEMUCapsLoadCPUModels does
> n = virXPathNodeSet("./cpu[@type='kvm']", ctxt, &nodes);
> if (n == 0)
> return 0;
>
I agree, virQEMUCapsLoadHostCPUModelInfo and virQEMUCapsLoadCPUModels
don't need the check.
> virQEMUCapsInitHostCPUModel always fills in something and your check
> should probably remain in place for it
>
> virQEMUCapsFormatHostCPUModelInfo does
> virQEMUCapsHostCPUDataPtr cpuData = &qemuCaps->kvmCPU;
> qemuMonitorCPUModelInfoPtr model = cpuData->info;
> if (!model)
> return;
>
> virQEMUCapsFormatCPUModels
> cpus = qemuCaps->kvmCPUModels;
> if (!cpus)
> return;
>
> So to me it looks like all functions are ready to see NULL pointers and
> just do nothing if that's the case. Thus the only thing this patch
> should need to do is to make sure virQEMUCapsInitHostCPUModel does not
> set something non-NULL there.
Unfortunately, that won't work for the patch series. kvmCPUModels is renamed to
accelCPUModels and kvmCPU is renamed to accelCPU in PATCH 6.
And how does different name change the behavior?
So, virQEMUCapsFormatHostCPUModelInfo looks like:
if (virQEMUCapsTypeIsAccelerated(type))
cpuData = qemuCaps->accelCPU;
else
cpuData = qemuCaps->tcgCPU;
and virQEMUCapsFormatCPUModels looks like:
if (virQEMUCapsTypeIsAccelerated(type))
cpus = qemuCaps->accelCPUModels;
else
cpus = qemuCaps->tcgCPUModels;
Without the check we'd return CPUs for KVM domain on the platform that doesn't
support it.
It won't return anything because the code will make sure accelCPUModels
and accelCPU will be NULL when no accel method is supported.
Jirka
4:55 p.m.
New subject: [libvirt] [PATCHv2 01/16] qemu: Add KVM CPUs into cache only if KVM is present
On Fri, Nov 23, 2018 at 04:30:13PM +0100, Jiri Denemark wrote:
On Fri, Nov 23, 2018 at 17:16:12 +0300, Roman Bolshakov wrote:
> On Wed, Nov 21, 2018 at 07:43:43PM +0100, Jiri Denemark wrote:
> > virQEMUCapsInitHostCPUModel always fills in something and your check
> > should probably remain in place for it
> >
> > virQEMUCapsFormatHostCPUModelInfo does
> > virQEMUCapsHostCPUDataPtr cpuData = &qemuCaps->kvmCPU;
> > qemuMonitorCPUModelInfoPtr model = cpuData->info;
> > if (!model)
> > return;
> >
> > virQEMUCapsFormatCPUModels
> > cpus = qemuCaps->kvmCPUModels;
> > if (!cpus)
> > return;
> >
> > So to me it looks like all functions are ready to see NULL pointers and
> > just do nothing if that's the case. Thus the only thing this patch
> > should need to do is to make sure virQEMUCapsInitHostCPUModel does not
> > set something non-NULL there.
>
> Unfortunately, that won't work for the patch series. kvmCPUModels is renamed to
> accelCPUModels and kvmCPU is renamed to accelCPU in PATCH 6.
And how does different name change the behavior?
> So, virQEMUCapsFormatHostCPUModelInfo looks like:
> if (virQEMUCapsTypeIsAccelerated(type))
> cpuData = qemuCaps->accelCPU;
> else
> cpuData = qemuCaps->tcgCPU;
>
> and virQEMUCapsFormatCPUModels looks like:
> if (virQEMUCapsTypeIsAccelerated(type))
> cpus = qemuCaps->accelCPUModels;
> else
> cpus = qemuCaps->tcgCPUModels;
>
> Without the check we'd return CPUs for KVM domain on the platform that
doesn't
> support it.
It won't return anything because the code will make sure accelCPUModels
and accelCPU will be NULL when no accel method is supported.
But accelCPU is not NULL on macOS with QEMU_CAPS_HVF and on Linux with
QEMU_CAPS_KVM. That's where the problem arises. We're going to get
additional kvm CPUs on mac and hvf CPUs on Linux and that will break
qemucapabilitiestest.
In fact they will be the same accelCPUs of the supported accelerator but
with hostCPU's type attribute of the other accelerator.
If you wish I can try to rework the patchset. Instead of generalizing
kvmCPU, I'd just add hvfCPU to qemuCaps. It might have a good side
effect that libvirt will be able to support multiple accelerators on the
same platform.
--
Roman
6:16 p.m.
New subject: [libvirt] [PATCHv2 01/16] qemu: Add KVM CPUs into cache only if KVM is present
On Fri, Nov 23, 2018 at 18:55:00 +0300, Roman Bolshakov wrote:
On Fri, Nov 23, 2018 at 04:30:13PM +0100, Jiri Denemark wrote:
> On Fri, Nov 23, 2018 at 17:16:12 +0300, Roman Bolshakov wrote:
> > On Wed, Nov 21, 2018 at 07:43:43PM +0100, Jiri Denemark wrote:
> > > virQEMUCapsInitHostCPUModel always fills in something and your check
> > > should probably remain in place for it
> > >
> > > virQEMUCapsFormatHostCPUModelInfo does
> > > virQEMUCapsHostCPUDataPtr cpuData = &qemuCaps->kvmCPU;
> > > qemuMonitorCPUModelInfoPtr model = cpuData->info;
> > > if (!model)
> > > return;
> > >
> > > virQEMUCapsFormatCPUModels
> > > cpus = qemuCaps->kvmCPUModels;
> > > if (!cpus)
> > > return;
> > >
> > > So to me it looks like all functions are ready to see NULL pointers and
> > > just do nothing if that's the case. Thus the only thing this patch
> > > should need to do is to make sure virQEMUCapsInitHostCPUModel does not
> > > set something non-NULL there.
> >
> > Unfortunately, that won't work for the patch series. kvmCPUModels is
renamed to
> > accelCPUModels and kvmCPU is renamed to accelCPU in PATCH 6.
>
> And how does different name change the behavior?
>
> > So, virQEMUCapsFormatHostCPUModelInfo looks like:
> > if (virQEMUCapsTypeIsAccelerated(type))
> > cpuData = qemuCaps->accelCPU;
> > else
> > cpuData = qemuCaps->tcgCPU;
> >
> > and virQEMUCapsFormatCPUModels looks like:
> > if (virQEMUCapsTypeIsAccelerated(type))
> > cpus = qemuCaps->accelCPUModels;
> > else
> > cpus = qemuCaps->tcgCPUModels;
> >
> > Without the check we'd return CPUs for KVM domain on the platform that
doesn't
> > support it.
>
> It won't return anything because the code will make sure accelCPUModels
> and accelCPU will be NULL when no accel method is supported.
But accelCPU is not NULL on macOS with QEMU_CAPS_HVF and on Linux with
QEMU_CAPS_KVM. That's where the problem arises.
Right, and that's what I think should be changed. Rather then adding
checks to the formatting and loading code to ignore something which
shouldn't be present in the first place.
We're going to get additional kvm CPUs on mac and hvf CPUs on
Linux
and that will break qemucapabilitiestest.
I think I'm missing something here. There's only one CPU definition
describing the host CPU. There are hosts which have several different
CPUs, but libvirt is not really prepared to see that and I believe this
is not what you're addressing with this series, is it? Or are you
talking about some other CPUs?
In fact they will be the same accelCPUs of the supported accelerator
but with hostCPU's type attribute of the other accelerator.
How would this happen? We have a single accelerator enabled on a host
and we generate a host CPU model for it (and just for it, there's no
reason to generate a CPU model for something that is not supported on
the host).
If you wish I can try to rework the patchset. Instead of
generalizing
kvmCPU, I'd just add hvfCPU to qemuCaps. It might have a good side
effect that libvirt will be able to support multiple accelerators on the
same platform.
I think we can leave this for the future :-)
Jirka
7:46 p.m.
New subject: [libvirt] [PATCHv2 01/16] qemu: Add KVM CPUs into cache only if KVM is present
On Fri, Nov 23, 2018 at 06:16:46PM +0100, Jiri Denemark wrote:
On Fri, Nov 23, 2018 at 18:55:00 +0300, Roman Bolshakov wrote:
> On Fri, Nov 23, 2018 at 04:30:13PM +0100, Jiri Denemark wrote:
> > On Fri, Nov 23, 2018 at 17:16:12 +0300, Roman Bolshakov wrote:
> > > On Wed, Nov 21, 2018 at 07:43:43PM +0100, Jiri Denemark wrote:
> > > > virQEMUCapsInitHostCPUModel always fills in something and your check
> > > > should probably remain in place for it
> > > >
> > > > virQEMUCapsFormatHostCPUModelInfo does
> > > > virQEMUCapsHostCPUDataPtr cpuData = &qemuCaps->kvmCPU;
> > > > qemuMonitorCPUModelInfoPtr model = cpuData->info;
> > > > if (!model)
> > > > return;
> > > >
> > > > virQEMUCapsFormatCPUModels
> > > > cpus = qemuCaps->kvmCPUModels;
> > > > if (!cpus)
> > > > return;
> > > >
> > > > So to me it looks like all functions are ready to see NULL pointers
and
> > > > just do nothing if that's the case. Thus the only thing this
patch
> > > > should need to do is to make sure virQEMUCapsInitHostCPUModel does
not
> > > > set something non-NULL there.
> > >
> > > Unfortunately, that won't work for the patch series. kvmCPUModels is
renamed to
> > > accelCPUModels and kvmCPU is renamed to accelCPU in PATCH 6.
> >
> > And how does different name change the behavior?
> >
> > > So, virQEMUCapsFormatHostCPUModelInfo looks like:
> > > if (virQEMUCapsTypeIsAccelerated(type))
> > > cpuData = qemuCaps->accelCPU;
> > > else
> > > cpuData = qemuCaps->tcgCPU;
> > >
> > > and virQEMUCapsFormatCPUModels looks like:
> > > if (virQEMUCapsTypeIsAccelerated(type))
> > > cpus = qemuCaps->accelCPUModels;
> > > else
> > > cpus = qemuCaps->tcgCPUModels;
> > >
> > > Without the check we'd return CPUs for KVM domain on the platform that
doesn't
> > > support it.
> >
> > It won't return anything because the code will make sure accelCPUModels
> > and accelCPU will be NULL when no accel method is supported.
>
> But accelCPU is not NULL on macOS with QEMU_CAPS_HVF and on Linux with
> QEMU_CAPS_KVM. That's where the problem arises.
Right, and that's what I think should be changed. Rather then adding
checks to the formatting and loading code to ignore something which
shouldn't be present in the first place.
> We're going to get additional kvm CPUs on mac and hvf CPUs on Linux
> and that will break qemucapabilitiestest.
I think I'm missing something here. There's only one CPU definition
describing the host CPU. There are hosts which have several different
CPUs, but libvirt is not really prepared to see that and I believe this
is not what you're addressing with this series, is it? Or are you
talking about some other CPUs?
> In fact they will be the same accelCPUs of the supported accelerator
> but with hostCPU's type attribute of the other accelerator.
How would this happen? We have a single accelerator enabled on a host
and we generate a host CPU model for it (and just for it, there's no
reason to generate a CPU model for something that is not supported on
the host).
accelCPU will be present on a host where an accelerator is avaialable.
You said can't have host CPU definitions present twice. I agree with
that. But if we call virQEMUCapsFormatCPUModels twice for
VIR_DOMAIN_VIRT_KVM and VIR_DOMAIN_VIRT_HVF without the checks, host cpu
definitions will be present twice for each accelerator because accelCPU
is not NULL.
So we need to call it only once for the supported accelerator.
The checks help in that. Alternative approach to do only one call is:
virDomainVirtType acceleratedDomain = VIR_DOMAIN_VIRT_KVM;
if (virQEMUCapsGet(qemuCaps, QEMU_CAPS_HVF))
acceleratedDomain = VIR_DOMAIN_VIRT_HVF;
virQEMUCapsFormatHostCPUModelInfo(qemuCaps, &buf, acceleratedDomain);
virQEMUCapsFormatHostCPUModelInfo(qemuCaps, &buf, VIR_DOMAIN_VIRT_QEMU);
virQEMUCapsFormatCPUModels(qemuCaps, &buf, acceleratedDomain);
virQEMUCapsFormatCPUModels(qemuCaps, &buf, VIR_DOMAIN_VIRT_QEMU);
Would that work for you?
--
Thank you,
Roman
10:15 p.m.
New subject: [libvirt] [PATCHv2 01/16] qemu: Add KVM CPUs into cache only if KVM is present
On Fri, Nov 23, 2018 at 09:46:36PM +0300, Roman Bolshakov wrote:
On Fri, Nov 23, 2018 at 06:16:46PM +0100, Jiri Denemark wrote:
> On Fri, Nov 23, 2018 at 18:55:00 +0300, Roman Bolshakov wrote:
> > On Fri, Nov 23, 2018 at 04:30:13PM +0100, Jiri Denemark wrote:
> > > On Fri, Nov 23, 2018 at 17:16:12 +0300, Roman Bolshakov wrote:
> > > > On Wed, Nov 21, 2018 at 07:43:43PM +0100, Jiri Denemark wrote:
> > > > > virQEMUCapsInitHostCPUModel always fills in something and your
check
> > > > > should probably remain in place for it
> > > > >
> > > > > virQEMUCapsFormatHostCPUModelInfo does
> > > > > virQEMUCapsHostCPUDataPtr cpuData =
&qemuCaps->kvmCPU;
> > > > > qemuMonitorCPUModelInfoPtr model = cpuData->info;
> > > > > if (!model)
> > > > > return;
> > > > >
> > > > > virQEMUCapsFormatCPUModels
> > > > > cpus = qemuCaps->kvmCPUModels;
> > > > > if (!cpus)
> > > > > return;
> > > > >
> > > > > So to me it looks like all functions are ready to see NULL
pointers and
> > > > > just do nothing if that's the case. Thus the only thing this
patch
> > > > > should need to do is to make sure virQEMUCapsInitHostCPUModel
does not
> > > > > set something non-NULL there.
> > > >
> > > > Unfortunately, that won't work for the patch series. kvmCPUModels
is renamed to
> > > > accelCPUModels and kvmCPU is renamed to accelCPU in PATCH 6.
> > >
> > > And how does different name change the behavior?
> > >
> > > > So, virQEMUCapsFormatHostCPUModelInfo looks like:
> > > > if (virQEMUCapsTypeIsAccelerated(type))
> > > > cpuData = qemuCaps->accelCPU;
> > > > else
> > > > cpuData = qemuCaps->tcgCPU;
> > > >
> > > > and virQEMUCapsFormatCPUModels looks like:
> > > > if (virQEMUCapsTypeIsAccelerated(type))
> > > > cpus = qemuCaps->accelCPUModels;
> > > > else
> > > > cpus = qemuCaps->tcgCPUModels;
> > > >
> > > > Without the check we'd return CPUs for KVM domain on the platform
that doesn't
> > > > support it.
> > >
> > > It won't return anything because the code will make sure
accelCPUModels
> > > and accelCPU will be NULL when no accel method is supported.
> >
> > But accelCPU is not NULL on macOS with QEMU_CAPS_HVF and on Linux with
> > QEMU_CAPS_KVM. That's where the problem arises.
>
> Right, and that's what I think should be changed. Rather then adding
> checks to the formatting and loading code to ignore something which
> shouldn't be present in the first place.
>
> > We're going to get additional kvm CPUs on mac and hvf CPUs on Linux
> > and that will break qemucapabilitiestest.
>
> I think I'm missing something here. There's only one CPU definition
> describing the host CPU. There are hosts which have several different
> CPUs, but libvirt is not really prepared to see that and I believe this
> is not what you're addressing with this series, is it? Or are you
> talking about some other CPUs?
>
> > In fact they will be the same accelCPUs of the supported accelerator
> > but with hostCPU's type attribute of the other accelerator.
>
> How would this happen? We have a single accelerator enabled on a host
> and we generate a host CPU model for it (and just for it, there's no
> reason to generate a CPU model for something that is not supported on
> the host).
>
accelCPU will be present on a host where an accelerator is avaialable.
You said can't have host CPU definitions present twice. I agree with
that. But if we call virQEMUCapsFormatCPUModels twice for
VIR_DOMAIN_VIRT_KVM and VIR_DOMAIN_VIRT_HVF without the checks, host cpu
definitions will be present twice for each accelerator because accelCPU
is not NULL.
So we need to call it only once for the supported accelerator.
The checks help in that. Alternative approach to do only one call is:
virDomainVirtType acceleratedDomain = VIR_DOMAIN_VIRT_KVM;
if (virQEMUCapsGet(qemuCaps, QEMU_CAPS_HVF))
acceleratedDomain = VIR_DOMAIN_VIRT_HVF;
virQEMUCapsFormatHostCPUModelInfo(qemuCaps, &buf, acceleratedDomain);
virQEMUCapsFormatHostCPUModelInfo(qemuCaps, &buf, VIR_DOMAIN_VIRT_QEMU);
virQEMUCapsFormatCPUModels(qemuCaps, &buf, acceleratedDomain);
virQEMUCapsFormatCPUModels(qemuCaps, &buf, VIR_DOMAIN_VIRT_QEMU);
Would that work for you?
--
Thank you,
Roman
Hi Jiri,
That's a kind reminder.
Thank you,
Roman
12:48 p.m.
New subject: [libvirt] [PATCHv2 01/16] qemu: Add KVM CPUs into cache only if KVM is present
First, I'd like to apologize for such a late reply.
...
> > > We're going to get additional kvm CPUs on mac and
hvf CPUs on Linux
> > > and that will break qemucapabilitiestest.
> >
> > I think I'm missing something here. There's only one CPU definition
> > describing the host CPU. There are hosts which have several different
> > CPUs, but libvirt is not really prepared to see that and I believe this
> > is not what you're addressing with this series, is it? Or are you
> > talking about some other CPUs?
> >
> > > In fact they will be the same accelCPUs of the supported accelerator
> > > but with hostCPU's type attribute of the other accelerator.
> >
> > How would this happen? We have a single accelerator enabled on a host
> > and we generate a host CPU model for it (and just for it, there's no
> > reason to generate a CPU model for something that is not supported on
> > the host).
> >
>
> accelCPU will be present on a host where an accelerator is avaialable.
> You said can't have host CPU definitions present twice. I agree with
> that. But if we call virQEMUCapsFormatCPUModels twice for
> VIR_DOMAIN_VIRT_KVM and VIR_DOMAIN_VIRT_HVF without the checks, host cpu
> definitions will be present twice for each accelerator because accelCPU
> is not NULL.
I see. I was thinking about several options. In general I think we
should keep the loader and formatter code as simple and stupid as
possible, we should not wire any fancy logic in them. Thus we have two
options:
First option:
> So we need to call it only once for the supported accelerator.
> The checks help in that. Alternative approach to do only one call is:
>
> virDomainVirtType acceleratedDomain = VIR_DOMAIN_VIRT_KVM;
> if (virQEMUCapsGet(qemuCaps, QEMU_CAPS_HVF))
> acceleratedDomain = VIR_DOMAIN_VIRT_HVF;
>
> virQEMUCapsFormatHostCPUModelInfo(qemuCaps, &buf, acceleratedDomain);
> virQEMUCapsFormatHostCPUModelInfo(qemuCaps, &buf, VIR_DOMAIN_VIRT_QEMU);
>
> virQEMUCapsFormatCPUModels(qemuCaps, &buf, acceleratedDomain);
> virQEMUCapsFormatCPUModels(qemuCaps, &buf, VIR_DOMAIN_VIRT_QEMU);
Or even using a dedicated enum instead of virDomainVirtType for
accessing the CPU data. Either way, the callers would need to contain
the extra code to request the data they want.
Second option: store CPU data separately for each virtType (qemu, kvm,
hvf), which would effectively add support for multiple accelerators on a
single host. While we don't currently need to support multiple
accelerators, I think this solution would be the cleanest one. It would
be pretty clear what data are stored in the cache and what the callers
want without having to copy paste some special handling for individual
accelerators. The formatting/loading code would just be called for all
three virtTypes unconditionally.
Thanks for the patience.
Jirka
3:01 p.m.
New subject: [libvirt] [PATCHv2 02/16] conf: Add hvf domain type
QEMU supports Hypervisor.framework since 2.12 as hvf accel.
Hypervisor.framework provides a lightweight interface to run a virtual
cpu on macOS without the need to install third-party kernel
extensions (KEXTs).
It's supported since macOS 10.10 on machines with Intel VT-x feature
set that includes Extended Page Tables (EPT) and Unrestricted Mode.
Signed-off-by: Roman Bolshakov <r.bolshakov(a)yadro.com>
---
docs/formatdomain.html.in | 8 ++++----
docs/schemas/domaincommon.rng | 1 +
src/conf/domain_conf.c | 4 +++-
src/conf/domain_conf.h | 1 +
src/qemu/qemu_command.c | 4 ++++
5 files changed, 13 insertions(+), 5 deletions(-)
diff --git a/docs/formatdomain.html.in b/docs/formatdomain.html.in
index 2af4960981..25dd4bbbd6 100644
--- a/docs/formatdomain.html.in
+++ b/docs/formatdomain.html.in
@@ -22,10 +22,10 @@
<a
id="attributeDomainType"><code>type</code></a>
specifies the hypervisor used for running
the domain. The allowed values are driver specific, but
- include "xen", "kvm", "qemu", "lxc" and
"kqemu". The
- second attribute is <code>id</code> which is a unique
- integer identifier for the running guest machine. Inactive
- machines have no id value.
+ include "xen", "kvm", "hvf" (<span
class="since">since 4.10.0 and QEMU
+ 2.12</span>), "qemu", "lxc" and "kqemu". The
second attribute is
+ <code>id</code> which is a unique integer identifier for the running
+ guest machine. Inactive machines have no id value.
</p>
diff --git a/docs/schemas/domaincommon.rng b/docs/schemas/domaincommon.rng
index 5ee727eefa..596e347eda 100644
--- a/docs/schemas/domaincommon.rng
+++ b/docs/schemas/domaincommon.rng
@@ -213,6 +213,7 @@
<value>phyp</value>
<value>vz</value>
<value>bhyve</value>
+ <value>hvf</value>
</choice>
</attribute>
</define>
diff --git a/src/conf/domain_conf.c b/src/conf/domain_conf.c
index 13874837c2..369d4bd634 100644
--- a/src/conf/domain_conf.c
+++ b/src/conf/domain_conf.c
@@ -119,7 +119,8 @@ VIR_ENUM_IMPL(virDomainVirt, VIR_DOMAIN_VIRT_LAST,
"phyp",
"parallels",
"bhyve",
- "vz")
+ "vz",
+ "hvf")
VIR_ENUM_IMPL(virDomainOS, VIR_DOMAIN_OSTYPE_LAST,
"hvm",
@@ -15024,6 +15025,7 @@ virDomainVideoDefaultType(const virDomainDef *def)
case VIR_DOMAIN_VIRT_HYPERV:
case VIR_DOMAIN_VIRT_PHYP:
case VIR_DOMAIN_VIRT_NONE:
+ case VIR_DOMAIN_VIRT_HVF:
case VIR_DOMAIN_VIRT_LAST:
default:
return VIR_DOMAIN_VIDEO_TYPE_DEFAULT;
diff --git a/src/conf/domain_conf.h b/src/conf/domain_conf.h
index 467785cd83..65f00692b7 100644
--- a/src/conf/domain_conf.h
+++ b/src/conf/domain_conf.h
@@ -245,6 +245,7 @@ typedef enum {
VIR_DOMAIN_VIRT_PARALLELS,
VIR_DOMAIN_VIRT_BHYVE,
VIR_DOMAIN_VIRT_VZ,
+ VIR_DOMAIN_VIRT_HVF,
VIR_DOMAIN_VIRT_LAST
} virDomainVirtType;
diff --git a/src/qemu/qemu_command.c b/src/qemu/qemu_command.c
index 23a6661c10..0fb796e15c 100644
--- a/src/qemu/qemu_command.c
+++ b/src/qemu/qemu_command.c
@@ -7251,6 +7251,10 @@ qemuBuildMachineCommandLine(virCommandPtr cmd,
virBufferAddLit(&buf, ",accel=kvm");
break;
+ case VIR_DOMAIN_VIRT_HVF:
+ virBufferAddLit(&buf, ",accel=hvf");
+ break;
+
case VIR_DOMAIN_VIRT_KQEMU:
case VIR_DOMAIN_VIRT_XEN:
case VIR_DOMAIN_VIRT_LXC:
--
2.19.1
3:01 p.m.
New subject: [libvirt] [PATCHv2 03/16] qemu: Define hvf capability
Signed-off-by: Roman Bolshakov <r.bolshakov(a)yadro.com>
---
src/qemu/qemu_capabilities.c | 1 +
src/qemu/qemu_capabilities.h | 1 +
2 files changed, 2 insertions(+)
diff --git a/src/qemu/qemu_capabilities.c b/src/qemu/qemu_capabilities.c
index 4ba8369e3a..0bbda80782 100644
--- a/src/qemu/qemu_capabilities.c
+++ b/src/qemu/qemu_capabilities.c
@@ -515,6 +515,7 @@ VIR_ENUM_IMPL(virQEMUCaps, QEMU_CAPS_LAST,
/* 320 */
"memory-backend-memfd.hugetlb",
"iothread.poll-max-ns",
+ "hvf",
);
diff --git a/src/qemu/qemu_capabilities.h b/src/qemu/qemu_capabilities.h
index c2caaf6fe1..7d08e8d243 100644
--- a/src/qemu/qemu_capabilities.h
+++ b/src/qemu/qemu_capabilities.h
@@ -499,6 +499,7 @@ typedef enum { /* virQEMUCapsFlags grouping marker for syntax-check
*/
/* 320 */
QEMU_CAPS_OBJECT_MEMORY_MEMFD_HUGETLB, /* -object memory-backend-memfd.hugetlb */
QEMU_CAPS_IOTHREAD_POLLING, /* -object iothread.poll-max-ns */
+ QEMU_CAPS_HVF, /* Whether Hypervisor.framework is available */
QEMU_CAPS_LAST /* this must always be the last item */
} virQEMUCapsFlags;
--
2.19.1
3:01 p.m.
New subject: [libvirt] [PATCHv2 04/16] qemu: Query hvf capability on macOS
There's no QMP command for querying if hvf is supported, therefore we
use sysctl interface that tells if Hypervisor.framwork works/available
on the host.
Signed-off-by: Roman Bolshakov <r.bolshakov(a)yadro.com>
---
src/qemu/qemu_capabilities.c | 34 ++++++++++++++++++++++++++++++++++
1 file changed, 34 insertions(+)
diff --git a/src/qemu/qemu_capabilities.c b/src/qemu/qemu_capabilities.c
index 0bbda80782..5ebe3f1afe 100644
--- a/src/qemu/qemu_capabilities.c
+++ b/src/qemu/qemu_capabilities.c
@@ -54,6 +54,10 @@
#include <sys/wait.h>
#include <stdarg.h>
#include <sys/utsname.h>
+#ifdef __APPLE__
+# include <sys/types.h>
+# include <sys/sysctl.h>
+#endif
#define VIR_FROM_THIS VIR_FROM_QEMU
@@ -2599,6 +2603,33 @@ virQEMUCapsProbeQMPKVMState(virQEMUCapsPtr qemuCaps,
return 0;
}
+#ifdef __APPLE__
+static int
+virQEMUCapsProbeHVF(virQEMUCapsPtr qemuCaps)
+{
+ int hv_support;
+ size_t len = sizeof(hv_support);
+ if (sysctlbyname("kern.hv_support", &hv_support, &len, NULL, 0))
+ hv_support = 0;
+
+ if (qemuCaps->version >= 2012000 &&
+ ARCH_IS_X86(qemuCaps->arch) &&
+ hv_support) {
+ virQEMUCapsSet(qemuCaps, QEMU_CAPS_HVF);
+ }
+
+ return 0;
+}
+#else
+static int
+virQEMUCapsProbeHVF(virQEMUCapsPtr qemuCaps)
+{
+ (void) qemuCaps;
+
+ return 0;
+}
+#endif
+
struct virQEMUCapsCommandLineProps {
const char *option;
const char *param;
@@ -4150,6 +4181,9 @@ virQEMUCapsInitQMPMonitor(virQEMUCapsPtr qemuCaps,
if (virQEMUCapsProbeQMPKVMState(qemuCaps, mon) < 0)
goto cleanup;
+ if (virQEMUCapsProbeHVF(qemuCaps) < 0)
+ goto cleanup;
+
if (virQEMUCapsProbeQMPEvents(qemuCaps, mon) < 0)
goto cleanup;
if (virQEMUCapsProbeQMPDevices(qemuCaps, mon) < 0)
--
2.19.1
3:01 p.m.
New subject: [libvirt] [PATCHv2 05/16] qemu: Expose hvf domain type if hvf is supported
Signed-off-by: Roman Bolshakov <r.bolshakov(a)yadro.com>
Reviewed-by: Daniel P. Berrangé <berrange(a)redhat.com>
---
src/qemu/qemu_capabilities.c | 11 +++++++++++
1 file changed, 11 insertions(+)
diff --git a/src/qemu/qemu_capabilities.c b/src/qemu/qemu_capabilities.c
index 5ebe3f1afe..645ce2c89e 100644
--- a/src/qemu/qemu_capabilities.c
+++ b/src/qemu/qemu_capabilities.c
@@ -859,6 +859,17 @@ virQEMUCapsInitGuestFromBinary(virCapsPtr caps,
}
}
+ if (virQEMUCapsGet(qemuCaps, QEMU_CAPS_HVF)) {
+ if (virCapabilitiesAddGuestDomain(guest,
+ VIR_DOMAIN_VIRT_HVF,
+ NULL,
+ NULL,
+ 0,
+ NULL) == NULL) {
+ goto cleanup;
+ }
+ }
+
if ((ARCH_IS_X86(guestarch) || guestarch == VIR_ARCH_AARCH64) &&
virCapabilitiesAddGuestFeature(guest, "acpi", true, true) == NULL) {
goto cleanup;
--
2.19.1
3:01 p.m.
New subject: [libvirt] [PATCHv2 06/16] qemu: Rename kvmCPU to accelCPU
QEMU supports a number of accelerators. It'd be good to have more
generic name for kvmCPUModels and kvmCPU.
Signed-off-by: Roman Bolshakov <r.bolshakov(a)yadro.com>
---
src/qemu/qemu_capabilities.c | 36 ++++++++++++++++++------------------
1 file changed, 18 insertions(+), 18 deletions(-)
diff --git a/src/qemu/qemu_capabilities.c b/src/qemu/qemu_capabilities.c
index 645ce2c89e..ad15d2853e 100644
--- a/src/qemu/qemu_capabilities.c
+++ b/src/qemu/qemu_capabilities.c
@@ -578,7 +578,7 @@ struct _virQEMUCaps {
virArch arch;
- virDomainCapsCPUModelsPtr kvmCPUModels;
+ virDomainCapsCPUModelsPtr accelCPUModels;
virDomainCapsCPUModelsPtr tcgCPUModels;
size_t nmachineTypes;
@@ -589,7 +589,7 @@ struct _virQEMUCaps {
virSEVCapability *sevCapabilities;
- virQEMUCapsHostCPUData kvmCPU;
+ virQEMUCapsHostCPUData accelCPU;
virQEMUCapsHostCPUData tcgCPU;
};
@@ -1564,9 +1564,9 @@ virQEMUCapsPtr virQEMUCapsNewCopy(virQEMUCapsPtr qemuCaps)
ret->arch = qemuCaps->arch;
- if (qemuCaps->kvmCPUModels) {
- ret->kvmCPUModels = virDomainCapsCPUModelsCopy(qemuCaps->kvmCPUModels);
- if (!ret->kvmCPUModels)
+ if (qemuCaps->accelCPUModels) {
+ ret->accelCPUModels =
virDomainCapsCPUModelsCopy(qemuCaps->accelCPUModels);
+ if (!ret->accelCPUModels)
goto error;
}
@@ -1576,7 +1576,7 @@ virQEMUCapsPtr virQEMUCapsNewCopy(virQEMUCapsPtr qemuCaps)
goto error;
}
- if (virQEMUCapsHostCPUDataCopy(&ret->kvmCPU, &qemuCaps->kvmCPU) < 0
||
+ if (virQEMUCapsHostCPUDataCopy(&ret->accelCPU, &qemuCaps->accelCPU)
< 0 ||
virQEMUCapsHostCPUDataCopy(&ret->tcgCPU, &qemuCaps->tcgCPU) <
0)
goto error;
@@ -1623,7 +1623,7 @@ void virQEMUCapsDispose(void *obj)
}
VIR_FREE(qemuCaps->machineTypes);
- virObjectUnref(qemuCaps->kvmCPUModels);
+ virObjectUnref(qemuCaps->accelCPUModels);
virObjectUnref(qemuCaps->tcgCPUModels);
virBitmapFree(qemuCaps->flags);
@@ -1636,7 +1636,7 @@ void virQEMUCapsDispose(void *obj)
virSEVCapabilitiesFree(qemuCaps->sevCapabilities);
- virQEMUCapsHostCPUDataClear(&qemuCaps->kvmCPU);
+ virQEMUCapsHostCPUDataClear(&qemuCaps->accelCPU);
virQEMUCapsHostCPUDataClear(&qemuCaps->tcgCPU);
}
@@ -1794,8 +1794,8 @@ virQEMUCapsAddCPUDefinitions(virQEMUCapsPtr qemuCaps,
size_t i;
virDomainCapsCPUModelsPtr cpus = NULL;
- if (type == VIR_DOMAIN_VIRT_KVM && qemuCaps->kvmCPUModels)
- cpus = qemuCaps->kvmCPUModels;
+ if (type == VIR_DOMAIN_VIRT_KVM && qemuCaps->accelCPUModels)
+ cpus = qemuCaps->accelCPUModels;
else if (type == VIR_DOMAIN_VIRT_QEMU && qemuCaps->tcgCPUModels)
cpus = qemuCaps->tcgCPUModels;
@@ -1804,7 +1804,7 @@ virQEMUCapsAddCPUDefinitions(virQEMUCapsPtr qemuCaps,
return -1;
if (type == VIR_DOMAIN_VIRT_KVM)
- qemuCaps->kvmCPUModels = cpus;
+ qemuCaps->accelCPUModels = cpus;
else
qemuCaps->tcgCPUModels = cpus;
}
@@ -1823,7 +1823,7 @@ virQEMUCapsGetCPUDefinitions(virQEMUCapsPtr qemuCaps,
virDomainVirtType type)
{
if (type == VIR_DOMAIN_VIRT_KVM)
- return qemuCaps->kvmCPUModels;
+ return qemuCaps->accelCPUModels;
else
return qemuCaps->tcgCPUModels;
}
@@ -1834,7 +1834,7 @@ virQEMUCapsGetHostCPUData(virQEMUCapsPtr qemuCaps,
virDomainVirtType type)
{
if (type == VIR_DOMAIN_VIRT_KVM)
- return &qemuCaps->kvmCPU;
+ return &qemuCaps->accelCPU;
else
return &qemuCaps->tcgCPU;
}
@@ -1898,7 +1898,7 @@ virQEMUCapsIsCPUModeSupported(virQEMUCapsPtr qemuCaps,
case VIR_CPU_MODE_CUSTOM:
if (type == VIR_DOMAIN_VIRT_KVM)
- cpus = qemuCaps->kvmCPUModels;
+ cpus = qemuCaps->accelCPUModels;
else
cpus = qemuCaps->tcgCPUModels;
return cpus && cpus->nmodels > 0;
@@ -2385,7 +2385,7 @@ virQEMUCapsProbeQMPCPUDefinitions(virQEMUCapsPtr qemuCaps,
if (tcg || !virQEMUCapsGet(qemuCaps, QEMU_CAPS_KVM))
qemuCaps->tcgCPUModels = models;
else
- qemuCaps->kvmCPUModels = models;
+ qemuCaps->accelCPUModels = models;
return 0;
}
@@ -3232,7 +3232,7 @@ virQEMUCapsLoadCPUModels(virQEMUCapsPtr qemuCaps,
goto cleanup;
if (type == VIR_DOMAIN_VIRT_KVM)
- qemuCaps->kvmCPUModels = cpus;
+ qemuCaps->accelCPUModels = cpus;
else
qemuCaps->tcgCPUModels = cpus;
@@ -3710,7 +3710,7 @@ virQEMUCapsFormatCPUModels(virQEMUCapsPtr qemuCaps,
if (type == VIR_DOMAIN_VIRT_KVM) {
typeStr = "kvm";
- cpus = qemuCaps->kvmCPUModels;
+ cpus = qemuCaps->accelCPUModels;
} else {
typeStr = "tcg";
cpus = qemuCaps->tcgCPUModels;
@@ -5107,7 +5107,7 @@ virQEMUCapsFillDomainCPUCaps(virCapsPtr caps,
virDomainCapsCPUModelsPtr cpus;
if (domCaps->virttype == VIR_DOMAIN_VIRT_KVM)
- cpus = qemuCaps->kvmCPUModels;
+ cpus = qemuCaps->accelCPUModels;
else
cpus = qemuCaps->tcgCPUModels;
--
2.19.1
3:01 p.m.
New subject: [libvirt] [PATCHv2 07/16] qemu: Introduce virQEMUCapsTypeIsAccelerated
It replaces hardcoded checks that select accelCPU/accelCPUModels
(formerly known as kvmCPU/kvmCPUModels) for KVM. It'll be cleaner to use
the function when multiple accelerators are supported in qemu driver.
Explicit KVM domain checks should be done only when a feature is
available only for KVM.
Signed-off-by: Roman Bolshakov <r.bolshakov(a)yadro.com>
---
src/qemu/qemu_capabilities.c | 28 +++++++++++++++++-----------
1 file changed, 17 insertions(+), 11 deletions(-)
diff --git a/src/qemu/qemu_capabilities.c b/src/qemu/qemu_capabilities.c
index ad15d2853e..e302fbb48f 100644
--- a/src/qemu/qemu_capabilities.c
+++ b/src/qemu/qemu_capabilities.c
@@ -637,6 +637,11 @@ static const char *virQEMUCapsArchToString(virArch arch)
return virArchToString(arch);
}
+static bool
+virQEMUCapsTypeIsAccelerated(virDomainVirtType type)
+{
+ return type == VIR_DOMAIN_VIRT_KVM;
+}
/* Checks whether a domain with @guest arch can run natively on @host.
*/
@@ -1794,7 +1799,7 @@ virQEMUCapsAddCPUDefinitions(virQEMUCapsPtr qemuCaps,
size_t i;
virDomainCapsCPUModelsPtr cpus = NULL;
- if (type == VIR_DOMAIN_VIRT_KVM && qemuCaps->accelCPUModels)
+ if (virQEMUCapsTypeIsAccelerated(type) && qemuCaps->accelCPUModels)
cpus = qemuCaps->accelCPUModels;
else if (type == VIR_DOMAIN_VIRT_QEMU && qemuCaps->tcgCPUModels)
cpus = qemuCaps->tcgCPUModels;
@@ -1803,7 +1808,7 @@ virQEMUCapsAddCPUDefinitions(virQEMUCapsPtr qemuCaps,
if (!(cpus = virDomainCapsCPUModelsNew(count)))
return -1;
- if (type == VIR_DOMAIN_VIRT_KVM)
+ if (virQEMUCapsTypeIsAccelerated(type))
qemuCaps->accelCPUModels = cpus;
else
qemuCaps->tcgCPUModels = cpus;
@@ -1822,7 +1827,7 @@ virDomainCapsCPUModelsPtr
virQEMUCapsGetCPUDefinitions(virQEMUCapsPtr qemuCaps,
virDomainVirtType type)
{
- if (type == VIR_DOMAIN_VIRT_KVM)
+ if (virQEMUCapsTypeIsAccelerated(type))
return qemuCaps->accelCPUModels;
else
return qemuCaps->tcgCPUModels;
@@ -1833,7 +1838,7 @@ static virQEMUCapsHostCPUDataPtr
virQEMUCapsGetHostCPUData(virQEMUCapsPtr qemuCaps,
virDomainVirtType type)
{
- if (type == VIR_DOMAIN_VIRT_KVM)
+ if (virQEMUCapsTypeIsAccelerated(type))
return &qemuCaps->accelCPU;
else
return &qemuCaps->tcgCPU;
@@ -1889,7 +1894,7 @@ virQEMUCapsIsCPUModeSupported(virQEMUCapsPtr qemuCaps,
switch (mode) {
case VIR_CPU_MODE_HOST_PASSTHROUGH:
- return type == VIR_DOMAIN_VIRT_KVM &&
+ return virQEMUCapsTypeIsAccelerated(type) &&
virQEMUCapsGuestIsNative(caps->host.arch, qemuCaps->arch);
case VIR_CPU_MODE_HOST_MODEL:
@@ -1897,7 +1902,7 @@ virQEMUCapsIsCPUModeSupported(virQEMUCapsPtr qemuCaps,
VIR_QEMU_CAPS_HOST_CPU_REPORTED);
case VIR_CPU_MODE_CUSTOM:
- if (type == VIR_DOMAIN_VIRT_KVM)
+ if (virQEMUCapsTypeIsAccelerated(type))
cpus = qemuCaps->accelCPUModels;
else
cpus = qemuCaps->tcgCPUModels;
@@ -3004,7 +3009,7 @@ virQEMUCapsInitHostCPUModel(virQEMUCapsPtr qemuCaps,
virArchToString(qemuCaps->arch),
virDomainVirtTypeToString(type));
goto error;
- } else if (type == VIR_DOMAIN_VIRT_KVM &&
+ } else if (virQEMUCapsTypeIsAccelerated(type) &&
virCPUGetHostIsSupported(qemuCaps->arch)) {
if (!(fullCPU = virCPUGetHost(qemuCaps->arch, VIR_CPU_TYPE_GUEST,
NULL, NULL)))
@@ -3231,7 +3236,7 @@ virQEMUCapsLoadCPUModels(virQEMUCapsPtr qemuCaps,
if (!(cpus = virDomainCapsCPUModelsNew(n)))
goto cleanup;
- if (type == VIR_DOMAIN_VIRT_KVM)
+ if (virQEMUCapsTypeIsAccelerated(type))
qemuCaps->accelCPUModels = cpus;
else
qemuCaps->tcgCPUModels = cpus;
@@ -3708,7 +3713,7 @@ virQEMUCapsFormatCPUModels(virQEMUCapsPtr qemuCaps,
const char *typeStr;
size_t i;
- if (type == VIR_DOMAIN_VIRT_KVM) {
+ if (virQEMUCapsTypeIsAccelerated(type)) {
typeStr = "kvm";
cpus = qemuCaps->accelCPUModels;
} else {
@@ -4966,7 +4971,8 @@ virQEMUCapsCacheLookupDefault(virFileCachePtr cache,
if (virttype == VIR_DOMAIN_VIRT_NONE)
virttype = capsType;
- if (virttype == VIR_DOMAIN_VIRT_KVM && capsType == VIR_DOMAIN_VIRT_QEMU) {
+ if (virQEMUCapsTypeIsAccelerated(virttype) &&
+ !virQEMUCapsTypeIsAccelerated(capsType)) {
virReportError(VIR_ERR_INVALID_ARG,
_("KVM is not supported by '%s' on this host"),
binary);
@@ -5106,7 +5112,7 @@ virQEMUCapsFillDomainCPUCaps(virCapsPtr caps,
if (virCPUGetModels(domCaps->arch, &models) >= 0) {
virDomainCapsCPUModelsPtr cpus;
- if (domCaps->virttype == VIR_DOMAIN_VIRT_KVM)
+ if (virQEMUCapsTypeIsAccelerated(domCaps->virttype))
cpus = qemuCaps->accelCPUModels;
else
cpus = qemuCaps->tcgCPUModels;
--
2.19.1
3:27 p.m.
New subject: [libvirt] [PATCHv2 07/16] qemu: Introduce virQEMUCapsTypeIsAccelerated
On Wednesday, 21 November 2018 15:01:50 CET Roman Bolshakov wrote:
+static bool
+virQEMUCapsTypeIsAccelerated(virDomainVirtType type)
+{
+ return type == VIR_DOMAIN_VIRT_KVM;
+}
[...]
@@ -4966,7 +4971,8 @@ virQEMUCapsCacheLookupDefault(virFileCachePtr cache,
if (virttype == VIR_DOMAIN_VIRT_NONE)
virttype = capsType;
- if (virttype == VIR_DOMAIN_VIRT_KVM && capsType == VIR_DOMAIN_VIRT_QEMU) {
+ if (virQEMUCapsTypeIsAccelerated(virttype) &&
+ !virQEMUCapsTypeIsAccelerated(capsType)) {
virReportError(VIR_ERR_INVALID_ARG,
_("KVM is not supported by '%s' on this
host"),
binary);
From what I see, this check is now different:
- "capsType
== VIR_DOMAIN_VIRT_QEMU" will be true only when capsType is
VIR_DOMAIN_VIRT_QEMU
- !virQEMUCapsTypeIsAccelerated(capsType) will be true when capsType is
not VIR_DOMAIN_VIRT_KVM
--
Pino Toscano
4:12 p.m.
New subject: [libvirt] [PATCHv2 07/16] qemu: Introduce virQEMUCapsTypeIsAccelerated
On Fri, Nov 23, 2018 at 03:27:50PM +0100, Pino Toscano wrote:
On Wednesday, 21 November 2018 15:01:50 CET Roman Bolshakov wrote:
> +static bool
> +virQEMUCapsTypeIsAccelerated(virDomainVirtType type)
> +{
> + return type == VIR_DOMAIN_VIRT_KVM;
> +}
> [...]
> @@ -4966,7 +4971,8 @@ virQEMUCapsCacheLookupDefault(virFileCachePtr cache,
> if (virttype == VIR_DOMAIN_VIRT_NONE)
> virttype = capsType;
>
> - if (virttype == VIR_DOMAIN_VIRT_KVM && capsType ==
VIR_DOMAIN_VIRT_QEMU) {
> + if (virQEMUCapsTypeIsAccelerated(virttype) &&
> + !virQEMUCapsTypeIsAccelerated(capsType)) {
> virReportError(VIR_ERR_INVALID_ARG,
> _("KVM is not supported by '%s' on this
host"),
> binary);
From what I see, this check is now different:
- "capsType == VIR_DOMAIN_VIRT_QEMU" will be true only when capsType is
VIR_DOMAIN_VIRT_QEMU
- !virQEMUCapsTypeIsAccelerated(capsType) will be true when capsType is
not VIR_DOMAIN_VIRT_KVM
Hi Pino,
Yep, sure I can leave the 'capsType == VIR_DOMAIN_VIRT_QEMU' as is.
Thank you,
Roman
3:01 p.m.
New subject: [libvirt] [PATCHv2 08/16] qemu: Introduce virQEMUCapsHaveAccel
The function should be used to check if qemu capabilities include a
hardware acceleration, i.e. accel is not TCG.
Signed-off-by: Roman Bolshakov <r.bolshakov(a)yadro.com>
---
src/qemu/qemu_capabilities.c | 12 +++++++++---
1 file changed, 9 insertions(+), 3 deletions(-)
diff --git a/src/qemu/qemu_capabilities.c b/src/qemu/qemu_capabilities.c
index e302fbb48f..f80ee62019 100644
--- a/src/qemu/qemu_capabilities.c
+++ b/src/qemu/qemu_capabilities.c
@@ -643,6 +643,12 @@ virQEMUCapsTypeIsAccelerated(virDomainVirtType type)
return type == VIR_DOMAIN_VIRT_KVM;
}
+static bool
+virQEMUCapsHaveAccel(virQEMUCapsPtr qemuCaps)
+{
+ return virQEMUCapsGet(qemuCaps, QEMU_CAPS_KVM);
+}
+
/* Checks whether a domain with @guest arch can run natively on @host.
*/
bool
@@ -2387,7 +2393,7 @@ virQEMUCapsProbeQMPCPUDefinitions(virQEMUCapsPtr qemuCaps,
if (!(models = virQEMUCapsFetchCPUDefinitions(mon)))
return -1;
- if (tcg || !virQEMUCapsGet(qemuCaps, QEMU_CAPS_KVM))
+ if (tcg || !virQEMUCapsHaveAccel(qemuCaps))
qemuCaps->tcgCPUModels = models;
else
qemuCaps->accelCPUModels = models;
@@ -2413,7 +2419,7 @@ virQEMUCapsProbeQMPHostCPU(virQEMUCapsPtr qemuCaps,
if (!virQEMUCapsGet(qemuCaps, QEMU_CAPS_QUERY_CPU_MODEL_EXPANSION))
return 0;
- if (tcg || !virQEMUCapsGet(qemuCaps, QEMU_CAPS_KVM)) {
+ if (tcg || !virQEMUCapsHaveAccel(qemuCaps)) {
virtType = VIR_DOMAIN_VIRT_QEMU;
model = "max";
} else {
@@ -4528,7 +4534,7 @@ virQEMUCapsInitQMP(virQEMUCapsPtr qemuCaps,
if (virQEMUCapsInitQMPMonitor(qemuCaps, cmd->mon) < 0)
goto cleanup;
- if (virQEMUCapsGet(qemuCaps, QEMU_CAPS_KVM)) {
+ if (virQEMUCapsHaveAccel(qemuCaps)) {
virQEMUCapsInitQMPCommandAbort(cmd);
if ((rc = virQEMUCapsInitQMPCommandRun(cmd, true)) != 0) {
if (rc == 1)
--
2.19.1
3:01 p.m.
New subject: [libvirt] [PATCHv2 09/16] qemu: Introduce virQEMUCapsToVirtType
The function is needed to support multiple accelerators without
cluttering codebase by conditionals.
At the first glance that might cause an issue related to the ordering
capabilities being checked on a system with many accelerators but in the
current code base it should be just fine because
virQEMUCapsGetHostCPUData is not interested in the exact type of
accelarator.
Signed-off-by: Roman Bolshakov <r.bolshakov(a)yadro.com>
---
src/qemu/qemu_capabilities.c | 16 +++++++++++-----
1 file changed, 11 insertions(+), 5 deletions(-)
diff --git a/src/qemu/qemu_capabilities.c b/src/qemu/qemu_capabilities.c
index f80ee62019..1c6b79594d 100644
--- a/src/qemu/qemu_capabilities.c
+++ b/src/qemu/qemu_capabilities.c
@@ -649,6 +649,15 @@ virQEMUCapsHaveAccel(virQEMUCapsPtr qemuCaps)
return virQEMUCapsGet(qemuCaps, QEMU_CAPS_KVM);
}
+static virDomainVirtType
+virQEMUCapsToVirtType(virQEMUCapsPtr qemuCaps)
+{
+ if (virQEMUCapsGet(qemuCaps, QEMU_CAPS_KVM))
+ return VIR_DOMAIN_VIRT_KVM;
+ else
+ return VIR_DOMAIN_VIRT_QEMU;
+}
+
/* Checks whether a domain with @guest arch can run natively on @host.
*/
bool
@@ -2423,7 +2432,7 @@ virQEMUCapsProbeQMPHostCPU(virQEMUCapsPtr qemuCaps,
virtType = VIR_DOMAIN_VIRT_QEMU;
model = "max";
} else {
- virtType = VIR_DOMAIN_VIRT_KVM;
+ virtType = virQEMUCapsToVirtType(qemuCaps);
model = "host";
}
@@ -4969,10 +4978,7 @@ virQEMUCapsCacheLookupDefault(virFileCachePtr cache,
machine = virQEMUCapsGetPreferredMachine(qemuCaps);
}
- if (virQEMUCapsGet(qemuCaps, QEMU_CAPS_KVM))
- capsType = VIR_DOMAIN_VIRT_KVM;
- else
- capsType = VIR_DOMAIN_VIRT_QEMU;
+ capsType = virQEMUCapsToVirtType(qemuCaps);
if (virttype == VIR_DOMAIN_VIRT_NONE)
virttype = capsType;
--
2.19.1
3:01 p.m.
New subject: [libvirt] [PATCHv2 10/16] qemu: Introduce virQEMUCapsAccelStr
This makes possible to add more accelerators by touching less code and
reduces code duplication.
Signed-off-by: Roman Bolshakov <r.bolshakov(a)yadro.com>
---
src/qemu/qemu_capabilities.c | 21 ++++++++++++++-------
1 file changed, 14 insertions(+), 7 deletions(-)
diff --git a/src/qemu/qemu_capabilities.c b/src/qemu/qemu_capabilities.c
index 1c6b79594d..1cee9a833b 100644
--- a/src/qemu/qemu_capabilities.c
+++ b/src/qemu/qemu_capabilities.c
@@ -658,6 +658,16 @@ virQEMUCapsToVirtType(virQEMUCapsPtr qemuCaps)
return VIR_DOMAIN_VIRT_QEMU;
}
+static const char *
+virQEMUCapsAccelStr(virDomainVirtType type)
+{
+ if (type == VIR_DOMAIN_VIRT_KVM) {
+ return "kvm";
+ } else {
+ return "tcg";
+ }
+}
+
/* Checks whether a domain with @guest arch can run natively on @host.
*/
bool
@@ -3670,7 +3680,7 @@ virQEMUCapsFormatHostCPUModelInfo(virQEMUCapsPtr qemuCaps,
{
virQEMUCapsHostCPUDataPtr cpuData = virQEMUCapsGetHostCPUData(qemuCaps, type);
qemuMonitorCPUModelInfoPtr model = cpuData->info;
- const char *typeStr = type == VIR_DOMAIN_VIRT_KVM ? "kvm" :
"tcg";
+ const char *typeStr = virQEMUCapsAccelStr(type);
size_t i;
if (!model)
@@ -3725,16 +3735,13 @@ virQEMUCapsFormatCPUModels(virQEMUCapsPtr qemuCaps,
virDomainVirtType type)
{
virDomainCapsCPUModelsPtr cpus;
- const char *typeStr;
+ const char *typeStr = virQEMUCapsAccelStr(type);
size_t i;
- if (virQEMUCapsTypeIsAccelerated(type)) {
- typeStr = "kvm";
+ if (virQEMUCapsTypeIsAccelerated(type))
cpus = qemuCaps->accelCPUModels;
- } else {
- typeStr = "tcg";
+ else
cpus = qemuCaps->tcgCPUModels;
- }
if (!cpus)
return;
--
2.19.1
3:01 p.m.
New subject: [libvirt] [PATCHv2 11/16] qemu: Make error message accel-agnostic
With more acceleration types, KVM should be used only in error messages
related to KVM.
Signed-off-by: Roman Bolshakov <r.bolshakov(a)yadro.com>
---
src/qemu/qemu_capabilities.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/qemu/qemu_capabilities.c b/src/qemu/qemu_capabilities.c
index 1cee9a833b..8a1fb2b5d9 100644
--- a/src/qemu/qemu_capabilities.c
+++ b/src/qemu/qemu_capabilities.c
@@ -4993,8 +4993,8 @@ virQEMUCapsCacheLookupDefault(virFileCachePtr cache,
if (virQEMUCapsTypeIsAccelerated(virttype) &&
!virQEMUCapsTypeIsAccelerated(capsType)) {
virReportError(VIR_ERR_INVALID_ARG,
- _("KVM is not supported by '%s' on this host"),
- binary);
+ _("the accel '%s' is not supported by '%s' on
this host"),
+ virQEMUCapsAccelStr(virttype), binary);
goto cleanup;
}
--
2.19.1
3:01 p.m.
New subject: [libvirt] [PATCHv2 12/16] qemu: Correct CPU capabilities probing for hvf
With this change virsh domcapabilites shows:
<mode name='host-passthrough' supported='yes'/>
Signed-off-by: Roman Bolshakov <r.bolshakov(a)yadro.com>
Reviewed-by: Daniel P. Berrangé <berrange(a)redhat.com>
---
src/qemu/qemu_capabilities.c | 28 +++++++++++++++++++++++++---
1 file changed, 25 insertions(+), 3 deletions(-)
diff --git a/src/qemu/qemu_capabilities.c b/src/qemu/qemu_capabilities.c
index 8a1fb2b5d9..4297a11b27 100644
--- a/src/qemu/qemu_capabilities.c
+++ b/src/qemu/qemu_capabilities.c
@@ -640,13 +640,15 @@ static const char *virQEMUCapsArchToString(virArch arch)
static bool
virQEMUCapsTypeIsAccelerated(virDomainVirtType type)
{
- return type == VIR_DOMAIN_VIRT_KVM;
+ return type == VIR_DOMAIN_VIRT_KVM ||
+ type == VIR_DOMAIN_VIRT_HVF;
}
static bool
virQEMUCapsHaveAccel(virQEMUCapsPtr qemuCaps)
{
- return virQEMUCapsGet(qemuCaps, QEMU_CAPS_KVM);
+ return virQEMUCapsGet(qemuCaps, QEMU_CAPS_KVM) ||
+ virQEMUCapsGet(qemuCaps, QEMU_CAPS_HVF);
}
static virDomainVirtType
@@ -654,6 +656,8 @@ virQEMUCapsToVirtType(virQEMUCapsPtr qemuCaps)
{
if (virQEMUCapsGet(qemuCaps, QEMU_CAPS_KVM))
return VIR_DOMAIN_VIRT_KVM;
+ else if (virQEMUCapsGet(qemuCaps, QEMU_CAPS_HVF))
+ return VIR_DOMAIN_VIRT_HVF;
else
return VIR_DOMAIN_VIRT_QEMU;
}
@@ -663,6 +667,8 @@ virQEMUCapsAccelStr(virDomainVirtType type)
{
if (type == VIR_DOMAIN_VIRT_KVM) {
return "kvm";
+ } else if (type == VIR_DOMAIN_VIRT_HVF) {
+ return "hvf";
} else {
return "tcg";
}
@@ -3109,6 +3115,8 @@ virQEMUCapsLoadHostCPUModelInfo(virQEMUCapsPtr qemuCaps,
if (virtType == VIR_DOMAIN_VIRT_KVM)
hostCPUNode = virXPathNode("./hostCPU[@type='kvm']", ctxt);
+ else if (virtType == VIR_DOMAIN_VIRT_HVF)
+ hostCPUNode = virXPathNode("./hostCPU[@type='hvf']", ctxt);
else
hostCPUNode = virXPathNode("./hostCPU[@type='tcg']", ctxt);
@@ -3244,6 +3252,8 @@ virQEMUCapsLoadCPUModels(virQEMUCapsPtr qemuCaps,
if (type == VIR_DOMAIN_VIRT_KVM)
n = virXPathNodeSet("./cpu[@type='kvm']", ctxt, &nodes);
+ else if (type == VIR_DOMAIN_VIRT_HVF)
+ n = virXPathNodeSet("./cpu[@type='hvf']", ctxt, &nodes);
else
n = virXPathNodeSet("./cpu[@type='tcg']", ctxt, &nodes);
@@ -3542,11 +3552,15 @@ virQEMUCapsLoadCache(virArch hostArch,
if ((virQEMUCapsGet(qemuCaps, QEMU_CAPS_KVM) &&
virQEMUCapsLoadHostCPUModelInfo(qemuCaps, ctxt, VIR_DOMAIN_VIRT_KVM) < 0) ||
+ (virQEMUCapsGet(qemuCaps, QEMU_CAPS_HVF) &&
+ virQEMUCapsLoadHostCPUModelInfo(qemuCaps, ctxt, VIR_DOMAIN_VIRT_HVF) < 0) ||
virQEMUCapsLoadHostCPUModelInfo(qemuCaps, ctxt, VIR_DOMAIN_VIRT_QEMU) < 0)
goto cleanup;
if ((virQEMUCapsGet(qemuCaps, QEMU_CAPS_KVM) &&
virQEMUCapsLoadCPUModels(qemuCaps, ctxt, VIR_DOMAIN_VIRT_KVM) < 0) ||
+ (virQEMUCapsGet(qemuCaps, QEMU_CAPS_HVF) &&
+ virQEMUCapsLoadCPUModels(qemuCaps, ctxt, VIR_DOMAIN_VIRT_HVF) < 0) ||
virQEMUCapsLoadCPUModels(qemuCaps, ctxt, VIR_DOMAIN_VIRT_QEMU) < 0)
goto cleanup;
@@ -3661,6 +3675,8 @@ virQEMUCapsLoadCache(virArch hostArch,
if (virQEMUCapsGet(qemuCaps, QEMU_CAPS_KVM))
virQEMUCapsInitHostCPUModel(qemuCaps, hostArch, VIR_DOMAIN_VIRT_KVM);
+ if (virQEMUCapsGet(qemuCaps, QEMU_CAPS_HVF))
+ virQEMUCapsInitHostCPUModel(qemuCaps, hostArch, VIR_DOMAIN_VIRT_HVF);
virQEMUCapsInitHostCPUModel(qemuCaps, hostArch, VIR_DOMAIN_VIRT_QEMU);
ret = 0;
@@ -3841,10 +3857,14 @@ virQEMUCapsFormatCache(virQEMUCapsPtr qemuCaps)
if (virQEMUCapsGet(qemuCaps, QEMU_CAPS_KVM))
virQEMUCapsFormatHostCPUModelInfo(qemuCaps, &buf, VIR_DOMAIN_VIRT_KVM);
+ if (virQEMUCapsGet(qemuCaps, QEMU_CAPS_HVF))
+ virQEMUCapsFormatHostCPUModelInfo(qemuCaps, &buf, VIR_DOMAIN_VIRT_HVF);
virQEMUCapsFormatHostCPUModelInfo(qemuCaps, &buf, VIR_DOMAIN_VIRT_QEMU);
if (virQEMUCapsGet(qemuCaps, QEMU_CAPS_KVM))
virQEMUCapsFormatCPUModels(qemuCaps, &buf, VIR_DOMAIN_VIRT_KVM);
+ if (virQEMUCapsGet(qemuCaps, QEMU_CAPS_HVF))
+ virQEMUCapsFormatCPUModels(qemuCaps, &buf, VIR_DOMAIN_VIRT_HVF);
virQEMUCapsFormatCPUModels(qemuCaps, &buf, VIR_DOMAIN_VIRT_QEMU);
for (i = 0; i < qemuCaps->nmachineTypes; i++) {
@@ -4455,7 +4475,7 @@ virQEMUCapsInitQMPCommandRun(virQEMUCapsInitQMPCommandPtr cmd,
if (forceTCG)
machine = "none,accel=tcg";
else
- machine = "none,accel=kvm:tcg";
+ machine = "none,accel=kvm:hvf:tcg";
VIR_DEBUG("Try to probe capabilities of '%s' via QMP, machine %s",
cmd->binary, machine);
@@ -4646,6 +4666,8 @@ virQEMUCapsNewForBinaryInternal(virArch hostArch,
if (virQEMUCapsGet(qemuCaps, QEMU_CAPS_KVM))
virQEMUCapsInitHostCPUModel(qemuCaps, hostArch, VIR_DOMAIN_VIRT_KVM);
+ if (virQEMUCapsGet(qemuCaps, QEMU_CAPS_HVF))
+ virQEMUCapsInitHostCPUModel(qemuCaps, hostArch, VIR_DOMAIN_VIRT_HVF);
virQEMUCapsInitHostCPUModel(qemuCaps, hostArch, VIR_DOMAIN_VIRT_QEMU);
if (virQEMUCapsGet(qemuCaps, QEMU_CAPS_KVM)) {
--
2.19.1
3:01 p.m.
New subject: [libvirt] [PATCHv2 13/16] news: Mention hvf domain type
Signed-off-by: Roman Bolshakov <r.bolshakov(a)yadro.com>
---
docs/news.xml | 12 ++++++++++++
1 file changed, 12 insertions(+)
diff --git a/docs/news.xml b/docs/news.xml
index 4406aeb775..90e378187d 100644
--- a/docs/news.xml
+++ b/docs/news.xml
@@ -68,6 +68,18 @@
be viewed via the domain statistics.
</description>
</change>
+ <change>
+ <summary>
+ qemu: Add hvf domain type for Hypervisor.framework
+ </summary>
+ <description>
+ QEMU introduced experimental support of Hypervisor.framework
+ since 2.12.
+
+ It's supported on machines with Intel VT-x feature set that includes
+ Extended Page Tables (EPT) and Unrestricted Mode since macOS 10.10.
+ </description>
+ </change>
</section>
<section title="Improvements">
</section>
--
2.19.1
3:01 p.m.
New subject: [libvirt] [PATCHv2 14/16] docs: Add hvf on QEMU driver page
It's worth to make the domain type a little bit more visible than a row
in news. An example of hvf domain is available on QEMU driver page.
While at it, mention Hypervisor.framework on index page.
Signed-off-by: Roman Bolshakov <r.bolshakov(a)yadro.com>
---
docs/drvqemu.html.in | 49 +++++++++++++++++++++++++++++++++++++++++---
docs/index.html.in | 1 +
2 files changed, 47 insertions(+), 3 deletions(-)
diff --git a/docs/drvqemu.html.in b/docs/drvqemu.html.in
index 0d14027646..7c511ce3b6 100644
--- a/docs/drvqemu.html.in
+++ b/docs/drvqemu.html.in
@@ -2,13 +2,16 @@
<!DOCTYPE html>
<html xmlns="http://www.w3.org/1999/xhtml">
<body>
- <h1>KVM/QEMU hypervisor driver</h1>
+ <h1>QEMU/KVM/HVF hypervisor driver</h1>
<ul id="toc"></ul>
<p>
- The libvirt KVM/QEMU driver can manage any QEMU emulator from
- version 1.5.0 or later.
+ The libvirt QEMU driver can manage any QEMU emulator from
+ version 1.5.0 or later. It supports multiple QEMU accelerators: software
+ emulation also known as TCG, hardware-assisted virtualization on Linux
+ with KVM and hardware-assisted virtualization on macOS with
+ Hypervisor.framework (<span class="since">since
4.10.0</span>).
</p>
<h2><a id="project">Project Links</a></h2>
@@ -21,6 +24,9 @@
<li>
The <a href="https://wiki.qemu.org/Index.html">QEMU</a>
emulator
</li>
+ <li>
+ <a
href="https://developer.apple.com/documentation/hypervisor">...
reference
+ </li>
</ul>
<h2><a id="prereq">Deployment
pre-requisites</a></h2>
@@ -41,6 +47,13 @@
node. If both are found, then KVM fullyvirtualized, hardware accelerated
guests will be available.
</li>
+ <li>
+ <strong>Hypervisor.framework (HVF)</strong>: The driver will probe
+ <code>sysctl</code> for the presence of
+ <code>Hypervisor.framework</code>. If it is found and QEMU is newer
+ than 2.12, then it will be possible to create hardware accelerated
+ guests.
+ </li>
</ul>
<h2><a id="uris">Connections to QEMU
driver</a></h2>
@@ -640,5 +653,35 @@ $ virsh domxml-to-native qemu-argv demo.xml
</devices>
</domain></pre>
+ <h3>HVF hardware accelerated guest on x86_64</h3>
+
+ <pre><domain type='hvf'>
+ <name>hvf-demo</name>
+ <uuid>4dea24b3-1d52-d8f3-2516-782e98a23fa0</uuid>
+ <memory>131072</memory>
+ <vcpu>1</vcpu>
+ <os>
+ <type arch="x86_64">hvm</type>
+ </os>
+ <features>
+ <acpi/>
+ </features>
+ <clock sync="localtime"/>
+ <devices>
+ <emulator>/usr/local/bin/qemu-system-x86_64</emulator>
+ <controller type='scsi' index='0'
model='virtio-scsi'/>
+ <disk type='volume' device='disk'>
+ <driver name='qemu' type='qcow2'/>
+ <source pool='default' volume='myos'/>
+ <target bus='scsi' dev='sda'/>
+ </disk>
+ <interface type='user'>
+ <mac address='24:42:53:21:52:45'/>
+ <model type='virtio'/>
+ </interface>
+ <graphics type='vnc' port='-1'/>
+ </devices>
+</domain></pre>
+
</body>
</html>
diff --git a/docs/index.html.in b/docs/index.html.in
index 1f9f448399..b02802fdd9 100644
--- a/docs/index.html.in
+++ b/docs/index.html.in
@@ -32,6 +32,7 @@
<li>is accessible from C, Python, Perl, Java and more</li>
<li>is licensed under open source licenses</li>
<li>supports <a href="drvqemu.html">KVM</a>,
+ <a href="drvqemu.html">Hypervisor.framework</a>,
<a href="drvqemu.html">QEMU</a>, <a
href="drvxen.html">Xen</a>,
<a href="drvvirtuozzo.html">Virtuozzo</a>,
<a href="drvesx.html">VMWare ESX</a>,
--
2.19.1
3:01 p.m.
New subject: [libvirt] [PATCHv2 15/16] docs: Note hvf support for domain elements
Many domain elements have "QEMU and KVM only" or "QEMU/KVM since
x.y.z"
remarks. Most of the elements work for HVF domain, so it makes sense to
add respective notices for HVF domain.
All the elements have been manually tested.
Signed-off-by: Roman Bolshakov <r.bolshakov(a)yadro.com>
---
docs/formatdomain.html.in | 133 ++++++++++++++++++++++----------------
1 file changed, 77 insertions(+), 56 deletions(-)
diff --git a/docs/formatdomain.html.in b/docs/formatdomain.html.in
index 25dd4bbbd6..b1a64c7c74 100644
--- a/docs/formatdomain.html.in
+++ b/docs/formatdomain.html.in
@@ -158,10 +158,10 @@
which is specified by absolute path,
used to assist the domain creation process. It is used by Xen
fully virtualized domains as well as setting the QEMU BIOS file
- path for QEMU/KVM domains. <span class="since">Xen since 0.1.0,
- QEMU/KVM since 0.9.12</span> Then, <span
class="since">since
- 1.2.8</span> it's possible for the element to have two
- optional attributes: <code>readonly</code> (accepted values are
+ path for QEMU/KVM/HVF domains. <span class="since">Xen since
0.1.0,
+ QEMU/KVM since 0.9.12, HVF since 4.10.0</span> Then, <span
+ class="since">since 1.2.8</span> it's possible for the
element to have
+ two optional attributes: <code>readonly</code> (accepted values are
<code>yes</code> and <code>no</code>) to reflect the fact
that the
image should be writable or read-only. The second attribute
<code>type</code> accepts values <code>rom</code> and
@@ -680,7 +680,7 @@
IOThreads are dedicated event loop threads for supported disk
devices to perform block I/O requests in order to improve
scalability especially on an SMP host/guest with many LUNs.
- <span class="since">Since 1.2.8 (QEMU only)</span>
+ <span class="since">QEMU/KVM since 1.2.8, HVF since
4.10.0</span>
</p>
<pre>
@@ -1603,12 +1603,13 @@
Both <code>host-model</code> and
<code>host-passthrough</code> modes
make sense when a domain can run directly on the host CPUs (for
- example, domains with type <code>kvm</code>). The actual host CPU is
- irrelevant for domains with emulated virtual CPUs (such as domains with
- type <code>qemu</code>). However, for backward compatibility
- <code>host-model</code> may be implemented even for domains running
on
- emulated CPUs in which case the best CPU the hypervisor is able to
- emulate may be used rather then trying to mimic the host CPU model.
+ example, domains with type <code>kvm</code> or
<code>hvf</code>). The
+ actual host CPU is irrelevant for domains with emulated virtual CPUs
+ (such as domains with type <code>qemu</code>). However, for backward
+ compatibility <code>host-model</code> may be implemented even for
+ domains running on emulated CPUs in which case the best CPU the
+ hypervisor is able to emulate may be used rather then trying to mimic
+ the host CPU model.
</dd>
<dt><code>model</code></dt>
@@ -1902,12 +1903,12 @@
</dl>
<p>
- QEMU/KVM supports the <code>on_poweroff</code> and
<code>on_reboot</code>
- events handling the <code>destroy</code> and
<code>restart</code> actions.
- The <code>preserve</code> action for an
<code>on_reboot</code> event
- is treated as a <code>destroy</code> and the
<code>rename-restart</code>
- action for an <code>on_poweroff</code> event is treated as a
- <code>restart</code> event.
+ QEMU/KVM/HVF domains support the <code>on_poweroff</code> and
+ <code>on_reboot</code> events handling the
<code>destroy</code> and
+ <code>restart</code> actions. The <code>preserve</code>
action for an
+ <code>on_reboot</code> event is treated as a
<code>destroy</code> and the
+ <code>rename-restart</code> action for an
<code>on_poweroff</code> event is
+ treated as a <code>restart</code> event.
</p>
<p>
@@ -2043,7 +2044,7 @@
to address more than 4 GB of memory.</dd>
<dt><code>acpi</code></dt>
<dd>ACPI is useful for power management, for example, with
- KVM guests it is required for graceful shutdown to work.
+ KVM or HVF guests it is required for graceful shutdown to work.
</dd>
<dt><code>apic</code></dt>
<dd>APIC allows the use of programmable IRQ
@@ -2286,7 +2287,8 @@
</dd>
<dt><code>vmcoreinfo</code></dt>
<dd>Enable QEMU vmcoreinfo device to let the guest kernel save debug
- details. <span class="since">Since 4.4.0</span> (QEMU
only)
+ details. <span class="since">QEMU/KVM since 4.4.0, HVF since
+ 4.10.0</span>
</dd>
<dt><code>htm</code></dt>
<dd>Configure HTM (Hardware Transational Memory) availability for
@@ -3559,7 +3561,7 @@
Copy-on-read avoids accessing the same backing file sectors
repeatedly and is useful when the backing file is over a slow
network. By default copy-on-read is off.
- <span class='since'>Since 0.9.10 (QEMU and KVM
only)</span>
+ <span class='since'>QEMU/KVM since 0.9.10, HVF since
4.10.0</span>
</li>
<li>
The optional <code>discard</code> attribute controls whether
@@ -3567,7 +3569,7 @@
ignored or passed to the filesystem. The value can be either
"unmap" (allow the discard request to be passed) or
"ignore"
(ignore the discard request).
- <span class='since'>Since 1.0.6 (QEMU and KVM
only)</span>
+ <span class='since'>QEMU/KVM since 1.0.6, HVF since
4.10.0</span>
</li>
<li>
The optional <code>detect_zeroes</code> attribute controls
whether
@@ -3723,7 +3725,7 @@
<dt><code>blockio</code></dt>
<dd>If present, the <code>blockio</code> element allows
to override any of the block device properties listed below.
- <span class="since">Since 0.10.2 (QEMU and KVM)</span>
+ <span class="since">QEMU/KVM since 0.10.2, HVF since
4.10.0</span>
<dl>
<dt><code>logical_block_size</code></dt>
<dd>The logical block size the disk will report to the guest
@@ -4157,14 +4159,14 @@
The optional <code>queues</code> attribute specifies the number of
queues for the controller. For best performance, it's recommended to
specify a value matching the number of vCPUs.
- <span class="since">Since 1.0.5 (QEMU and KVM only)</span>
+ <span class="since">QEMU/KVM since 1.0.5, HVF since
4.10.0</span>
</dd>
<dt><code>cmd_per_lun</code></dt>
<dd>
The optional <code>cmd_per_lun</code> attribute specifies the
maximum
number of commands that can be queued on devices controlled by the
host.
- <span class="since">Since 1.2.7 (QEMU and KVM only)</span>
+ <span class="since">QEMU/KVM since 1.2.7, HVF since
4.10.0</span>
</dd>
<dt><code>max_sectors</code></dt>
<dd>
@@ -4172,7 +4174,7 @@
amount of data in bytes that will be transferred to or from the device
in a single command. The transfer length is measured in sectors, where
a sector is 512 bytes.
- <span class="since">Since 1.2.7 (QEMU and KVM only)</span>
+ <span class="since">QEMU/KVM since 1.2.7, HVF since
4.10.0</span>
</dd>
<dt><code>ioeventfd</code></dt>
<dd>
@@ -4268,7 +4270,8 @@
<code>unit</code> attribute) the 64-bit PCI hole should be. Some guests
(like
Windows XP or Windows Server 2003) might crash when QEMU and Seabios
are recent enough to support 64-bit PCI holes, unless this is disabled
- (set to 0). <span class="since">Since 1.1.2 (QEMU
only)</span>
+ (set to 0). <span class="since">QEMU/KVM since 1.1.2, HVF since
+ 4.10.0</span>
</p>
<p>
PCI controllers also have an optional
@@ -4280,8 +4283,8 @@
model <b>attribute</b>. In almost all cases, you should not
manually add a <code><model></code> subelement to a
controller, nor should you modify one that is automatically
- generated by libvirt. <span class="since">Since 1.2.19 (QEMU
- only).</span>
+ generated by libvirt. <span class="since">QEMU/KVM since 1.2.19,
HVF
+ since 4.10.0</span>
</p>
<p>
PCI controllers also have an optional
@@ -4293,7 +4296,8 @@
should not manually add a <code><target></code>
subelement
to a controller, nor should you modify the values in the those
that are automatically generated by
- libvirt. <span class="since">Since 1.2.19 (QEMU
only).</span>
+ libvirt. <span class="since">QEMU/KVM since 1.2.19, HVF since
4.10.0
+ </span>
</p>
<dl>
<dt><code>chassisNr</code></dt>
@@ -5681,7 +5685,7 @@
<p>
The values for <code>type</code> aren't defined specifically by
libvirt, but by what the underlying hypervisor supports (if
- any). For QEMU and KVM you can get a list of supported models
+ any). For QEMU, KVM and HVF you can get a list of supported models
with these commands:
</p>
@@ -5691,7 +5695,7 @@ qemu-kvm -net nic,model=? /dev/null
</pre>
<p>
- Typical values for QEMU and KVM include:
+ Typical values for QEMU, KVM and HVF include:
ne2k_isa i82551 i82557b i82559er ne2k_pci pcnet rtl8139 e1000 virtio
</p>
@@ -5730,7 +5734,7 @@ qemu-kvm -net nic,model=? /dev/null
will be rejected. If this attribute is not present, then the
domain defaults to 'vhost' if present, but silently falls back
to 'qemu' without error.
- <span class="since">Since 0.8.8 (QEMU and KVM only)</span>
+ <span class="since">QEMU/KVM since 0.8.8, HVF since
4.10.0</span>
</dd>
<dd>
For interfaces of type='hostdev' (PCI passthrough devices)
@@ -5755,7 +5759,8 @@ qemu-kvm -net nic,model=? /dev/null
The <code>txmode</code> attribute specifies how to handle
transmission of packets when the transmit buffer is full. The
value can be either 'iothread' or 'timer'.
- <span class="since">Since 0.8.8 (QEMU and KVM
only)</span><br/><br/>
+ <span class="since">QEMU/KVM since 0.8.8, HVF since
4.10.0</span>
+ <br/><br/>
If set to 'iothread', packet tx is all done in an iothread in
the bottom half of the driver (this option translates into
@@ -5801,7 +5806,8 @@ qemu-kvm -net nic,model=? /dev/null
usually if the feature is supported, default is on. In case
there is a situation where this behavior is suboptimal, this
attribute provides a way to force the feature off.
- <span class="since">Since 0.9.5 (QEMU and KVM
only)</span><br/><br/>
+ <span class="since">QEMU/KVM since 0.9.5, HVF since
4.10.0</span>
+ <br/><br/>
<b>In general you should leave this option alone, unless you
are very certain you know what you are doing.</b>
@@ -5828,7 +5834,8 @@ qemu-kvm -net nic,model=? /dev/null
some restrictions on actual value. For instance, latest
QEMU (as of 2016-09-01) requires value to be a power of two
from [256, 1024] range.
- <span class="since">Since 2.3.0 (QEMU and KVM
only)</span><br/><br/>
+ <span class="since">QEMU/KVM since 2.3.0, HVF since
4.10.0</span>
+ <br/><br/>
<b>In general you should leave this option alone, unless you
are very certain you know what you are doing.</b>
@@ -5844,7 +5851,8 @@ qemu-kvm -net nic,model=? /dev/null
range. In addition to that, this may work only for a subset of
interface types, e.g. aforementioned QEMU enables this option
only for <code>vhostuser</code> type.
- <span class="since">Since 3.7.0 (QEMU and KVM
only)</span><br/><br/>
+ <span class="since">QEMU/KVM since 3.7.0, HVF since
4.10.0</span>
+ <br/><br/>
<b>In general you should leave this option alone, unless you
are very certain you know what you are doing.</b>
@@ -6748,7 +6756,10 @@ qemu-kvm -net nic,model=? /dev/null
of the first forward dev will be used.
</p>
</dd>
- <dt><code>socket</code> <span class="since">since
2.0.0 (QEMU only)</span></dt>
+ <dt>
+ <code>socket</code> <span class="since">QEMU/KVM
since 2.0.0, HVF
+ since 4.10.0</span>
+ </dt>
<dd>
<p>
This listen type tells a graphics server to listen on unix socket.
@@ -6764,7 +6775,10 @@ qemu-kvm -net nic,model=? /dev/null
attribute all <code>listen</code> elements are ignored.
</p>
</dd>
- <dt><code>none</code> <span class="since">since
2.0.0 (QEMU only)</span></dt>
+ <dt>
+ <code>none</code> <span class="since">QEMU/KVM since
2.0.0, HVF
+ since 4.10.0</span>
+ </dt>
<dd>
<p>
This listen type doesn't have any other attribute. Libvirt supports
@@ -6838,19 +6852,21 @@ qemu-kvm -net nic,model=? /dev/null
<p>
You can provide the amount of video memory in kibibytes (blocks of
1024 bytes) using <code>vram</code>. This is supported only for
guest
- type of "libxl", "vz", "qemu", "vbox",
"vmx" and "xen". If no
- value is provided the default is used. If the size is not a power of
- two it will be rounded to closest one.
+ type of "libxl", "vz", "qemu", "kvm",
"hvf", "vbox", "vmx" and "xen".
+ If no value is provided the default is used. If the size is not a
+ power of two it will be rounded to closest one.
</p>
<p>
The number of screen can be set using <code>heads</code>. This is
- supported only for guests type of "vz", "kvm",
"vbox" and "vmx".
+ supported only for guests type of "vz", "kvm",
"hvf", "vbox" and
+ "vmx".
</p>
<p>
- For guest type of "kvm" or "qemu" and model type
"qxl" there are
- optional attributes. Attribute <code>ram</code> (<span
class="since">
- since 1.0.2</span>) specifies the size of the primary bar, while the
- attribute <code>vram</code> specifies the secondary bar size.
+ For guest type of "kvm", "hvf" or "qemu" and
model type "qxl" there
+ are optional attributes. Attribute <code>ram</code> (<span
+ class="since"> since 1.0.2</span>) specifies the size of the
primary
+ bar, while the attribute <code>vram</code> specifies the secondary
bar
+ size.
If <code>ram</code> or <code>vram</code> are not
supplied a default
value is used. The <code>ram</code> should also be rounded to power
of
two as <code>vram</code>. There is also optional attribute
@@ -7735,7 +7751,7 @@ qemu-kvm -net nic,model=? /dev/null
<p>
A virtual hardware watchdog device can be added to the guest via
the <code>watchdog</code> element.
- <span class="since">Since 0.7.3, QEMU and KVM only</span>
+ <span class="since">QEMU/KVM since 0.7.3, HVF since
4.10.0</span>
</p>
<p>
@@ -7773,12 +7789,17 @@ qemu-kvm -net nic,model=? /dev/null
underlying hypervisor.
</p>
<p>
- QEMU and KVM support:
+ QEMU, KVM and HVF support:
</p>
<ul>
<li>'i6300esb' - the recommended device,
emulating a PCI Intel 6300ESB </li>
<li>'ib700' - emulating an ISA iBase IB700 </li>
+ </ul>
+ <p>
+ QEMU and KVM for s390/s390x support:
+ </p>
+ <ul>
<li>'diag288' - emulating an S390 DIAG288 device
<span class="since">Since 1.2.17</span></li>
</ul>
@@ -7791,7 +7812,7 @@ qemu-kvm -net nic,model=? /dev/null
specific to the underlying hypervisor.
</p>
<p>
- QEMU and KVM support:
+ QEMU, KVM and HVF support:
</p>
<ul>
<li>'reset' - default, forcefully reset the guest</li>
@@ -7823,14 +7844,14 @@ qemu-kvm -net nic,model=? /dev/null
<h4><a id="elementsMemBalloon">Memory balloon
device</a></h4>
<p>
- A virtual memory balloon device is added to all Xen and KVM/QEMU
+ A virtual memory balloon device is added to all Xen and QEMU/KVM/HVF
guests. It will be seen as <code>memballoon</code> element.
It will be automatically added when appropriate, so there is no
need to explicitly add this element in the guest XML unless a
specific PCI slot needs to be assigned.
- <span class="since">Since 0.8.3, Xen, QEMU and KVM
only</span>
- Additionally, <span class="since">since 0.8.4</span>, if the
- memballoon device needs to be explicitly disabled,
+ <span class="since">Xen, QEMU and KVM since 0.8.3, HVF since
+ 4.10.0</span> Additionally, <span class="since">since
0.8.4</span>, if
+ the memballoon device needs to be explicitly disabled,
<code>model='none'</code> may be used.
</p>
@@ -7867,7 +7888,7 @@ qemu-kvm -net nic,model=? /dev/null
the virtualization platform
</p>
<ul>
- <li>'virtio' - default with QEMU/KVM</li>
+ <li>'virtio' - default with QEMU/KVM/HVF</li>
<li>'xen' - default with Xen</li>
</ul>
</dd>
@@ -8148,7 +8169,7 @@ qemu-kvm -net nic,model=? /dev/null
<p>
panic device enables libvirt to receive panic notification from a QEMU
guest.
- <span class="since">Since 1.2.1, QEMU and KVM only</span>
+ <span class="since">QEMU/KVM since 1.2.1, HVF since
4.10.0</span>
</p>
<p>
This feature is always enabled for:
@@ -8816,7 +8837,7 @@ qemu-kvm -net nic,model=? /dev/null
<ul>
<li><a href="drvxen.html#xmlconfig">Xen
examples</a></li>
- <li><a href="drvqemu.html#xmlconfig">QEMU/KVM
examples</a></li>
+ <li><a href="drvqemu.html#xmlconfig">QEMU/KVM/HVF
examples</a></li>
</ul>
</body>
</html>
--
2.19.1
3:01 p.m.
New subject: [libvirt] [PATCHv2 16/16] docs: Add support page for libvirt on macOS
While at it, rename OS-X on index page to macOS.
Signed-off-by: Roman Bolshakov <r.bolshakov(a)yadro.com>
---
docs/docs.html.in | 3 +
docs/index.html.in | 3 +-
docs/macos.html.in | 229 +++++++++++++++++++++++++++++++++++++++++++++
3 files changed, 234 insertions(+), 1 deletion(-)
create mode 100644 docs/macos.html.in
diff --git a/docs/docs.html.in b/docs/docs.html.in
index 40e0e3b82e..84a51a55fb 100644
--- a/docs/docs.html.in
+++ b/docs/docs.html.in
@@ -12,6 +12,9 @@
<dt><a href="windows.html">Windows</a></dt>
<dd>Downloads for Windows</dd>
+ <dt><a href="macos.html">macOS</a></dt>
+ <dd>Working with libvirt on macOS</dd>
+
<dt><a
href="migration.html">Migration</a></dt>
<dd>Migrating guests between machines</dd>
diff --git a/docs/index.html.in b/docs/index.html.in
index b02802fdd9..34b491ec69 100644
--- a/docs/index.html.in
+++ b/docs/index.html.in
@@ -39,7 +39,8 @@
<a href="drvlxc.html">LXC</a>,
<a href="drvbhyve.html">BHyve</a> and
<a href="drivers.html">more</a></li>
- <li>targets Linux, FreeBSD, <a
href="windows.html">Windows</a> and OS-X</li>
+ <li>targets Linux, FreeBSD, <a
href="windows.html">Windows</a> and
+ <a href="macos.html">macOS</a></li>
<li>is used by many <a
href="apps.html">applications</a></li>
</ul>
<p>Recent / forthcoming <a href="news.html">release
changes</a></p>
diff --git a/docs/macos.html.in b/docs/macos.html.in
new file mode 100644
index 0000000000..54c93ea2fb
--- /dev/null
+++ b/docs/macos.html.in
@@ -0,0 +1,229 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html>
+<html xmlns="http://www.w3.org/1999/xhtml">
+ <body>
+ <h1 >macOS support</h1>
+
+ <ul id="toc"></ul>
+
+ <p>
+ Libvirt works both as client and server (for <a
href="drvqemu.html">
+ "qemu" domain</a>) on macOS High Sierra (10.13) and macOS Mojave
(10.14)
+ since 4.7.0. Other macOS variants likely work but we neither tested nor
+ received reports for them.
+ </p>
+
+ <p>
+ <a href="drvqemu.html">"hvf" domain type</a> adds
support of <a
+ href="https://developer.apple.com/documentation/hypervisor">
+ Hypervisor.framework</a> since 4.10.0. To use "hvf" domain, QEMU
must
+ be at least 2.12 and macOS must be no less than Yosemite (10.10). "hvf"
+ domain type is similar to "kvm" but it has less features.
+ </p>
+
+ <p>
+ Hypervisor.framework is available on your machine if the sysctl command
+ returns 1:
+
+ <pre>sysctl -n kern.hv_support</pre>
+ </p>
+
+ <h2><a id="installation">Installation</a></h2>
+
+ <p>
+ libvirt client (virsh), server (libvirtd) and development headers can be
+ installed from <a href="https://brew.sh">homebrew</a>:
+
+ <pre>brew install libvirt</pre>
+
+ <a href="http://virt-manager.org">virt-manager and
virt-viewer</a> can be
+ installed from source via <a
+ href="https://github.com/jeffreywildman/homebrew-virt-manager">
+ Jeffrey Wildman's tap</a>:
+
+ <pre>brew tap jeffreywildman/homebrew-virt-manager
+brew install virt-manager virt-viewer</pre>
+ </p>
+
+ <h2><a id='local-libvirtd'>Running libvirtd
locally</a></h2>
+
+ <p>
+ The server can be started manually:
+ <pre>libvirtd</pre>
+ or on system boot:
+ <pre>brew services start libvirt</pre>
+ </p>
+ <p>
+ Once started, you can use virsh to work with libvirtd:
+ <pre>virsh define domain.xml
+virsh start domain
+virsh shutdown domain</pre>
+
+ For more details on virsh, please see <a
href="virshcmdref.html">virsh
+ command reference</a> or built-in help:
+ <pre>virsh help</pre>
+ </p>
+
+ <p>
+ Domain XML examples can be found on <a
href="drvqemu.html#xmlconfig">QEMU
+ driver page</a>. Full reference is available on <a
+ href="formatdomain.html">domain XML format page</a>.
+ </p>
+
+ <p>
+ You can use virt-manager to connect to libvirtd (connection URI must be
+ specified on the first connection, then it'll be possible to omit it):
+ <pre>virt-manager -c qemu:///session</pre>
+ or, if you only need an access to the virtual display of a VM you can use
+ virt-viewer:
+ <pre>virt-viewer -c qemu:///session</pre>
+ </p>
+
+ <h2><a id="external-hypervisors">Working with external
hypervisors</a></h2>
+ <p>
+ Details on the example domain XML files, capabilities and connection
+ string syntax used for connecting to external hypervisors can be found
+ online on <a href="drivers.html">hypervisor specific driver
+ pages</a>.
+ </p>
+
+ <h2><a id="tlscerts">TLS Certificates</a></h2>
+
+ <p>
+ TLS certificates must be placed in the correct locations, before you will
+ be able to connect to QEMU servers over TLS.
+ </p>
+
+ <p>
+ Information on generating TLS certificates can be found here:
+ </p>
+
+ <a
href="http://wiki.libvirt.org/page/TLSSetup">http://wiki.lib...
+
+ <p>
+ The Certificate Authority (CA) certificate file must be placed in:
+ </p>
+
+ <ul>
+ <li>~/.cache/libvirt/pki/CA/cacert.pem</li>
+ </ul>
+
+ <p>
+ The Client certificate file must be placed in:
+ </p>
+
+ <ul>
+ <li>~/.cache/libvirt/pki/libvirt/clientcert.pem</li>
+ </ul>
+
+ <p>
+ The Client key file must be placed in:
+ </p>
+
+ <ul>
+ <li>~/.cache/libvirt/pki/libvirt/private/clientkey.pem</li>
+ </ul>
+
+ <h2><a id="known-issues">Known issues</a></h2>
+ <p>
+ This is a list of issues that can be easily fixed and provide
+ substantial improvement of user experience:
+ </p>
+ <ul>
+ <li>
+ virt-install doesn't work unless disks are created upfront. The reason
+ is because VIR_STORAGE_VOL_CREATE_PREALLOC_METADATA sets
+ preallocate=falloc which is not supported by qemu-img on macOS.
+ </li>
+ <li>
+ "hvf" is not default domain type when virt-install connects to the
+ local libvirtd on macOS
+ </li>
+ <li>
+ QXL VGA device and SPICE display cannot be used unless QEMU is compiled
+ with SPICE server. The changes to build and run SPICE server on macOS
+ haven't been sent to upstream yet.
+ </li>
+ <li>
+ "make check" reports many failing tests on macOS. Some of the tests
+ need to be adopted to run both on Linux and macOS.
+ </li>
+ <li>
+ "make syntax-check" needs be fixed too, it depends on GNU version of
+ grep but uses system (BSD) grep.
+ </li>
+ <li>
+ QEMU from homebrew is compiled without USB redirection support.
+ </li>
+ <li>
+ CPU usage is not gathered for VMs and therefore cannot be dispalyed in
+ virt-manager.
+ </li>
+ <li>
+ libvirtd logs are noisy because some features are missing.
+ </li>
+ </ul>
+
+ <h2><a id="missing-features">Missing
features</a></h2>
+ <p>
+ "hvf" is a new domain type and can't be compared to "kvm"
feature-wise.
+ "kvm" domain relies on QEMU backend devices implemented in Linux kernel
+ such as para-virtualized vhost devices and PCI-passthrough with vfio.
+
+ Nonetheless, some of the features available in "kvm" domain can be
+ implemented in userspace for "hvf" domain.
+ </p>
+ <ul>
+ <li>
+ Instruction emulation in "hvf" accelerator is not mature. The bugs are
+ tracked on <a
+ href="https://bugs.launchpad.net/qemu/+bugs?field.tag=hvf">QEMU bug
+ tracker</a>.
+ </li>
+ <li>
+ Power Management notifications are not implemented, therefore guests
+ cannot respond to <a
+
href="https://developer.apple.com/library/archive/qa/qa1340/_index.h...
+ sleep events on the host</a>.
+ </li>
+ <li>
+ CPU pinning doesn't work but macOS provides <a
+
href="https://developer.apple.com/library/archive/releasenotes/Perfo...
+ Thread Affinity API</a> that can be used to implement it.
+ </li>
+ <li>
+ Network management is not available but macOS has an API that is used
+ by ifconfig to create bridge and tap devices. So, it should be possible
+ to implement network management and bridged networking.
+ </li>
+ <li>
+ Filesystem pass-through is not available.
+ </li>
+ <li>
+ PCI/SCSI/USB pass-through is not available.
+ </li>
+ </ul>
+
+
+ <h2><a id="feedback">Feedback</a></h2>
+
+ <p>
+ Feedback and suggestions on changes and what else to include
+ <a href="contact.html">are desired</a>.
+ </p>
+
+ <h2><a id="compiling">Compiling yourself</a></h2>
+
+ <p>
+ Use these options when following the instructions on the
+ <a href="compiling.html">Compiling</a> page.
+ </p>
+
+<pre>
+./configure \
+ --without-wireshark-dissector \
+ --without-dbus
+</pre>
+
+ </body>
+</html>
--
2.19.1
2104
days inactive
2131
days old
28 comments
3 participants
participants (3)
-
Jiri Denemark -
Pino Toscano -
Roman Bolshakov