[libvirt] [PATCH] qemu: Permit PCI-free aarch64 mach-virt guests
by Andrea Bolognani
There has been some progress lately in enabling virtio-pci on
aarch64 guests; however, guest OS support is still spotty at best,
so most guests are going to be using virtio-mmio instead.
Currently, mach-virt guests are closely modeled after q35 guests,
and that includes always adding a dmi-to-pci-bridge that's just
impossible to get rid of. While that's acceptable (if suboptimal)
for q35, where you will always need some kind of PCI device anyway,
mach-virt guests should be allowed to avoid it.
---
src/qemu/qemu_domain.c | 8 ++++++--
src/qemu/qemu_domain_address.c | 8 +++++++-
.../qemuxml2argv-aarch64-virt-2.6-virtio-pci-default.args | 1 -
.../qemuxml2argv-aarch64-virtio-pci-default.args | 1 -
.../qemuxml2argv-aarch64-virtio-pci-manual-addresses.args | 5 +++--
.../qemuxml2argv-aarch64-virtio-pci-manual-addresses.xml | 14 ++++++++++++--
.../qemuxml2xmlout-aarch64-virtio-pci-default.xml | 4 ----
.../qemuxml2xmlout-aarch64-virtio-pci-manual-addresses.xml | 13 +++++++++----
8 files changed, 37 insertions(+), 17 deletions(-)
diff --git a/src/qemu/qemu_domain.c b/src/qemu/qemu_domain.c
index 1eb5644..595ad64 100644
--- a/src/qemu/qemu_domain.c
+++ b/src/qemu/qemu_domain.c
@@ -1951,11 +1951,15 @@ qemuDomainDefAddDefaultDevices(virDomainDefPtr def,
VIR_DOMAIN_CONTROLLER_MODEL_PCIE_ROOT)) {
goto cleanup;
}
- /* add a dmi-to-pci-bridge and a pci-bridge if there are no pci controllers
+ /* Add a dmi-to-pci-bridge bridge if there are no PCI controllers
* other than the pcie-root. This is so that there will be hot-pluggable
- * PCI slots available
+ * PCI slots available.
+ *
+ * We skip this step for aarch64 mach-virt guests, where we want to
+ * be able to have a pure virtio-mmio topology
*/
if (virDomainControllerFind(def, VIR_DOMAIN_CONTROLLER_TYPE_PCI, 1) < 0 &&
+ !qemuDomainMachineIsVirt(def) &&
!virDomainDefAddController(def, VIR_DOMAIN_CONTROLLER_TYPE_PCI, 1,
VIR_DOMAIN_CONTROLLER_MODEL_DMI_TO_PCI_BRIDGE))
goto cleanup;
diff --git a/src/qemu/qemu_domain_address.c b/src/qemu/qemu_domain_address.c
index ca3adc0..883264a 100644
--- a/src/qemu/qemu_domain_address.c
+++ b/src/qemu/qemu_domain_address.c
@@ -1483,9 +1483,15 @@ qemuDomainAssignPCIAddresses(virDomainDefPtr def,
}
/* Reserve 1 extra slot for a (potential) bridge only if buses
- * are not fully reserved yet
+ * are not fully reserved yet.
+ *
+ * We don't reserve the extra slot for aarch64 mach-virt guests
+ * either because we want to be able to have pure virtio-mmio
+ * guests, and reserving this slot would force us to add at least
+ * a dmi-to-pci-bridge to an otherwise PCI-free topology
*/
if (!buses_reserved &&
+ !qemuDomainMachineIsVirt(def) &&
virDomainPCIAddressReserveNextSlot(addrs, &info, flags) < 0)
goto cleanup;
diff --git a/tests/qemuxml2argvdata/qemuxml2argv-aarch64-virt-2.6-virtio-pci-default.args b/tests/qemuxml2argvdata/qemuxml2argv-aarch64-virt-2.6-virtio-pci-default.args
index 2a5702f..3e6bee9 100644
--- a/tests/qemuxml2argvdata/qemuxml2argv-aarch64-virt-2.6-virtio-pci-default.args
+++ b/tests/qemuxml2argvdata/qemuxml2argv-aarch64-virt-2.6-virtio-pci-default.args
@@ -21,7 +21,6 @@ QEMU_AUDIO_DRV=none \
-initrd /aarch64.initrd \
-append 'earlyprintk console=ttyAMA0,115200n8 rw root=/dev/vda rootwait' \
-dtb /aarch64.dtb \
--device i82801b11-bridge,id=pci.1,bus=pcie.0,addr=0x1 \
-device virtio-serial-device,id=virtio-serial0 \
-usb \
-drive file=/aarch64.raw,format=raw,if=none,id=drive-virtio-disk0 \
diff --git a/tests/qemuxml2argvdata/qemuxml2argv-aarch64-virtio-pci-default.args b/tests/qemuxml2argvdata/qemuxml2argv-aarch64-virtio-pci-default.args
index a2df858..566bee2 100644
--- a/tests/qemuxml2argvdata/qemuxml2argv-aarch64-virtio-pci-default.args
+++ b/tests/qemuxml2argvdata/qemuxml2argv-aarch64-virtio-pci-default.args
@@ -21,7 +21,6 @@ QEMU_AUDIO_DRV=none \
-initrd /aarch64.initrd \
-append 'earlyprintk console=ttyAMA0,115200n8 rw root=/dev/vda rootwait' \
-dtb /aarch64.dtb \
--device i82801b11-bridge,id=pci.1,bus=pcie.0,addr=0x1 \
-device virtio-serial-device,id=virtio-serial0 \
-usb \
-drive file=/aarch64.raw,format=raw,if=none,id=drive-virtio-disk0 \
diff --git a/tests/qemuxml2argvdata/qemuxml2argv-aarch64-virtio-pci-manual-addresses.args b/tests/qemuxml2argvdata/qemuxml2argv-aarch64-virtio-pci-manual-addresses.args
index 0234404..4e5dbdb 100644
--- a/tests/qemuxml2argvdata/qemuxml2argv-aarch64-virtio-pci-manual-addresses.args
+++ b/tests/qemuxml2argvdata/qemuxml2argv-aarch64-virtio-pci-manual-addresses.args
@@ -23,12 +23,13 @@ QEMU_AUDIO_DRV=none \
-dtb /aarch64.dtb \
-device i82801b11-bridge,id=pci.1,bus=pcie.0,addr=0x1 \
-device pci-bridge,chassis_nr=2,id=pci.2,bus=pci.1,addr=0x0 \
--device virtio-scsi-pci,id=scsi0,bus=pcie.0,addr=0x3 \
+-device pci-bridge,chassis_nr=3,id=pci.3,bus=pci.1,addr=0x1 \
+-device virtio-scsi-pci,id=scsi0,bus=pci.3,addr=0x1 \
-usb \
-drive file=/aarch64.raw,format=raw,if=none,id=drive-scsi0-0-0-0 \
-device scsi-disk,bus=scsi0.0,channel=0,scsi-id=0,lun=0,drive=drive-scsi0-0-0-0,\
id=scsi0-0-0-0 \
--device virtio-net-pci,vlan=0,id=net0,mac=52:54:00:09:a4:37,bus=pcie.0,addr=0x2 \
+-device virtio-net-pci,vlan=0,id=net0,mac=52:54:00:09:a4:37,bus=pci.3,addr=0x2 \
-net user,vlan=0,name=hostnet0 \
-device virtio-net-pci,vlan=1,id=net1,mac=52:54:00:09:a4:38,bus=pci.2,addr=0x1 \
-net user,vlan=1,name=hostnet1
diff --git a/tests/qemuxml2argvdata/qemuxml2argv-aarch64-virtio-pci-manual-addresses.xml b/tests/qemuxml2argvdata/qemuxml2argv-aarch64-virtio-pci-manual-addresses.xml
index bf0f249..5e1b494 100644
--- a/tests/qemuxml2argvdata/qemuxml2argv-aarch64-virtio-pci-manual-addresses.xml
+++ b/tests/qemuxml2argvdata/qemuxml2argv-aarch64-virtio-pci-manual-addresses.xml
@@ -31,13 +31,23 @@
<target dev='sda' bus='scsi'/>
<address type='drive' controller='0' bus='0' target='0' unit='0'/>
</disk>
+ <controller type='pci' index='0' model='pcie-root'/>
+ <controller type='pci' index='1' model='dmi-to-pci-bridge'>
+ <model name='i82801b11-bridge'/>
+ <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x0'/>
+ </controller>
+ <controller type='pci' index='2' model='pci-bridge'>
+ <model name='pci-bridge'/>
+ <target chassisNr='2'/>
+ <address type='pci' domain='0x0000' bus='0x01' slot='0x00' function='0x0'/>
+ </controller>
<controller type='scsi' index='0' model='virtio-scsi'>
- <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/>
+ <address type='pci' domain='0x0000' bus='0x03' slot='0x01' function='0x0'/>
</controller>
<interface type='user'>
<mac address='52:54:00:09:a4:37'/>
<model type='virtio'/>
- <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x0'/>
+ <address type='pci' domain='0x0000' bus='0x03' slot='0x02' function='0x0'/>
</interface>
<interface type='user'>
<mac address='52:54:00:09:a4:38'/>
diff --git a/tests/qemuxml2xmloutdata/qemuxml2xmlout-aarch64-virtio-pci-default.xml b/tests/qemuxml2xmloutdata/qemuxml2xmlout-aarch64-virtio-pci-default.xml
index a212601..7c3fc19 100644
--- a/tests/qemuxml2xmloutdata/qemuxml2xmlout-aarch64-virtio-pci-default.xml
+++ b/tests/qemuxml2xmloutdata/qemuxml2xmlout-aarch64-virtio-pci-default.xml
@@ -33,10 +33,6 @@
<address type='virtio-mmio'/>
</disk>
<controller type='pci' index='0' model='pcie-root'/>
- <controller type='pci' index='1' model='dmi-to-pci-bridge'>
- <model name='i82801b11-bridge'/>
- <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x0'/>
- </controller>
<controller type='virtio-serial' index='0'>
<address type='virtio-mmio'/>
</controller>
diff --git a/tests/qemuxml2xmloutdata/qemuxml2xmlout-aarch64-virtio-pci-manual-addresses.xml b/tests/qemuxml2xmloutdata/qemuxml2xmlout-aarch64-virtio-pci-manual-addresses.xml
index 4fdedac..1b50f75 100644
--- a/tests/qemuxml2xmloutdata/qemuxml2xmlout-aarch64-virtio-pci-manual-addresses.xml
+++ b/tests/qemuxml2xmloutdata/qemuxml2xmlout-aarch64-virtio-pci-manual-addresses.xml
@@ -32,9 +32,6 @@
<target dev='sda' bus='scsi'/>
<address type='drive' controller='0' bus='0' target='0' unit='0'/>
</disk>
- <controller type='scsi' index='0' model='virtio-scsi'>
- <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/>
- </controller>
<controller type='pci' index='0' model='pcie-root'/>
<controller type='pci' index='1' model='dmi-to-pci-bridge'>
<model name='i82801b11-bridge'/>
@@ -45,10 +42,18 @@
<target chassisNr='2'/>
<address type='pci' domain='0x0000' bus='0x01' slot='0x00' function='0x0'/>
</controller>
+ <controller type='scsi' index='0' model='virtio-scsi'>
+ <address type='pci' domain='0x0000' bus='0x03' slot='0x01' function='0x0'/>
+ </controller>
+ <controller type='pci' index='3' model='pci-bridge'>
+ <model name='pci-bridge'/>
+ <target chassisNr='3'/>
+ <address type='pci' domain='0x0000' bus='0x01' slot='0x01' function='0x0'/>
+ </controller>
<interface type='user'>
<mac address='52:54:00:09:a4:37'/>
<model type='virtio'/>
- <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x0'/>
+ <address type='pci' domain='0x0000' bus='0x03' slot='0x02' function='0x0'/>
</interface>
<interface type='user'>
<mac address='52:54:00:09:a4:38'/>
--
2.5.5
8 years, 4 months
[libvirt] [PATCHv2 0/2] Rewrite prohibit-duplicate-header in perl
by Ján Tomko
v2:
* use minuses instead of underscores in make target
* actually call it during syntax-check
* output file name and line for ViM integration
Ján Tomko (2):
syntax-check: rewrite prohibit-duplicate-header in perl
prohibit-duplicate-header: print file name and line
build-aux/prohibit-duplicate-header.pl | 26 ++++++++++++++++++++++++++
cfg.mk | 32 +++++++-------------------------
2 files changed, 33 insertions(+), 25 deletions(-)
create mode 100644 build-aux/prohibit-duplicate-header.pl
--
2.7.3
8 years, 4 months
[libvirt] [PATCH RESEND 0/2] qemu: reject invalid video accel* settings
by Cole Robinson
This series adds a couple checks for invalid video accel* settings,
incase users screw up their XML when trying to enable spice GL
No change since last posting, just rebased to master
Cole Robinson (2):
qemu: command: Error on accel3d with non-virtio
qemu: command: Error on accel2d
src/qemu/qemu_command.c | 28 ++++++++++++++++++----------
1 file changed, 18 insertions(+), 10 deletions(-)
--
2.7.4
8 years, 4 months
[libvirt] [PATCH] Do not ignore perl scripts in build-aux
by Ján Tomko
Also remove the duplicate build-aux entry from .gitignore.
---
.gitignore | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/.gitignore b/.gitignore
index 8ce7e18..fba1464 100644
--- a/.gitignore
+++ b/.gitignore
@@ -43,7 +43,6 @@
/NEWS
/aclocal.m4
/autom4te.cache
-/build-aux
/build-aux/
/build/
/confdefs.h
@@ -197,6 +196,7 @@ stamp-h
stamp-h.in
stamp-h1
tags
+!/build-aux/*.pl
!/gnulib/lib/Makefile.am
!/gnulib/tests/Makefile.am
!/m4/virt-*.m4
--
2.7.3
8 years, 4 months
[libvirt] [PATCH v2 0/6] Add runnability info to query-cpu-definitions
by Eduardo Habkost
This series extends query-cpu-definitions to include an extra
field: "unavailable-features". The new field can be used to find
out reasons that prevent the CPU model from running in the
current host.
This will return information based on the current machine and
accelerator only. In the future we may extend these mechanisms to
allow querying other machines and other accelerators without
restarting QEMU, but it will require some reorganization of
QEMU's main code.
This series is based on my 'x86-next' branch, at:
git://github.com/ehabkost/qemu.git x86-next
Changes v1 -> v2:
* Fixed documentation to say "(since 2.7)"
* Removed @runnable field, improved documentation
Example command output:
{ "return": [
{
"unavailable-features": [ "kvm" ],
"name": "host"
},
{
"unavailable-features": [],
"name": "qemu64"
},
{
"unavailable-features": [],
"name": "qemu32"
},
{
"unavailable-features": ["npt", "fxsr-opt", "vme"],
"name": "phenom"
},
{
"unavailable-features": ["vme"],
"name": "pentium3"
},
{
"unavailable-features": ["vme"],
"name": "pentium2"
},
{
"unavailable-features": ["vme"],
"name": "pentium"
},
{
"unavailable-features": ["vme"],
"name": "n270"
},
{
"unavailable-features": ["vme"],
"name": "kvm64"
},
{
"unavailable-features": ["vme"],
"name": "kvm32"
},
{
"unavailable-features": ["vme"],
"name": "coreduo"
},
{
"unavailable-features": ["vme"],
"name": "core2duo"
},
{
"unavailable-features": ["vme"],
"name": "athlon"
},
{
"unavailable-features": ["vme"],
"name": "Westmere"
},
{
"unavailable-features": ["xsavec", "3dnowprefetch", "rdseed", "rtm", "invpcid", "erms", "avx2", "hle", "rdrand", "f16c", "avx", "tsc-deadline", "x2apic", "pcid", "fma", "vme"],
"name": "Skylake-Client"
},
{
"unavailable-features": ["avx", "tsc-deadline", "x2apic", "vme"],
"name": "SandyBridge"
},
{
"unavailable-features": ["vme"],
"name": "Penryn"
},
{
"unavailable-features": ["tbm", "fma4", "xop", "3dnowprefetch", "misalignsse", "f16c", "avx", "fma", "vme"],
"name": "Opteron_G5"
},
{
"unavailable-features": ["fma4", "xop", "3dnowprefetch", "misalignsse", "avx", "vme"],
"name": "Opteron_G4"
},
{
"unavailable-features": ["misalignsse", "vme"],
"name": "Opteron_G3"
},
{
"unavailable-features": ["vme"],
"name": "Opteron_G2"
},
{
"unavailable-features": ["vme"],
"name": "Opteron_G1"
},
{
"unavailable-features": ["vme"],
"name": "Nehalem"
},
{
"unavailable-features": ["erms", "rdrand", "f16c", "avx", "tsc-deadline", "x2apic", "vme"],
"name": "IvyBridge"
},
{
"unavailable-features": ["rtm", "invpcid", "erms", "avx2", "hle", "rdrand", "f16c", "avx", "tsc-deadline", "x2apic", "pcid", "fma", "vme"],
"name": "Haswell"
},
{
"unavailable-features": ["invpcid", "erms", "avx2", "rdrand", "f16c", "avx", "tsc-deadline", "x2apic", "pcid", "fma", "vme"],
"name": "Haswell-noTSX"
},
{
"unavailable-features": ["vme"],
"name": "Conroe"
},
{
"unavailable-features": ["3dnowprefetch", "rdseed", "rtm", "invpcid", "erms", "avx2", "hle", "rdrand", "f16c", "avx", "tsc-deadline", "x2apic", "pcid", "fma", "vme"],
"name": "Broadwell"
},
{
"unavailable-features": ["3dnowprefetch", "rdseed", "invpcid", "erms", "avx2", "rdrand", "f16c", "avx", "tsc-deadline", "x2apic", "pcid", "fma", "vme"],
"name": "Broadwell-noTSX"
},
{
"unavailable-features": ["vme"],
"name": "486"
}
]}
Cc: David Hildenbrand <dahi(a)linux.vnet.ibm.com>
Cc: Michael Mueller <mimu(a)linux.vnet.ibm.com>
Cc: Christian Borntraeger <borntraeger(a)de.ibm.com>
Cc: Cornelia Huck <cornelia.huck(a)de.ibm.com>
Cc: Jiri Denemark <jdenemar(a)redhat.com>
Cc: libvir-list(a)redhat.com
Eduardo Habkost (6):
target-i386: List CPU models using subclass list
target-i386: Move warning code outside x86_cpu_filter_features()
target-i386: Define CPUID filtering functions before x86_cpu_list()
qmp: Add runnability information to query-cpu-definitions
target-i386: Use "-" instead of "_" on all feature names
target-i386: Return runnability information on query-cpu-definitions
qapi-schema.json | 23 ++++-
target-i386/cpu-qom.h | 4 +
target-i386/cpu.c | 262 +++++++++++++++++++++++++++++++++++---------------
3 files changed, 209 insertions(+), 80 deletions(-)
--
2.5.5
8 years, 4 months
[libvirt] [PATCH] Allow virDomain(SG)etGuestVcpus on read-write connection only
by Peter Krempa
Guest agent interaction is considered privileged.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1349272
---
src/libvirt-domain.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/src/libvirt-domain.c b/src/libvirt-domain.c
index 508520e..2ca054a 100644
--- a/src/libvirt-domain.c
+++ b/src/libvirt-domain.c
@@ -11873,6 +11873,8 @@ virDomainGetGuestVcpus(virDomainPtr domain,
virResetLastError();
virCheckDomainReturn(domain, -1);
+ virCheckReadOnlyGoto(domain->conn->flags, error);
+
virCheckNonNullArgGoto(params, error);
virCheckNonNullArgGoto(nparams, error);
@@ -11929,6 +11931,8 @@ virDomainSetGuestVcpus(virDomainPtr domain,
virResetLastError();
virCheckDomainReturn(domain, -1);
+ virCheckReadOnlyGoto(domain->conn->flags, error);
+
virCheckNonNullArgGoto(cpumap, error);
if (domain->conn->driver->domainSetGuestVcpus) {
--
2.8.3
8 years, 4 months
Re: [libvirt] [RFC 00/28] s390x CPU models: exposing features
by Eduardo Habkost
(CCing libvirt people)
On Tue, Jun 21, 2016 at 03:02:05PM +0200, David Hildenbrand wrote:
> This is our second attempt to implement CPU models for s390x. We realized
> that we also want to have features exposed via the CPU model. While doing
> that we realized that we want to have a better interface for libvirt.
Before getting into the details, I would like to clarify how the
following could be accomplished using the new commands:
Example:
1) User configures libvirt with:
<cpu match='exact'>
<model fallback='forbid'>Westmere</model>
<feature policy='require' name='aes'/>
</cpu>
2) libvirt will translate that to:
"-cpu Westmere,+aes" or "-cpu Westmere,aes=on"
3) libvirt wants to know if "-cpu Westmere,aes=on" is usable in
the current host, before trying to start the VM.
How exactly would this be done using the new commands?
>
> Unfortunately, CPU models on s390x are special and we have to take care of:
> - A CPU like z13 looks differently in various environments (under different
> LPAR versions, under different z/VM versions, under different KVM
> versions, export regulation) - we have _a lot_ of feature variability.
> - We still have certain features that are not published but might be
> implemented/introduced in the future. As they are a theoretical part
> of a CPU already, we have to find a way to model these future changes.
> - We still have certain features that are already published, but not
> implemented. Implementation might be added in the future in KVM.
> - We heavily rely on KVM to tell us which features it can actually
> virtualize - user space queries like "STFL(e)" give no guarantees.
> - Certain "subfeatures" were introduced in one run. In practice, they are
> always around, but in theory, subfeatures could be dropped in the future.
> - Just because two CPU models have the same features doesn't mean they
> are equal - some internal numbers might be different. E.g. we won't allow
> running a z13 under a zBC12 just by turning off features.
> - We cannot blindly enable all possible features for a CPU generation,
> the IBC "Instruction Blocking Control" in KVM will try to block
> instructions introduced with certain features. So a CPU generation always
> has some maximum feature set that is guaranteed to work.
>
> It all boils down to a specific released CPU to have.
> a) A fixed feature set that we expect it to be have on every hypervisor.
> b) A variable part that depends on the hypervisor and that could be
> extended in the future (adding not yet implemented features) that we
> always want to enable later on.
> c) A variable part that we want to enable only if requested - nested
> virtualization ("vsie") and assists are one example.
>
> But, the fixed feature set is not really what we want to use as a default.
> It is just like a really minimum, stable base.
>
> So we have
> a) A "stable" CPU model for each released CPU that will never change and
> maps to the minimum feature set we expect to be around on all
> hypervisors. e.g. "z13-base" or "z10EC.2-base". These are migration
> safe.
> b) A "default" CPU model for each released CPU, that can change between
> QEMU versions and that will always include the features we expect to
> be around in our currently supported environments and will contain only
> features we expect to be stable. E.g. nested virtualization will not be
> contained in these models. These models are not migration safe, e.g
> "z13" or "z10EC.2". The feature set can differ between QEMU versions.
> c) An internal "maximum" CPU model for each generation that tells us which
> features were supported as a maximum back when the hardware was
> released. This will not be exposed
>
> To not have to replicate all CPU model changes ("new default fetaures") in
> libvirt, to not duplicate the logic about compatibility and the like,
> our approach tries to keep all the QEMU logic in libvirt and provide
> standardized interfaces for libvirt to e.g. baseline, compare. This
> allows libvirt to not have to care about any model names or feature names,
> it can just pass the data from interface to interface and report it to
> the user.
>
> Also, libvirt might want to know what the "host" model looks like and
> convert a CPU model to a migration safe variant. For this reason, a QMP
> command is added that can create a migration safe variant of a variable
> CPU model, indicating only the delta changes done to a stable model.
>
> So we have:
> a) "query-cpu-model-expansion" - tell us what the "host" or a migration
> unsafe model looks like. Either falling back to a stable model or
> completely exposing all properties. We are interested in stable models.
> b) "query-cpu-model-comparison" - tell us how two CPU models compare,
> indicating which properties were responsible for the decision.
> c) "query-cpu-model-baseline" - create a new model out of two models,
> taking a requested level of stability into account.
>
> As we are aware that e.g. x86 has their own idea of a CPU model and their
> existing implementation in place, but are also looking into to ways to e.g.
> expand the "host" CPU model to a detailed representation, we designed the
> "expansion" interface to also allow that.
>
> Comments are very welcome, but please always keep the restrictions and
> specialties in mind when suggesting some major design changes.
>
> The header update will be replaced by a kvm-next header update as soon as
> the VSIE patches are upstream. The major KVM interface changes are already
> part of kvm-next.
>
> The current state is available on git://github.com/cohuck/qemu on branch
> "cpumodel-s390x".
>
> David Hildenbrand (26):
> s390x/cpumodel: "host" and "qemu" as CPU subclasses
> s390x/cpumodel: expose CPU class properties
> s390x/cpumodel: generate CPU feature group lists
> s390x/cpumodel: introduce CPU feature group definitions
> s390x/cpumodel: register defined CPU models as subclasses
> s390x/cpumodel: store the CPU model in the CPU instance
> s390x/cpumodel: expose features and feature groups as properties
> s390x/cpumodel: let the CPU model handle feature checks
> s390x/cpumodel: check and apply the CPU model
> s390x/sclp: factor out preparation of cpu entries
> s390x/sclp: introduce sclp feature blocks
> s390x/sclp: indicate sclp features
> s390x/sclp: propagate the ibc val(lowest and unblocked ibc)
> s390x/sclp: propagate the mha via sclp
> s390x/sclp: propagate hmfai
> update linux headers (CPU model)
> s390x/kvm: allow runtime-instrumentation for "none" machine
> s390x/kvm: implement CPU model support
> s390x/kvm: disable host model for existing compat machines
> s390x/kvm: let the CPU model control CMM(A)
> qmp: add QMP interface "query-cpu-model-expansion"
> qmp: add QMP interface "query-cpu-model-comparison"
> qmp: add QMP interface "query-cpu-model-baseline"
> s390x/cpumodel: implement QMP interface "query-cpu-model-expansion"
> s390x/cpumodel: implement QMP interface "query-cpu-model-comparison"
> s390x/cpumodel: implement QMP interface "query-cpu-model-baseline"
>
> Michael Mueller (2):
> s390x/cpumodel: introduce CPU features
> s390x/cpumodel: generate CPU feature lists for CPU models
>
> Makefile.target | 2 +-
> hw/s390x/s390-virtio-ccw.c | 5 +
> hw/s390x/s390-virtio.c | 6 +-
> hw/s390x/sclp.c | 35 +-
> include/hw/s390x/sclp.h | 17 +-
> include/sysemu/arch_init.h | 10 +
> linux-headers/asm-s390/kvm.h | 40 ++
> qapi-schema.json | 184 ++++++
> qmp-commands.hx | 18 +
> qmp.c | 22 +
> rules.mak | 1 +
> stubs/Makefile.objs | 3 +
> stubs/arch-query-cpu-model-baseline.c | 13 +
> stubs/arch-query-cpu-model-comparison.c | 12 +
> stubs/arch-query-cpu-model-expansion.c | 12 +
> target-s390x/Makefile.objs | 22 +-
> target-s390x/cpu-qom.h | 5 +
> target-s390x/cpu.c | 35 +-
> target-s390x/cpu.h | 5 +
> target-s390x/cpu_features.c | 376 +++++++++++
> target-s390x/cpu_features.h | 302 +++++++++
> target-s390x/cpu_models.c | 1055 +++++++++++++++++++++++++++++++
> target-s390x/cpu_models.h | 113 ++++
> target-s390x/gen-features.c | 587 +++++++++++++++++
> target-s390x/helper.c | 29 +-
> target-s390x/kvm.c | 346 +++++++++-
> target-s390x/machine.c | 14 +-
> 27 files changed, 3203 insertions(+), 66 deletions(-)
> create mode 100644 stubs/arch-query-cpu-model-baseline.c
> create mode 100644 stubs/arch-query-cpu-model-comparison.c
> create mode 100644 stubs/arch-query-cpu-model-expansion.c
> create mode 100644 target-s390x/cpu_features.c
> create mode 100644 target-s390x/cpu_features.h
> create mode 100644 target-s390x/cpu_models.c
> create mode 100644 target-s390x/cpu_models.h
> create mode 100644 target-s390x/gen-features.c
>
> --
> 2.6.6
>
--
Eduardo
8 years, 4 months
[libvirt] [PATCH] libxl: use serial device for console when targetType is serial
by Jim Fehlig
When domXML contains only <console type='pty'> and no corresponding
<serial>, the console is "stolen" [1] and used as the first <serial>
device. When this "stolen" console is accessed from the libxl driver
(in libxlConsoleCallback and libxlDomainOpenConsole), check if the
targetType is VIR_DOMAIN_CHR_CONSOLE_TARGET_TYPE_SERIAL, and use the
"stolen" device in def->serials[0] instead. Prior to this change,
creating a domain with input XML containing only a <console> device
and subsequently attempting to access its console with
'virsh console' would fail
error: internal error: character device <null> is not using a PTY
[1] See comments associated with virDomainDefAddConsoleCompat() in
$LIBVIRT-SRC/src/conf/domain_conf.c:
Signed-off-by: Jim Fehlig <jfehlig(a)suse.com>
---
src/libxl/libxl_domain.c | 8 ++++++--
src/libxl/libxl_driver.c | 5 ++++-
2 files changed, 10 insertions(+), 3 deletions(-)
diff --git a/src/libxl/libxl_domain.c b/src/libxl/libxl_domain.c
index 221af87..6bcb4d9 100644
--- a/src/libxl/libxl_domain.c
+++ b/src/libxl/libxl_domain.c
@@ -964,13 +964,17 @@ libxlConsoleCallback(libxl_ctx *ctx, libxl_event *ev, void *for_callback)
virObjectLock(vm);
for (i = 0; i < vm->def->nconsoles; i++) {
virDomainChrDefPtr chr = vm->def->consoles[i];
- if (chr && chr->source.type == VIR_DOMAIN_CHR_TYPE_PTY) {
+ if (i == 0 &&
+ chr->targetType == VIR_DOMAIN_CHR_CONSOLE_TARGET_TYPE_SERIAL)
+ chr = vm->def->serials[0];
+
+ if (chr->source.type == VIR_DOMAIN_CHR_TYPE_PTY) {
libxl_console_type console_type;
char *console = NULL;
int ret;
console_type =
- (chr->targetType == VIR_DOMAIN_CHR_CONSOLE_TARGET_TYPE_SERIAL ?
+ (chr->deviceType == VIR_DOMAIN_CHR_DEVICE_TYPE_SERIAL ?
LIBXL_CONSOLE_TYPE_SERIAL : LIBXL_CONSOLE_TYPE_PV);
ret = libxl_console_get_tty(ctx, ev->domid,
chr->target.port, console_type,
diff --git a/src/libxl/libxl_driver.c b/src/libxl/libxl_driver.c
index c8c1f07..3189f1c 100644
--- a/src/libxl/libxl_driver.c
+++ b/src/libxl/libxl_driver.c
@@ -4443,8 +4443,11 @@ libxlDomainOpenConsole(virDomainPtr dom,
priv = vm->privateData;
- if (vm->def->nconsoles)
+ if (vm->def->nconsoles) {
chr = vm->def->consoles[0];
+ if (chr->targetType == VIR_DOMAIN_CHR_CONSOLE_TARGET_TYPE_SERIAL)
+ chr = vm->def->serials[0];
+ }
if (!chr) {
virReportError(VIR_ERR_INTERNAL_ERROR,
--
2.1.4
8 years, 4 months
[libvirt] [PATCH] conf: Remove dead console compat formatting
by Cole Robinson
This code was attempting to handle some implicit <console> XML
formatting for manually assembled DomainDef, since previously the
console<->serial compat copying was only done at XML parse time.
Nowadays it's done via virDomainDefPostParse ->
virDomainDefAddConsoleCompat, which all manual DomainDef builders
already call, so we can drop this workaround.
---
src/conf/domain_conf.c | 14 --------------
1 file changed, 14 deletions(-)
diff --git a/src/conf/domain_conf.c b/src/conf/domain_conf.c
index 75ad03f..6ab7450 100644
--- a/src/conf/domain_conf.c
+++ b/src/conf/domain_conf.c
@@ -23463,20 +23463,6 @@ virDomainDefFormatInternal(virDomainDefPtr def,
if (virDomainChrDefFormat(buf, &console, flags) < 0)
goto error;
}
- /* The back-compat console device stub is added when parsing the domain XML
- * and handled above, this is for formatting definitions created via other
- * means.
- */
- if (def->os.type == VIR_DOMAIN_OSTYPE_HVM &&
- def->nconsoles == 0 &&
- def->nserials > 0) {
- virDomainChrDef console;
- memcpy(&console, def->serials[n], sizeof(console));
- console.deviceType = VIR_DOMAIN_CHR_DEVICE_TYPE_CONSOLE;
- console.targetType = VIR_DOMAIN_CHR_CONSOLE_TARGET_TYPE_SERIAL;
- if (virDomainChrDefFormat(buf, &console, flags) < 0)
- goto error;
- }
for (n = 0; n < def->nchannels; n++)
if (virDomainChrDefFormat(buf, def->channels[n], flags) < 0)
--
2.7.4
8 years, 4 months
[libvirt] [PATCH RFC] libxl: set serial source path for console type=serial
by Joao Martins
Guests use a <console /> (and sometimes <serial /> pair) to represent
the console. On the callback that is called when console is brought up
(NB: before domain starts), we fill the path of the console element with
the appropriate "/dev/pts/X". For PV guests it all works fine, although
for HVM guests it doesn't. Consequently we end up seeing erronous
behaviour on HVM guests where console path is not displayed on the XML
but still can be accessed with virDomainOpenConsole after booting guest.
Consumers of this XML (e.g. Openstack) also won't be able to use the
console path. Finally, the path set in consoles array won't persist
across daemon reboots, thus rendering admins/users with no access to
console with a message such as:
"error: operation failed: PTY device is not yet assigned"
This is because: for HVM guests, DefFormatInternal will ignore the
console element and instead write it with the content of the serial
element for target type = serial which isn't touched in our
libxlConsoleCallback. To address that we introduce a new helper routine
libxlConsoleSetSourcePath() that sets the source path and thus also
handling this case. That is by setting the source path on with serial
element akin to the one indexed by console "port". This way we keep
similar behaviour for PV and HVM guests.
Signed-off-by: Joao Martins <joao.m.martins(a)oracle.com>
---
src/libxl/libxl_domain.c | 35 +++++++++++++++++++++++++++++++----
1 file changed, 31 insertions(+), 4 deletions(-)
diff --git a/src/libxl/libxl_domain.c b/src/libxl/libxl_domain.c
index 221af87..4a46143 100644
--- a/src/libxl/libxl_domain.c
+++ b/src/libxl/libxl_domain.c
@@ -955,6 +955,35 @@ libxlNetworkPrepareDevices(virDomainDefPtr def)
return 0;
}
+static int
+libxlConsoleSetSourcePath(virDomainDefPtr def, virDomainChrDefPtr console,
+ char *path)
+{
+ int ret = -1;
+ size_t i;
+
+ if (!path || path[0] == '\0')
+ return ret;
+
+ if (VIR_STRDUP(console->source.data.file.path, path) < 0)
+ return ret;
+
+ if (console->targetType != VIR_DOMAIN_CHR_CONSOLE_TARGET_TYPE_SERIAL)
+ return 0;
+
+ for (i = 0; i < def->nserials; i++) {
+ virDomainChrDefPtr serial = def->serials[i];
+
+ if (serial->target.port == console->target.port &&
+ VIR_STRDUP(serial->source.data.file.path, path) >= 0) {
+ ret = 0;
+ break;
+ }
+ }
+
+ return ret;
+}
+
static void
libxlConsoleCallback(libxl_ctx *ctx, libxl_event *ev, void *for_callback)
{
@@ -977,10 +1006,8 @@ libxlConsoleCallback(libxl_ctx *ctx, libxl_event *ev, void *for_callback)
&console);
if (!ret) {
VIR_FREE(chr->source.data.file.path);
- if (console && console[0] != '\0') {
- ignore_value(VIR_STRDUP(chr->source.data.file.path,
- console));
- }
+ if (libxlConsoleSetSourcePath(vm->def, chr, console) < 0)
+ VIR_WARN("Failed to set console source path");
}
VIR_FREE(console);
}
--
2.1.4
8 years, 4 months
