[libvirt] [PATCH v4 03/25] [NEW] qemu: replace "def->nets[i]" with "net" and "def->sounds[i]" with "sound"

2016-10-14 Thread Laine Stump
More occurences of repeatedly dereferencing the same pointer stored in
an array are replaced with the definition of a temporary pointer that
is then used directly. No functional change.
---
 src/qemu/qemu_domain_address.c | 41 +++--
 1 file changed, 23 insertions(+), 18 deletions(-)

diff --git a/src/qemu/qemu_domain_address.c b/src/qemu/qemu_domain_address.c
index e6abadf..d2a3237 100644
--- a/src/qemu/qemu_domain_address.c
+++ b/src/qemu/qemu_domain_address.c
@@ -211,11 +211,12 @@ qemuDomainAssignSpaprVIOAddresses(virDomainDefPtr def,
 /* Default values match QEMU. See spapr_(llan|vscsi|vty).c */
 
 for (i = 0; i < def->nnets; i++) {
-if (def->nets[i]->model &&
-STREQ(def->nets[i]->model, "spapr-vlan"))
-def->nets[i]->info.type = VIR_DOMAIN_DEVICE_ADDRESS_TYPE_SPAPRVIO;
-if (qemuDomainAssignSpaprVIOAddress(def, >nets[i]->info,
-VIO_ADDR_NET) < 0)
+virDomainNetDefPtr net = def->nets[i];
+
+if (net->model &&
+STREQ(net->model, "spapr-vlan"))
+net->info.type = VIR_DOMAIN_DEVICE_ADDRESS_TYPE_SPAPRVIO;
+if (qemuDomainAssignSpaprVIOAddress(def, >info, VIO_ADDR_NET) < 0)
 goto cleanup;
 }
 
@@ -283,9 +284,11 @@ qemuDomainPrimeVirtioDeviceAddresses(virDomainDefPtr def,
 }
 
 for (i = 0; i < def->nnets; i++) {
-if (STREQ(def->nets[i]->model, "virtio") &&
-def->nets[i]->info.type == VIR_DOMAIN_DEVICE_ADDRESS_TYPE_NONE) {
-def->nets[i]->info.type = type;
+virDomainNetDefPtr net = def->nets[i];
+
+if (STREQ(net->model, "virtio") &&
+net->info.type == VIR_DOMAIN_DEVICE_ADDRESS_TYPE_NONE) {
+net->info.type = type;
 }
 }
 
@@ -1049,31 +1052,33 @@ qemuDomainAssignDevicePCISlots(virDomainDefPtr def,
 
 /* Network interfaces */
 for (i = 0; i < def->nnets; i++) {
+virDomainNetDefPtr net = def->nets[i];
+
 /* type='hostdev' network devices might be USB, and are also
  * in hostdevs list anyway, so handle them with other hostdevs
  * instead of here.
  */
-if ((def->nets[i]->type == VIR_DOMAIN_NET_TYPE_HOSTDEV) ||
-!virDeviceInfoPCIAddressWanted(>nets[i]->info)) {
+if ((net->type == VIR_DOMAIN_NET_TYPE_HOSTDEV) ||
+!virDeviceInfoPCIAddressWanted(>info)) {
 continue;
 }
-if (virDomainPCIAddressReserveNextSlot(addrs, >nets[i]->info,
-   flags) < 0)
+if (virDomainPCIAddressReserveNextSlot(addrs, >info, flags) < 0)
 goto error;
 }
 
 /* Sound cards */
 for (i = 0; i < def->nsounds; i++) {
-if (!virDeviceInfoPCIAddressWanted(>sounds[i]->info))
+virDomainSoundDefPtr sound = def->sounds[i];
+
+if (!virDeviceInfoPCIAddressWanted(>info))
 continue;
 /* Skip ISA sound card, PCSPK and usb-audio */
-if (def->sounds[i]->model == VIR_DOMAIN_SOUND_MODEL_SB16 ||
-def->sounds[i]->model == VIR_DOMAIN_SOUND_MODEL_PCSPK ||
-def->sounds[i]->model == VIR_DOMAIN_SOUND_MODEL_USB)
+if (sound->model == VIR_DOMAIN_SOUND_MODEL_SB16 ||
+sound->model == VIR_DOMAIN_SOUND_MODEL_PCSPK ||
+sound->model == VIR_DOMAIN_SOUND_MODEL_USB)
 continue;
 
-if (virDomainPCIAddressReserveNextSlot(addrs, >sounds[i]->info,
-   flags) < 0)
+if (virDomainPCIAddressReserveNextSlot(addrs, >info, flags) < 0)
 goto error;
 }
 
-- 
2.7.4

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list


[libvirt] [PATCH v4 00/25] Use more PCIe less legacy PCI

2016-10-14 Thread Laine Stump
The latest version of patches to auto-assign appropriate devices in
PCIe-capable domains to PCIe slots rather than legacy PCI, and to also
auto-add pcie-root-ports as necessary to make this easier.

I *think* I've dealt with all of Andrea's great critiques of V3,
either in my email responses or in these revised patches. Aside from
fixing typos and formatting problems, I also moved several "little
cosmetic fixes" out of the bigger functionality-changing patches, and
also split out the most confusing part of patch 20 (previously patch
15 - the one that auto-adds pcie-root-port and dmi-to-pci-bridge
controllers) into its own patch (doubly useful since the value of that
part of the patch is dubious - it is now the [RFC] patch 21)

As many of the simple costmetic patches as possible were pushed up to
the front of the series (if they weren't already there). If those are
ACKed on this round but others aren't, I'll push them immediately so I
don't need to resubmit the whole series again.

Some of these patches were ACKed last time, but I either had to change
them further due to changes in other patches, or I couldn't push them
because they have prerequisites that weren't ACKed. I've marked those
in the subject line (I've also marked entirely new patches in the
subject line).

Laine Stump (25):
  qemu: new functions qemuDomainMachineHasPCI[e]Root()
  qemu: replace a lot of "def->controllers[i]" with equivalent "cont"
  qemu: replace "def->nets[i]" with "net" and "def->sounds[i]" with
"sound"
  conf: add typedef for anonymous enum used for memballoon device model
  qemu: remove superfluous setting of addrs->nbuses
  qemu: make error message in qemuDomainPCIAddressSetCreate more clear.
  qemu: change first arg of qemuDomainAttachChrDeviceAssignAddr()
  conf: new function virDomainPCIAddressReserveNextAddr()
  qemu: use virDomainPCIAddressReserveNextAddr in
qemuDomainAssignDevicePCISlots
  conf: make virDomainPCIAddressGetNextSlot() a local static function
  qemu: replace calls to virDomainPCIAddressReserveNext*() with static
function
  qemu: new functions to calculate/set device pciConnectFlags
  qemu: set/use info->pciConnectFlags when validating/assigning PCI
addresses
  qemu: set/use proper pciConnectFlags during hotplug
  qemu: set pciConnectFlags to 0 instead of PCI|HOTPLUGGABLE if device
isn't PCI
  qemu: assign virtio devices to PCIe slot when appropriate
  qemu: assign e1000e network devices to PCIe slots when appropriate
  qemu: assign nec-xhci (USB3) controller to a PCIe address when
appropriate
  qemu: only force an available legacy-PCI slot on domains with pci-root
  qemu: auto-add pcie-root-port/dmi-to-pci-bridge controllers as needed
  [RFC] qemu: if pci-bridge is in PCIe config w/o dmi-to-pci-bridge, add
it
  qemu: don't force-add a dmi-to-pci-bridge just on principle
  qemu: add a USB3 controller to Q35 domains by default
  qemu: try to put ich9 sound device at 00:1B.0
  qemu: initially reserve one open pcie-root-port for hotplug

 src/conf/device_conf.h |5 +
 src/conf/domain_addr.c |  163 ++-
 src/conf/domain_addr.h |   11 +-
 src/conf/domain_conf.h |4 +-
 src/libvirt_private.syms   |2 +-
 src/qemu/qemu_domain.c |   52 +-
 src/qemu/qemu_domain.h |2 +
 src/qemu/qemu_domain_address.c | 1097 +++-
 src/qemu/qemu_domain_address.h |4 +
 src/qemu/qemu_hotplug.c|   27 +-
 tests/qemuxml2argvdata/qemuxml2argv-autoindex.args |   10 +-
 .../qemuxml2argv-bios-nvram-secure.args|1 +
 .../qemuxml2argv-machine-smm-opt.args  |1 +
 tests/qemuxml2argvdata/qemuxml2argv-pcie-root.args |3 +-
 .../qemuxml2argv-q35-default-devices-only.args |   23 +
 .../qemuxml2argv-q35-default-devices-only.xml  |   18 +
 .../qemuxml2argv-q35-pcie-autoadd.args |   57 +
 .../qemuxml2argv-q35-pcie-autoadd.xml  |   51 +
 tests/qemuxml2argvdata/qemuxml2argv-q35-pcie.args  |   58 ++
 tests/qemuxml2argvdata/qemuxml2argv-q35-pcie.xml   |   67 ++
 .../qemuxml2argv-q35-pm-disable-fallback.args  |1 +
 .../qemuxml2argv-q35-pm-disable.args   |1 +
 .../qemuxml2argv-q35-virt-manager-basic.args   |   56 +
 .../qemuxml2argv-q35-virt-manager-basic.xml|   76 ++
 .../qemuxml2argv-q35-virtio-pci.args   |   58 ++
 .../qemuxml2argv-q35-virtio-pci.xml|1 +
 tests/qemuxml2argvtest.c   |  164 ++-
 .../qemuxml2xmlout-autoindex.xml   |   10 +-
 .../qemuxml2xmlout-pcie-root.xml   |4 -
 .../qemuxml2xmlout-q35-default-devices-only.xml|   45 +
 .../qemuxml2xmlout-q35-pcie-autoadd.xml|  148 +++
 .../qemuxml2xmloutdata/qemuxml2xmlout-q35-pcie.xml 

[libvirt] [PATCH v4 11/25] [ACKED] qemu: replace calls to virDomainPCIAddressReserveNext*() with static function

2016-10-14 Thread Laine Stump
An upcoming commit will remove the "flag" argument from all the calls
to reserve the next available address|slot, but I don't want to change
the arguments in the hypervisor-agnostic
virDomainPCIAddressReserveNext*() functions, so this patch places a
simple qemu-specific wrapper around those functions - the new
functions don't take a flags arg, but grab it from the device's
info->pciConnectFlags.
---
Change: realigned/reformatted

 src/qemu/qemu_domain_address.c | 96 ++
 1 file changed, 59 insertions(+), 37 deletions(-)

diff --git a/src/qemu/qemu_domain_address.c b/src/qemu/qemu_domain_address.c
index fa52383..b4ea906 100644
--- a/src/qemu/qemu_domain_address.c
+++ b/src/qemu/qemu_domain_address.c
@@ -406,6 +406,27 @@ qemuDomainAssignARMVirtioMMIOAddresses(virDomainDefPtr def,
 
 
 static int
+qemuDomainPCIAddressReserveNextAddr(virDomainPCIAddressSetPtr addrs,
+virDomainDeviceInfoPtr dev,
+virDomainPCIConnectFlags flags,
+unsigned int function,
+bool reserveEntireSlot)
+{
+return virDomainPCIAddressReserveNextAddr(addrs, dev, flags,
+  function, reserveEntireSlot);
+}
+
+
+static int
+qemuDomainPCIAddressReserveNextSlot(virDomainPCIAddressSetPtr addrs,
+virDomainDeviceInfoPtr dev,
+virDomainPCIConnectFlags flags)
+{
+return qemuDomainPCIAddressReserveNextAddr(addrs, dev, flags, 0, true);
+}
+
+
+static int
 qemuDomainCollectPCIAddress(virDomainDefPtr def ATTRIBUTE_UNUSED,
 virDomainDeviceDefPtr device,
 virDomainDeviceInfoPtr info,
@@ -691,7 +712,7 @@ qemuDomainValidateDevicePCISlotsPIIX3(virDomainDefPtr def,
 
 if (virDomainPCIAddressSlotInUse(addrs, _addr)) {
 if (qemuDeviceVideoUsable) {
-if (virDomainPCIAddressReserveNextSlot(addrs,
+if (qemuDomainPCIAddressReserveNextSlot(addrs,
>info,
flags) < 0)
 goto cleanup;
@@ -882,7 +903,7 @@ qemuDomainValidateDevicePCISlotsQ35(virDomainDefPtr def,
 
 if (virDomainPCIAddressSlotInUse(addrs, _addr)) {
 if (qemuDeviceVideoUsable) {
-if (virDomainPCIAddressReserveNextSlot(addrs,
+if (qemuDomainPCIAddressReserveNextSlot(addrs,
>info,
flags) < 0)
 goto cleanup;
@@ -919,7 +940,8 @@ qemuDomainValidateDevicePCISlotsQ35(virDomainDefPtr def,
   " device will not be possible without manual"
   " intervention");
 virResetLastError();
-} else if (virDomainPCIAddressReserveSlot(addrs, _addr, flags) < 
0) {
+} else if (virDomainPCIAddressReserveSlot(addrs,
+  _addr, flags) < 0) {
 goto cleanup;
 }
 }
@@ -1023,8 +1045,8 @@ qemuDomainAssignDevicePCISlots(virDomainDefPtr def,
  * controller/bus to connect it to on the upstream side.
  */
 flags = virDomainPCIControllerModelToConnectType(model);
-if (virDomainPCIAddressReserveNextSlot(addrs,
-   >info, flags) < 0) {
+if (qemuDomainPCIAddressReserveNextSlot(addrs,
+>info, flags) < 0) {
 goto error;
 }
 }
@@ -1043,8 +1065,8 @@ qemuDomainAssignDevicePCISlots(virDomainDefPtr def,
 
 /* Only support VirtIO-9p-pci so far. If that changes,
  * we might need to skip devices here */
-if (virDomainPCIAddressReserveNextSlot(addrs, >fss[i]->info,
-   flags) < 0)
+if (qemuDomainPCIAddressReserveNextSlot(addrs, >fss[i]->info,
+flags) < 0)
 goto error;
 }
 
@@ -1060,7 +1082,7 @@ qemuDomainAssignDevicePCISlots(virDomainDefPtr def,
 !virDeviceInfoPCIAddressWanted(>info)) {
 continue;
 }
-if (virDomainPCIAddressReserveNextSlot(addrs, >info, flags) < 0)
+if (qemuDomainPCIAddressReserveNextSlot(addrs, >info, flags) < 0)
 goto error;
 }
 
@@ -1076,7 +1098,7 @@ qemuDomainAssignDevicePCISlots(virDomainDefPtr def,
 sound->model == VIR_DOMAIN_SOUND_MODEL_USB)
 continue;
 
-if (virDomainPCIAddressReserveNextSlot(addrs, >info, flags) < 0)
+if (qemuDomainPCIAddressReserveNextSlot(addrs, >info, flags) < 
0)
 

[libvirt] [PATCH v4 20/25] qemu: auto-add pcie-root-port/dmi-to-pci-bridge controllers as needed

2016-10-14 Thread Laine Stump
Previously libvirt would only add pci-bridge devices automatically
when an address was requested for a device that required a legacy PCI
slot and none was available. This patch expands that support to
dmi-to-pci-bridge (which is needed in order to add a pci-bridge on a
machine with a pcie-root), and pcie-root-port (which is needed to add
a hotpluggable PCIe device). It does *not* automatically add
pcie-switch-upstream-ports or pcie-switch-downstream-ports (and
currently there are no plans for that).

Given the existing code to auto-add pci-bridge devices, automatically
adding pcie-root-ports is fairly straightforward. The
dmi-to-pci-bridge support is a bit tricky though, for a few reasons:

1) Although the only reason to add a dmi-to-pci-bridge is so that
   there is a reasonable place to plug in a pci-bridge controller,
   most of the time it's not the presence of a pci-bridge *in the
   config* that triggers the requirement to add a dmi-to-pci-bridge.
   Rather, it is the presence of a legacy-PCI device in the config,
   which triggers auto-add of a pci-bridge, which triggers auto-add of
   a dmi-to-pci-bridge (this is handled in
   virDomainPCIAddressSetGrow() - if there's a request to add a
   pci-bridge we'll check if there is a suitable bus to plug it into;
   if not, we first add a dmi-to-pci-bridge).

2) Once there is already a single dmi-to-pci-bridge on the system,
   there won't be a need for any more, even if it's full, as long as
   there is a pci-bridge with an open slot - you can also plug
   pci-bridges into existing pci-bridges. So we have to make sure we
   don't add a dmi-to-pci-bridge unless there aren't any
   dmi-to-pci-bridges *or* any pci-bridges.

3) Although it is strongly discouraged, it is legal for a pci-bridge
   to be directly plugged into pcie-root, and we don't want to
   auto-add a dmi-to-pci-bridge if there is already a pci-bridge
   that's been forced directly into pcie-root.

Although libvirt will now automatically create a dmi-to-pci-bridge
when it's needed, the code still remains for now that forces a
dmi-to-pci-bridge on all domains with pcie-root (in
qemuDomainDefAddDefaultDevices()). That will be removed in the next
patch.

For now, the pcie-root-ports are added one to a slot, which is a bit
wasteful and means it will fail after 31 total PCIe devices (30 if
there are also some PCI devices), but helps keep the changeset down
for this patch. A future patch will have 8 pcie-root-ports sharing the
functions on a single slot.
---

Change: split out special code to add dmi-to-pci-bridge if config has
a pci-bridge without a dmi-to-pci-bridge (now in RFC patch 21)

 src/conf/domain_addr.c |  96 +++---
 src/qemu/qemu_domain_address.c |  55 +---
 .../qemuxml2argv-q35-pcie-autoadd.args |  57 
 .../qemuxml2argv-q35-pcie-autoadd.xml  |  51 +++
 tests/qemuxml2argvtest.c   |  24 
 .../qemuxml2xmlout-q35-pcie-autoadd.xml| 147 +
 tests/qemuxml2xmltest.c|  25 +++-
 7 files changed, 421 insertions(+), 34 deletions(-)
 create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-q35-pcie-autoadd.args
 create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-q35-pcie-autoadd.xml
 create mode 100644 tests/qemuxml2xmloutdata/qemuxml2xmlout-q35-pcie-autoadd.xml

diff --git a/src/conf/domain_addr.c b/src/conf/domain_addr.c
index e25a63f..7a7fd00 100644
--- a/src/conf/domain_addr.c
+++ b/src/conf/domain_addr.c
@@ -82,6 +82,30 @@ 
virDomainPCIControllerModelToConnectType(virDomainControllerModelPCI model)
 return 0;
 }
 
+
+static int
+virDomainPCIControllerConnectTypeToModel(virDomainPCIConnectFlags flags)
+{
+if (flags & VIR_PCI_CONNECT_TYPE_PCIE_ROOT_PORT)
+return VIR_DOMAIN_CONTROLLER_MODEL_PCIE_ROOT_PORT;
+if (flags & VIR_PCI_CONNECT_TYPE_PCIE_SWITCH_UPSTREAM_PORT)
+return VIR_DOMAIN_CONTROLLER_MODEL_PCIE_SWITCH_UPSTREAM_PORT;
+if (flags & VIR_PCI_CONNECT_TYPE_PCIE_SWITCH_DOWNSTREAM_PORT)
+return VIR_DOMAIN_CONTROLLER_MODEL_PCIE_SWITCH_DOWNSTREAM_PORT;
+if (flags & VIR_PCI_CONNECT_TYPE_DMI_TO_PCI_BRIDGE)
+return VIR_DOMAIN_CONTROLLER_MODEL_DMI_TO_PCI_BRIDGE;
+if (flags & VIR_PCI_CONNECT_TYPE_PCI_EXPANDER_BUS)
+return VIR_DOMAIN_CONTROLLER_MODEL_PCI_EXPANDER_BUS;
+if (flags & VIR_PCI_CONNECT_TYPE_PCIE_EXPANDER_BUS)
+return VIR_DOMAIN_CONTROLLER_MODEL_PCIE_EXPANDER_BUS;
+if (flags & VIR_PCI_CONNECT_TYPE_PCI_BRIDGE)
+return VIR_DOMAIN_CONTROLLER_MODEL_PCI_BRIDGE;
+
+/* some connect types don't correspond to a controller model */
+return -1;
+}
+
+
 bool
 virDomainPCIAddressFlagsCompatible(virPCIDeviceAddressPtr addr,
const char *addrStr,
@@ -332,10 +356,7 @@ virDomainPCIAddressBusSetModel(virDomainPCIAddressBusPtr 
bus,
 }
 
 
-/* Ensure addr fits in the address set, by 

[libvirt] [PATCH v4 24/25] [ACKED] qemu: try to put ich9 sound device at 00:1B.0

2016-10-14 Thread Laine Stump
Real Q35 hardware has an ICH9 chip that includes several integrated
devices at particular addresses (see the file docs/q35-chipset.cfg in
the qemu source). libvirt already attempts to put the first two sets
of ich9 USB2 controllers it finds at 00:1D.* and 00:1A.* to match the
real hardware. This patch does the same for the ich9 "HD audio"
device.

The main inspiration for this patch is that currently the *only*
device in a reasonable "workstation" type virtual machine config that
requires a legacy PCI slot is the audio device, Without this patch,
the standard Q35 machine created by virt-manager will have a
dmi-to-pci-bridge and a pci-bridge just for the sound device; with the
patch (and if you change the sound device model from the default
"ich6" to "ich9"), the machine definition constructed by virt-manager
has absolutely no legacy PCI controllers - any legacy PCI devices
(e.g. video and sound) are on pcie-root as integrated devices.
---

Change: continue instead of break, as suggested by Andrea.

 src/qemu/qemu_domain_address.c |  26 +
 .../qemuxml2argv-q35-virt-manager-basic.args   |  55 ++
 .../qemuxml2argv-q35-virt-manager-basic.xml|  76 ++
 tests/qemuxml2argvtest.c   |  34 ++
 .../qemuxml2xmlout-q35-virt-manager-basic.xml  | 116 +
 tests/qemuxml2xmltest.c|  24 +
 6 files changed, 331 insertions(+)
 create mode 100644 
tests/qemuxml2argvdata/qemuxml2argv-q35-virt-manager-basic.args
 create mode 100644 
tests/qemuxml2argvdata/qemuxml2argv-q35-virt-manager-basic.xml
 create mode 100644 
tests/qemuxml2xmloutdata/qemuxml2xmlout-q35-virt-manager-basic.xml

diff --git a/src/qemu/qemu_domain_address.c b/src/qemu/qemu_domain_address.c
index e81d212..8c4a5de 100644
--- a/src/qemu/qemu_domain_address.c
+++ b/src/qemu/qemu_domain_address.c
@@ -1343,6 +1343,32 @@ qemuDomainValidateDevicePCISlotsQ35(virDomainDefPtr def,
 goto cleanup;
 }
 }
+
+memset(_addr, 0, sizeof(tmp_addr));
+tmp_addr.slot = 0x1B;
+if (!virDomainPCIAddressSlotInUse(addrs, _addr)) {
+/* Since real Q35 hardware has an ICH9 chip that has an
+ * integrated HD audio device at :00:1B.0 put any
+ * unaddressed ICH9 audio device at that address if it's not
+ * already taken. If there's something already there, let the
+ * normal device addressing assign something later.
+ */
+for (i = 0; i < def->nsounds; i++) {
+virDomainSoundDefPtr sound = def->sounds[i];
+
+if (sound->model != VIR_DOMAIN_SOUND_MODEL_ICH9 ||
+!virDeviceInfoPCIAddressWanted(>info)) {
+continue;
+}
+if (virDomainPCIAddressReserveSlot(addrs, _addr, flags) < 0)
+goto cleanup;
+
+sound->info.type = VIR_DOMAIN_DEVICE_ADDRESS_TYPE_PCI;
+sound->info.addr.pci = tmp_addr;
+break;
+}
+}
+
 ret = 0;
  cleanup:
 VIR_FREE(addrStr);
diff --git a/tests/qemuxml2argvdata/qemuxml2argv-q35-virt-manager-basic.args 
b/tests/qemuxml2argvdata/qemuxml2argv-q35-virt-manager-basic.args
new file mode 100644
index 000..d3217d5
--- /dev/null
+++ b/tests/qemuxml2argvdata/qemuxml2argv-q35-virt-manager-basic.args
@@ -0,0 +1,55 @@
+LC_ALL=C \
+PATH=/bin \
+HOME=/home/test \
+USER=test \
+LOGNAME=test \
+QEMU_AUDIO_DRV=spice \
+/usr/bin/qemu-system_x86_64 \
+-name virt-manager-basic \
+-S \
+-M pc-q35-2.7 \
+-m 4096 \
+-smp 2,sockets=2,cores=1,threads=1 \
+-uuid 1b826c23-8767-47ad-a6b5-c83a88277f71 \
+-nodefaults \
+-monitor unix:/tmp/lib/domain--1-virt-manager-basic/monitor.sock,server,nowait 
\
+-rtc base=utc,driftfix=slew \
+-no-kvm-pit-reinjection \
+-global ICH9-LPC.disable_s3=1 \
+-global ICH9-LPC.disable_s4=1 \
+-boot c \
+-device ioh3420,port=0x10,chassis=1,id=pci.1,bus=pcie.0,addr=0x2 \
+-device ioh3420,port=0x18,chassis=2,id=pci.2,bus=pcie.0,addr=0x3 \
+-device ioh3420,port=0x20,chassis=3,id=pci.3,bus=pcie.0,addr=0x4 \
+-device ioh3420,port=0x28,chassis=4,id=pci.4,bus=pcie.0,addr=0x5 \
+-device ioh3420,port=0x30,chassis=5,id=pci.5,bus=pcie.0,addr=0x6 \
+-device nec-usb-xhci,id=usb,bus=pci.2,addr=0x0 \
+-device virtio-serial-pci,id=virtio-serial0,bus=pci.3,addr=0x0 \
+-drive file=/var/lib/libvirt/images/basic.qcow2,format=qcow2,if=none,\
+id=drive-virtio-disk0 \
+-device virtio-blk-pci,bus=pci.4,addr=0x0,drive=drive-virtio-disk0,\
+id=virtio-disk0 \
+-netdev user,id=hostnet0 \
+-device 
virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:9a:e6:c6,bus=pci.1,\
+addr=0x0 \
+-serial pty \
+-chardev socket,id=charchannel0,\
+path=/tmp/channel/domain--1-virt-manager-basic/org.qemu.guest_agent.0,server,\
+nowait \
+-device virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,\
+id=channel0,name=org.qemu.guest_agent.0 \
+-chardev spicevmc,id=charchannel1,name=vdagent \
+-device 

[libvirt] [PATCH v4 23/25] [ACKED] qemu: add a USB3 controller to Q35 domains by default

2016-10-14 Thread Laine Stump
Previously we added a set of EHCI+UHCI controllers to Q35 machines to
mimic real hardware as closely as possible, but recent discussions
have pointed out that the nec-usb-xhci (USB3) controller is much more
virtualization-friendly (uses less CPU), so this patch switches the
default for Q35 machinetypes to add an XHCI instead (if it's
supported, which it of course *will* be).

Since none of the existing test cases left out USB controllers in the
input XML, a new Q35 test case was added which has *no* devices, so
ends up with only the defaults always put in by qemu, plus those added
by libvirt.
---
 src/qemu/qemu_domain.c | 10 --
 .../qemuxml2argv-q35-default-devices-only.args | 22 
 .../qemuxml2argv-q35-default-devices-only.xml  | 18 ++
 tests/qemuxml2argvtest.c   | 23 +
 .../qemuxml2xmlout-q35-default-devices-only.xml| 40 ++
 tests/qemuxml2xmltest.c| 23 +
 6 files changed, 133 insertions(+), 3 deletions(-)
 create mode 100644 
tests/qemuxml2argvdata/qemuxml2argv-q35-default-devices-only.args
 create mode 100644 
tests/qemuxml2argvdata/qemuxml2argv-q35-default-devices-only.xml
 create mode 100644 
tests/qemuxml2xmloutdata/qemuxml2xmlout-q35-default-devices-only.xml

diff --git a/src/qemu/qemu_domain.c b/src/qemu/qemu_domain.c
index bd5c7ec..b00e7c3 100644
--- a/src/qemu/qemu_domain.c
+++ b/src/qemu/qemu_domain.c
@@ -1976,10 +1976,14 @@ qemuDomainDefAddDefaultDevices(virDomainDefPtr def,
 addPCIeRoot = true;
 addImplicitSATA = true;
 
-/* add a USB2 controller set, but only if the
- * ich9-usb-ehci1 device is supported
+/* Prefer adding USB3 controller if supported
+ * (nec-usb-xhci). Failing that, add a USB2 controller set
+ * if the ich9-usb-ehci1 device is supported. Otherwise
+ * don't add anything.
  */
-if (virQEMUCapsGet(qemuCaps, QEMU_CAPS_ICH9_USB_EHCI1))
+if (virQEMUCapsGet(qemuCaps, QEMU_CAPS_NEC_USB_XHCI))
+usbModel = VIR_DOMAIN_CONTROLLER_MODEL_USB_NEC_XHCI;
+else if (virQEMUCapsGet(qemuCaps, QEMU_CAPS_ICH9_USB_EHCI1))
 usbModel = VIR_DOMAIN_CONTROLLER_MODEL_USB_ICH9_EHCI1;
 else
 addDefaultUSB = false;
diff --git a/tests/qemuxml2argvdata/qemuxml2argv-q35-default-devices-only.args 
b/tests/qemuxml2argvdata/qemuxml2argv-q35-default-devices-only.args
new file mode 100644
index 000..9ac30dd
--- /dev/null
+++ b/tests/qemuxml2argvdata/qemuxml2argv-q35-default-devices-only.args
@@ -0,0 +1,22 @@
+LC_ALL=C \
+PATH=/bin \
+HOME=/home/test \
+USER=test \
+LOGNAME=test \
+QEMU_AUDIO_DRV=none \
+/usr/libexec/qemu-kvm \
+-name q35-test \
+-S \
+-M q35 \
+-m 2048 \
+-smp 2,sockets=2,cores=1,threads=1 \
+-uuid 11dbdcdd-4c3b-482b-8903-9bdb8c0a2774 \
+-nographic \
+-nodefaults \
+-monitor unix:/tmp/lib/domain--1-q35-test/monitor.sock,server,nowait \
+-no-acpi \
+-boot c \
+-device ioh3420,port=0x8,chassis=1,id=pci.1,bus=pcie.0,addr=0x1 \
+-device ioh3420,port=0x10,chassis=2,id=pci.2,bus=pcie.0,addr=0x2 \
+-device nec-usb-xhci,id=usb,bus=pci.1,addr=0x0 \
+-device virtio-balloon-pci,id=balloon0,bus=pci.2,addr=0x0
diff --git a/tests/qemuxml2argvdata/qemuxml2argv-q35-default-devices-only.xml 
b/tests/qemuxml2argvdata/qemuxml2argv-q35-default-devices-only.xml
new file mode 100644
index 000..7436583
--- /dev/null
+++ b/tests/qemuxml2argvdata/qemuxml2argv-q35-default-devices-only.xml
@@ -0,0 +1,18 @@
+
+  q35-test
+  11dbdcdd-4c3b-482b-8903-9bdb8c0a2774
+  2097152
+  2097152
+  2
+  
+hvm
+
+  
+  
+  destroy
+  restart
+  destroy
+  
+/usr/libexec/qemu-kvm
+  
+
diff --git a/tests/qemuxml2argvtest.c b/tests/qemuxml2argvtest.c
index 6f2ba6b..b78bce0 100644
--- a/tests/qemuxml2argvtest.c
+++ b/tests/qemuxml2argvtest.c
@@ -1814,6 +1814,29 @@ mymain(void)
 QEMU_CAPS_ICH9_USB_EHCI1,
 QEMU_CAPS_NEC_USB_XHCI,
 QEMU_CAPS_DEVICE_VIDEO_PRIMARY);
+DO_TEST("q35-default-devices-only",
+QEMU_CAPS_VIRTIO_PCI_DISABLE_LEGACY,
+QEMU_CAPS_DEVICE_VIRTIO_RNG,
+QEMU_CAPS_OBJECT_RNG_RANDOM,
+QEMU_CAPS_NETDEV,
+QEMU_CAPS_DEVICE_VIRTIO_NET,
+QEMU_CAPS_DEVICE_VIRTIO_GPU,
+QEMU_CAPS_VIRTIO_GPU_VIRGL,
+QEMU_CAPS_VIRTIO_KEYBOARD,
+QEMU_CAPS_VIRTIO_MOUSE,
+QEMU_CAPS_VIRTIO_TABLET,
+QEMU_CAPS_VIRTIO_INPUT_HOST,
+QEMU_CAPS_VIRTIO_SCSI,
+QEMU_CAPS_FSDEV,
+QEMU_CAPS_FSDEV_WRITEOUT,
+QEMU_CAPS_DEVICE_PCI_BRIDGE,
+QEMU_CAPS_DEVICE_DMI_TO_PCI_BRIDGE,
+QEMU_CAPS_DEVICE_IOH3420,
+QEMU_CAPS_ICH9_AHCI,
+QEMU_CAPS_PCI_MULTIFUNCTION,
+QEMU_CAPS_ICH9_USB_EHCI1,
+QEMU_CAPS_NEC_USB_XHCI,
+   

[libvirt] [PATCH v4 17/25] qemu: assign e1000e network devices to PCIe slots when appropriate

2016-10-14 Thread Laine Stump
The e1000e is an emulated network device based on the Intel 82574,
present in qemu 2.7.0 and later. Among other differences from the
e1000, it presents itself as a PCIe device rather than legacy PCI. In
order to get it assigned to a PCIe controller, this patch updates the
flags setting for network devices when the model name is "e1000e".

(Note that for some reason libvirt has never validated the network
device model names other than to check that there are no dangerous
characters in them. That should probably change, but is the subject of
another patch.)

Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1343094
---

Change: removed ATTRIBUTE_UNUSED, changed to fit reimplemented
qemuDomainDeviceCalculatePCIConnectFlags()

 src/qemu/qemu_domain_address.c |  6 --
 tests/qemuxml2argvdata/qemuxml2argv-q35-pcie.args  | 23 --
 tests/qemuxml2argvdata/qemuxml2argv-q35-pcie.xml   |  4 
 .../qemuxml2argv-q35-virtio-pci.args   |  3 +++
 .../qemuxml2xmloutdata/qemuxml2xmlout-q35-pcie.xml | 23 +-
 .../qemuxml2xmlout-q35-virtio-pci.xml  |  5 +
 6 files changed, 43 insertions(+), 21 deletions(-)

diff --git a/src/qemu/qemu_domain_address.c b/src/qemu/qemu_domain_address.c
index e4cea91..69e530e 100644
--- a/src/qemu/qemu_domain_address.c
+++ b/src/qemu/qemu_domain_address.c
@@ -426,8 +426,7 @@ qemuDomainAssignARMVirtioMMIOAddresses(virDomainDefPtr def,
  */
 static virDomainPCIConnectFlags
 qemuDomainDeviceCalculatePCIConnectFlags(virDomainDeviceDefPtr dev,
- virDomainPCIConnectFlags pcieFlags
- ATTRIBUTE_UNUSED,
+ virDomainPCIConnectFlags pcieFlags,
  virDomainPCIConnectFlags virtioFlags)
 {
 virDomainPCIConnectFlags pciFlags =  (VIR_PCI_CONNECT_TYPE_PCI_DEVICE |
@@ -518,6 +517,9 @@ 
qemuDomainDeviceCalculatePCIConnectFlags(virDomainDeviceDefPtr dev,
 if (STREQ(net->model, "virtio"))
 return  virtioFlags;
 
+if (STREQ(net->model, "e1000e"))
+return pcieFlags;
+
 return pciFlags;
 }
 
diff --git a/tests/qemuxml2argvdata/qemuxml2argv-q35-pcie.args 
b/tests/qemuxml2argvdata/qemuxml2argv-q35-pcie.args
index f07c085..d92e0b8 100644
--- a/tests/qemuxml2argvdata/qemuxml2argv-q35-pcie.args
+++ b/tests/qemuxml2argvdata/qemuxml2argv-q35-pcie.args
@@ -35,10 +35,10 @@ QEMU_AUDIO_DRV=none \
 addr=0x1d \
 -device ich9-usb-uhci2,masterbus=usb.0,firstport=2,bus=pcie.0,addr=0x1d.0x1 \
 -device ich9-usb-uhci3,masterbus=usb.0,firstport=4,bus=pcie.0,addr=0x1d.0x2 \
--device virtio-scsi-pci,id=scsi0,bus=pci.6,addr=0x0 \
--device virtio-serial-pci,id=virtio-serial0,bus=pci.5,addr=0x0 \
+-device virtio-scsi-pci,id=scsi0,bus=pci.7,addr=0x0 \
+-device virtio-serial-pci,id=virtio-serial0,bus=pci.6,addr=0x0 \
 -drive file=/dev/HostVG/QEMUGuest1,format=raw,if=none,id=drive-virtio-disk1 \
--device virtio-blk-pci,bus=pci.7,addr=0x0,drive=drive-virtio-disk1,\
+-device virtio-blk-pci,bus=pci.8,addr=0x0,drive=drive-virtio-disk1,\
 id=virtio-disk1 \
 -fsdev local,security_model=passthrough,id=fsdev-fs0,path=/export/to/guest \
 -device virtio-9p-pci,id=fs0,fsdev=fsdev-fs0,mount_tag=/import/from/host,\
@@ -46,13 +46,16 @@ bus=pci.3,addr=0x0 \
 -netdev user,id=hostnet0 \
 -device 
virtio-net-pci,netdev=hostnet0,id=net0,mac=00:11:22:33:44:55,bus=pci.4,\
 addr=0x0 \
--device virtio-input-host-pci,id=input0,evdev=/dev/input/event1234,bus=pci.10,\
+-netdev user,id=hostnet1 \
+-device e1000e,netdev=hostnet1,id=net1,mac=00:11:22:33:44:66,bus=pci.5,\
 addr=0x0 \
--device virtio-mouse-pci,id=input1,bus=pci.11,addr=0x0 \
--device virtio-keyboard-pci,id=input2,bus=pci.12,addr=0x0 \
--device virtio-tablet-pci,id=input3,bus=pci.13,addr=0x0 \
+-device virtio-input-host-pci,id=input0,evdev=/dev/input/event1234,bus=pci.11,\
+addr=0x0 \
+-device virtio-mouse-pci,id=input1,bus=pci.12,addr=0x0 \
+-device virtio-keyboard-pci,id=input2,bus=pci.13,addr=0x0 \
+-device virtio-tablet-pci,id=input3,bus=pci.14,addr=0x0 \
 -device virtio-gpu-pci,id=video0,bus=pcie.0,addr=0x1 \
--device virtio-balloon-pci,id=balloon0,bus=pci.8,addr=0x0 \
+-device virtio-balloon-pci,id=balloon0,bus=pci.9,addr=0x0 \
 -object rng-random,id=objrng0,filename=/dev/urandom \
--device 
virtio-rng-pci,rng=objrng0,id=rng0,max-bytes=123,period=1234,bus=pci.9,\
-addr=0x0
+-device virtio-rng-pci,rng=objrng0,id=rng0,max-bytes=123,period=1234,\
+bus=pci.10,addr=0x0
diff --git a/tests/qemuxml2argvdata/qemuxml2argv-q35-pcie.xml 
b/tests/qemuxml2argvdata/qemuxml2argv-q35-pcie.xml
index be2439e..39db5f0 100644
--- a/tests/qemuxml2argvdata/qemuxml2argv-q35-pcie.xml
+++ b/tests/qemuxml2argvdata/qemuxml2argv-q35-pcie.xml
@@ -46,6 +46,10 @@
   
   
 
+
+  
+  
+
 
 
   
diff --git a/tests/qemuxml2argvdata/qemuxml2argv-q35-virtio-pci.args 

[libvirt] [PATCH v4 14/25] qemu: set/use proper pciConnectFlags during hotplug

2016-10-14 Thread Laine Stump
Before now, all the qemu hotplug functions assumed that all devices to
be hotplugged were legacy PCI endpoint devices
(VIR_PCI_CONNECT_TYPE_PCI_DEVICE). This worked out "okay", because all
devices *are* legacy PCI endpoint devices on x86/440fx machinetypes,
and hotplug didn't work properly on machinetypes using PCIe anyway
(hotplugging onto a legacy PCI slot doesn't work, and until commit
b87703cf any attempt to manually specify a PCIe address for a
hotplugged device would be erroneously rejected).

This patch makes all qemu hotplug operations honor the pciConnectFlags
set by the single all-knowing function
qemuDomainDeviceCalculatePCIConnectFlags(). This is done in 3 steps,
but in a single commit since we would have to touch the other points
at each step anyway:

1) add a flags argument to the hypervisor-agnostic
virDomainPCIAddressEnsureAddr() (previously it hardcoded
..._PCI_DEVICE)

2) add a new qemu-specific function qemuDomainEnsurePCIAddress() which
gets the correct pciConnectFlags for the device from
qemuDomainDeviceConnectFlags(), then calls
virDomainPCIAddressEnsureAddr().

3) in qemu_hotplug.c replace all calls to
virDomainPCIAddressEnsureAddr() with calls to
qemuDomainEnsurePCIAddress()

So in effect, we're putting a "shim" on top of all calls to
virDomainPCIAddressEnsureAddr() that sets the right pciConnectFlags.
---

Change: modified comments as suggested.

 src/conf/domain_addr.c | 10 ++
 src/conf/domain_addr.h |  3 ++-
 src/qemu/qemu_domain_address.c | 27 +++
 src/qemu/qemu_domain_address.h |  4 
 src/qemu/qemu_hotplug.c| 20 ++--
 5 files changed, 49 insertions(+), 15 deletions(-)

diff --git a/src/conf/domain_addr.c b/src/conf/domain_addr.c
index 3a9e474..fcd5fc1 100644
--- a/src/conf/domain_addr.c
+++ b/src/conf/domain_addr.c
@@ -485,17 +485,11 @@ virDomainPCIAddressReserveSlot(virDomainPCIAddressSetPtr 
addrs,
 
 int
 virDomainPCIAddressEnsureAddr(virDomainPCIAddressSetPtr addrs,
-  virDomainDeviceInfoPtr dev)
+  virDomainDeviceInfoPtr dev,
+  virDomainPCIConnectFlags flags)
 {
 int ret = -1;
 char *addrStr = NULL;
-/* Flags should be set according to the particular device,
- * but only the caller knows the type of device. Currently this
- * function is only used for hot-plug, though, and hot-plug is
- * only supported for standard PCI devices, so we can safely use
- * the setting below */
-virDomainPCIConnectFlags flags = (VIR_PCI_CONNECT_HOTPLUGGABLE |
-  VIR_PCI_CONNECT_TYPE_PCI_DEVICE);
 
 if (!(addrStr = virDomainPCIAddressAsString(>addr.pci)))
 goto cleanup;
diff --git a/src/conf/domain_addr.h b/src/conf/domain_addr.h
index 4d6d12a..92ee04c 100644
--- a/src/conf/domain_addr.h
+++ b/src/conf/domain_addr.h
@@ -144,7 +144,8 @@ int 
virDomainPCIAddressReserveSlot(virDomainPCIAddressSetPtr addrs,
 ATTRIBUTE_NONNULL(1) ATTRIBUTE_NONNULL(2);
 
 int virDomainPCIAddressEnsureAddr(virDomainPCIAddressSetPtr addrs,
-  virDomainDeviceInfoPtr dev)
+  virDomainDeviceInfoPtr dev,
+  virDomainPCIConnectFlags flags)
 ATTRIBUTE_NONNULL(1) ATTRIBUTE_NONNULL(2);
 
 int virDomainPCIAddressReleaseAddr(virDomainPCIAddressSetPtr addrs,
diff --git a/src/qemu/qemu_domain_address.c b/src/qemu/qemu_domain_address.c
index 3a685e7..991cfa7 100644
--- a/src/qemu/qemu_domain_address.c
+++ b/src/qemu/qemu_domain_address.c
@@ -2136,6 +2136,33 @@ qemuDomainAssignAddresses(virDomainDefPtr def,
 return 0;
 }
 
+/**
+ * qemuDomainEnsurePCIAddress:
+ *
+ * if @dev should have a PCI address but doesn't, assign an address on
+ * a compatible PCI bus, and set it in @dev->...info. If there is an
+ * address already, validate that it is on a compatible bus, based on
+ * @dev->...info.pciConnectFlags.
+ *
+ * @obj: the virDomainObjPtr for the domain. This will include
+ *   qemuCaps and address cache (if there is one)
+ *
+ * @dev: the device that we need to ensure has a PCI address
+ *
+ * returns 0 on success -1 on failure.
+ */
+int
+qemuDomainEnsurePCIAddress(virDomainObjPtr obj,
+   virDomainDeviceDefPtr dev)
+{
+qemuDomainObjPrivatePtr priv = obj->privateData;
+virDomainDeviceInfoPtr info = virDomainDeviceGetInfo(dev);
+
+qemuDomainFillDevicePCIConnectFlags(obj->def, dev, priv->qemuCaps);
+
+return virDomainPCIAddressEnsureAddr(priv->pciaddrs, info,
+ info->pciConnectFlags);
+}
 
 void
 qemuDomainReleaseDeviceAddress(virDomainObjPtr vm,
diff --git a/src/qemu/qemu_domain_address.h b/src/qemu/qemu_domain_address.h
index 11d6e92..800859c 100644
--- a/src/qemu/qemu_domain_address.h
+++ b/src/qemu/qemu_domain_address.h
@@ -37,6 +37,10 @@ int qemuDomainAssignAddresses(virDomainDefPtr def,
  

[libvirt] [PATCH v4 07/25] [NEW] qemu: change first arg of qemuDomainAttachChrDeviceAssignAddr()

2016-10-14 Thread Laine Stump
from virDomainDefPtr to virDomainObjPtr so that the function has
access to the other parts of the virDomainObjPtr. Take advantage of
this by removing the "priv" arg and retrieving it from the
virDomainObjPtr instead.

No functional change.
---
 src/qemu/qemu_hotplug.c | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/src/qemu/qemu_hotplug.c b/src/qemu/qemu_hotplug.c
index 14af4e1..dc0faa6 100644
--- a/src/qemu/qemu_hotplug.c
+++ b/src/qemu/qemu_hotplug.c
@@ -1636,10 +1636,11 @@ qemuDomainChrRemove(virDomainDefPtr vmdef,
 }
 
 static int
-qemuDomainAttachChrDeviceAssignAddr(virDomainDefPtr def,
-qemuDomainObjPrivatePtr priv,
+qemuDomainAttachChrDeviceAssignAddr(virDomainObjPtr vm,
 virDomainChrDefPtr chr)
 {
+virDomainDefPtr def = vm->def;
+qemuDomainObjPrivatePtr priv = vm->privateData;
 int ret = -1;
 virDomainVirtioSerialAddrSetPtr vioaddrs = NULL;
 
@@ -1715,7 +1716,7 @@ int qemuDomainAttachChrDevice(virQEMUDriverPtr driver,
 if (qemuAssignDeviceChrAlias(vmdef, chr, -1) < 0)
 goto cleanup;
 
-if ((rc = qemuDomainAttachChrDeviceAssignAddr(vm->def, priv, chr)) < 0)
+if ((rc = qemuDomainAttachChrDeviceAssignAddr(vm, chr)) < 0)
 goto cleanup;
 if (rc == 1)
 need_release = true;
-- 
2.7.4

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list


[libvirt] [PATCH v4 16/25] qemu: assign virtio devices to PCIe slot when appropriate

2016-10-14 Thread Laine Stump
libvirt previously assigned nearly all devices to a "hotpluggable"
legacy PCI slot even on machines with a PCIe root bus (and even though
most such machines don't even support hotplug on legacy PCI slots!)
Forcing all devices onto legacy PCI slots means that the domain will
need a dmi-to-pci-bridge (to convert from PCIe to legacy PCI) and a
pci-bridge (to provide hotpluggable legacy PCI slots which, again,
usually aren't hotpluggable anyway).

To help reduce the need for these legacy controllers, this patch tries
to assign virtio-1.0-capable devices to PCIe slots whenever possible,
by setting appropriate connectFlags in
virDomainCalculateDevicePCIConnectFlags(). Happily, when that function
was written (just a few commits ago) it was created with a
"virtioFlags" argument, set by both of its callers, which is the
proper connectFlags to set for any virtio-*-pci device - depending on
the arch/machinetype of the domain, and whether or not the qemu binary
supports virtio-1.0, that flag will have either been set to PCI or
PCIE. This patch merely enables the functionality by setting the flags
for the device to whatever is in virtioFlags if the device is a
virtio-*-pci device.

NB: the first virtio video device will be placed directly on bus 0
slot 1 rather than on a pcie-root-port due to the override for primary
video devices in qemuDomainValidateDevicePCISlotsQ35(). Whether or not
to change that is a topic of discussion, but this patch doesn't change
that particular behavior.

NB2: since the slot must be hotpluggable, and pcie-root (the PCIe root
complex) does *not* support hotplug, this means that suitable
controllers must also be in the config (i.e. either pcie-root-port, or
pcie-downstream-port). For now, libvirt doesn't add those
automatically, so if you put virtio devices in a config for a qemu
that has PCIe-capable virtio devices, you'll need to add extra
pcie-root-ports yourself. That requirement will be eliminated in a
future patch, but for now, it's simple to do this:

   
   
   
   ...

Partially Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1330024
---

Change: modified due to changes in patch 12.

 src/qemu/qemu_domain_address.c |  41 --
 tests/qemuxml2argvdata/qemuxml2argv-q35-pcie.args  |  58 
 tests/qemuxml2argvdata/qemuxml2argv-q35-pcie.xml   |  61 
 .../qemuxml2argv-q35-virtio-pci.args   |  58 
 .../qemuxml2argv-q35-virtio-pci.xml|   1 +
 tests/qemuxml2argvtest.c   |  48 +++
 .../qemuxml2xmloutdata/qemuxml2xmlout-q35-pcie.xml | 154 +
 .../qemuxml2xmlout-q35-virtio-pci.xml  | 154 +
 tests/qemuxml2xmltest.c|  43 ++
 9 files changed, 609 insertions(+), 9 deletions(-)
 create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-q35-pcie.args
 create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-q35-pcie.xml
 create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-q35-virtio-pci.args
 create mode 12 tests/qemuxml2argvdata/qemuxml2argv-q35-virtio-pci.xml
 create mode 100644 tests/qemuxml2xmloutdata/qemuxml2xmlout-q35-pcie.xml
 create mode 100644 tests/qemuxml2xmloutdata/qemuxml2xmlout-q35-virtio-pci.xml

diff --git a/src/qemu/qemu_domain_address.c b/src/qemu/qemu_domain_address.c
index 22d859e..e4cea91 100644
--- a/src/qemu/qemu_domain_address.c
+++ b/src/qemu/qemu_domain_address.c
@@ -428,8 +428,7 @@ static virDomainPCIConnectFlags
 qemuDomainDeviceCalculatePCIConnectFlags(virDomainDeviceDefPtr dev,
  virDomainPCIConnectFlags pcieFlags
  ATTRIBUTE_UNUSED,
- virDomainPCIConnectFlags virtioFlags
- ATTRIBUTE_UNUSED)
+ virDomainPCIConnectFlags virtioFlags)
 {
 virDomainPCIConnectFlags pciFlags =  (VIR_PCI_CONNECT_TYPE_PCI_DEVICE |
   VIR_PCI_CONNECT_HOTPLUGGABLE);
@@ -469,9 +468,28 @@ 
qemuDomainDeviceCalculatePCIConnectFlags(virDomainDeviceDefPtr dev,
 }
 
 case VIR_DOMAIN_CONTROLLER_TYPE_IDE:
+return pciFlags;
+
 case VIR_DOMAIN_CONTROLLER_TYPE_SCSI:
+switch ((virDomainControllerModelSCSI)cont->model) {
+case VIR_DOMAIN_CONTROLLER_MODEL_SCSI_VIRTIO_SCSI:
+return virtioFlags;
+
+case VIR_DOMAIN_CONTROLLER_MODEL_SCSI_AUTO:
+case VIR_DOMAIN_CONTROLLER_MODEL_SCSI_BUSLOGIC:
+case VIR_DOMAIN_CONTROLLER_MODEL_SCSI_LSILOGIC:
+case VIR_DOMAIN_CONTROLLER_MODEL_SCSI_LSISAS1068:
+case VIR_DOMAIN_CONTROLLER_MODEL_SCSI_VMPVSCSI:
+case VIR_DOMAIN_CONTROLLER_MODEL_SCSI_IBMVSCSI:
+case VIR_DOMAIN_CONTROLLER_MODEL_SCSI_LSISAS1078:
+return pciFlags;
+
+case VIR_DOMAIN_CONTROLLER_MODEL_SCSI_LAST:
+

[libvirt] [PATCH v4 21/25] [NEW RFC] qemu: if pci-bridge is in PCIe config w/o dmi-to-pci-bridge, add it

2016-10-14 Thread Laine Stump
I'm undecided if it is worthwhile to add this...

Up until now it has been legal to have something like this in the xml:

  
  

(for example, see the existing test case
"usb-controller-default-q35").  This is handled in
qemuDomainPCIAddressSetCreate() when it's adding in controllers to
fill holes in the indexes.)

Since we have always added the following to every config:

  

there has always been a proper place for the unaddressed pci-bridge to
plug in.

A upcoming commit will eliminate the forced adding of a
dmi-to-pci-bridge to *every* Q35 domain config, though. This would
mean the above-mentioned test case (and one other) would begin to
fail. There are two possible solutions to this problem:

1) change the test cases, and made the above construct an error (note
that in the future it will work just fine to not list *any* pci
controller, and they will all be auto-added as needed).

or

2) This patch, which specifically looks for the case where we have a
pci-bridge (but no dmi-to-pci-bridge) in a PCIe domain config and
auto-adds the necessary dmi-to-pci-bridge. This can only work in the
case that the pci-bridge has been given an index such that there is an
unused index with a lower value for the dmi-to-pci-bridge to occupy.

This seems like a kind of odd corner case that nobody should need to
do in the future anyway. On the other hand, I already wrote the code
and it works, so I might as well send it and see what opinions (if
any) it generates.
---
 src/qemu/qemu_domain_address.c | 42 +-
 1 file changed, 37 insertions(+), 5 deletions(-)

diff --git a/src/qemu/qemu_domain_address.c b/src/qemu/qemu_domain_address.c
index 38b7775..e81d212 100644
--- a/src/qemu/qemu_domain_address.c
+++ b/src/qemu/qemu_domain_address.c
@@ -919,6 +919,9 @@ qemuDomainPCIAddressSetCreate(virDomainDefPtr def,
 virDomainPCIAddressSetPtr addrs;
 size_t i;
 bool hasPCIeRoot = false;
+unsigned int lowestDMIToPCIBridge = nbuses;
+unsigned int lowestUnaddressedPCIBridge = nbuses;
+unsigned int lowestAddressedPCIBridge = nbuses;
 virDomainControllerModelPCI defaultModel;
 
 if ((addrs = virDomainPCIAddressSetAlloc(nbuses)) == NULL)
@@ -943,8 +946,24 @@ qemuDomainPCIAddressSetCreate(virDomainDefPtr def,
 if (virDomainPCIAddressBusSetModel(>buses[idx], cont->model) < 
0)
 goto error;
 
-if (cont->model == VIR_DOMAIN_CONTROLLER_MODEL_PCIE_ROOT)
+/* we'll use all this info later to determine if we need
+ * to add a dmi-to-pci-bridge due to unaddressed pci-bridge controllers
+ */
+if (cont->model == VIR_DOMAIN_CONTROLLER_MODEL_PCIE_ROOT) {
 hasPCIeRoot = true;
+} else if (cont->model ==
+   VIR_DOMAIN_CONTROLLER_MODEL_DMI_TO_PCI_BRIDGE) {
+if (lowestDMIToPCIBridge > idx)
+lowestDMIToPCIBridge = idx;
+} else if (cont->model == VIR_DOMAIN_CONTROLLER_MODEL_PCI_BRIDGE) {
+if (virDeviceInfoPCIAddressWanted(>info)) {
+if (lowestUnaddressedPCIBridge > idx)
+lowestUnaddressedPCIBridge = idx;
+} else {
+if (lowestAddressedPCIBridge > idx)
+lowestAddressedPCIBridge = idx;
+}
+}
 }
 
 if (nbuses > 0 && !addrs->buses[0].model) {
@@ -960,13 +979,21 @@ qemuDomainPCIAddressSetCreate(virDomainDefPtr def,
 
 /* Now fill in a reasonable model for all the buses in the set
  * that don't yet have a corresponding controller in the domain
- * config.
+ * config.  In the rare (and ... strange, but still allowed) case
+ * that a domain has 1) a pcie-root at index 0, 2) *no*
+ * dmi-to-pci-bridge (or pci-bridge that was manually addressed to
+ * sit directly on pcie-root), and 3) does have an unaddressed
+ * pci-bridge at an index > 1, then we need to add a
+ * dmi-to-pci-bridge.
  */
 
-if (hasPCIeRoot)
-defaultModel = VIR_DOMAIN_CONTROLLER_MODEL_PCIE_ROOT_PORT;
-else
+if (!hasPCIeRoot)
 defaultModel = VIR_DOMAIN_CONTROLLER_MODEL_PCI_BRIDGE;
+else if (lowestUnaddressedPCIBridge < MIN(lowestAddressedPCIBridge,
+  lowestDMIToPCIBridge))
+defaultModel = VIR_DOMAIN_CONTROLLER_MODEL_DMI_TO_PCI_BRIDGE;
+else
+defaultModel = VIR_DOMAIN_CONTROLLER_MODEL_PCIE_ROOT_PORT;
 
 for (i = 1; i < addrs->nbuses; i++) {
 
@@ -978,6 +1005,11 @@ qemuDomainPCIAddressSetCreate(virDomainDefPtr def,
 
 VIR_DEBUG("Auto-adding ",
   virDomainControllerModelPCITypeToString(defaultModel), i);
+/* only add a single dmi-to-pci-bridge, then add pcie-root-port
+ * for any other unspecified controller indexes.
+ */
+if (hasPCIeRoot)
+defaultModel = VIR_DOMAIN_CONTROLLER_MODEL_PCIE_ROOT_PORT;
 }
 
 if (virDomainDeviceInfoIterate(def, qemuDomainCollectPCIAddress, 

[libvirt] [PATCH v4 19/25] [ACKED] qemu: only force an available legacy-PCI slot on domains with pci-root

2016-10-14 Thread Laine Stump
Andrea had the right idea when he disabled the "reserve an extra
unused slot" bit for aarch64/virt. For *any* PCI Express-based
machine, it is pointless since 1) an extra legacy-PCI slot can't be
used for hotplug, since hotplug into legacy PCI slots doesn't work on
PCI Express machinetypes, and 2) even for "coldplug" expansion,
everybody will want to expand using Express controllers, not legacy
PCI.

This patch eliminates the extra slot reserve unless the system has a
pci-root (i.e. legacy PCI)
---
 src/qemu/qemu_domain_address.c | 44 ++
 1 file changed, 27 insertions(+), 17 deletions(-)

diff --git a/src/qemu/qemu_domain_address.c b/src/qemu/qemu_domain_address.c
index 5262ad3..4e4e0d6 100644
--- a/src/qemu/qemu_domain_address.c
+++ b/src/qemu/qemu_domain_address.c
@@ -1815,8 +1815,6 @@ qemuDomainAssignPCIAddresses(virDomainDefPtr def,
  */
 virDomainDeviceInfo info;
 
-info.pciConnectFlags = VIR_PCI_CONNECT_TYPE_PCI_DEVICE;
-
 /* 1st pass to figure out how many PCI bridges we need */
 if (!(addrs = qemuDomainPCIAddressSetCreate(def, nbuses, true)))
 goto cleanup;
@@ -1825,23 +1823,35 @@ qemuDomainAssignPCIAddresses(virDomainDefPtr def,
  addrs) < 0)
 goto cleanup;
 
-for (i = 0; i < addrs->nbuses; i++) {
-if (!qemuDomainPCIBusFullyReserved(>buses[i]))
-buses_reserved = false;
-}
-
-/* Reserve 1 extra slot for a (potential) bridge only if buses
- * are not fully reserved yet.
+/* For domains that have pci-root, reserve 1 extra slot for a
+ * (potential) bridge (for future expansion) only if buses are
+ * not fully reserved yet (if all buses are fully reserved
+ * with manually/previously assigned addresses, any attempt to
+ * reserve an extra slot would fail anyway. But if all buses
+ * are *not* fully reserved, this extra reservation might push
+ * the config to add a new pci-bridge to plug into the final
+ * available slot, thus preserving the ability to expand)
  *
- * 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
+ * We only do this for those domains that have pci-root, since
+ * those with pcie-root will usually want to expand using PCIe
+ * controllers, which we will do after assigning addresses for
+ * all *actual* devices.
  */
-if (!buses_reserved &&
-!qemuDomainMachineIsVirt(def) &&
-qemuDomainPCIAddressReserveNextSlot(addrs, ) < 0)
-goto cleanup;
+
+if (qemuDomainMachineHasPCIRoot(def)) {
+info.pciConnectFlags = (VIR_PCI_CONNECT_HOTPLUGGABLE |
+VIR_PCI_CONNECT_TYPE_PCI_DEVICE);
+
+for (i = 0; i < addrs->nbuses; i++) {
+if (!qemuDomainPCIBusFullyReserved(>buses[i])) {
+buses_reserved = false;
+break;
+}
+}
+if (!buses_reserved &&
+qemuDomainPCIAddressReserveNextSlot(addrs, ) < 0)
+goto cleanup;
+}
 
 if (qemuDomainAssignDevicePCISlots(def, qemuCaps, addrs) < 0)
 goto cleanup;
-- 
2.7.4

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list


[libvirt] [PATCH v4 12/25] qemu: new functions to calculate/set device pciConnectFlags

2016-10-14 Thread Laine Stump
The lowest level function of this trio
(qemuDomainDeviceCalculatePCIConnectFlags()) aims to be the single
authority for the virDomainPCIConnectFlags to use for any given device
using a particular arch/machinetype/qemu-binary.

qemuDomainFillDevicePCIConnectFlags() sets info->pciConnectFlags in a
single device (unless it has no virDomainDeviceInfo, in which case
it's a NOP).

qemuDomainFillAllPCIConnectFlags() sets info->pciConnectFlags in all
devices that have a virDomainDeviceInfo

The latter two functions aren't called anywhere yet. This commit is
just making them available. Later patches will replace all the current
hodge-podge of flag settings with calls to this single authority.
---

Change: re-implemented as a giant two-level compound switch statement
with no default cases, as suggested by Andrea. Also start off
with the function setting the flags for *all* devices to
PCI_DEVICE|HOTPLUGGABLE, which is what's currently used when
assigning addresses (as opposed to merely validating addresses,
which is much less strict).

 src/conf/device_conf.h |   5 +
 src/qemu/qemu_domain_address.c | 379 +
 2 files changed, 384 insertions(+)

diff --git a/src/conf/device_conf.h b/src/conf/device_conf.h
index 8443de6..f435fb5 100644
--- a/src/conf/device_conf.h
+++ b/src/conf/device_conf.h
@@ -142,6 +142,11 @@ typedef struct _virDomainDeviceInfo {
 /* bootIndex is only used for disk, network interface, hostdev
  * and redirdev devices */
 unsigned int bootIndex;
+
+/* pciConnectFlags is only used internally during address
+ * assignment, never saved and never reported.
+ */
+int pciConnectFlags; /* enum virDomainPCIConnectFlags */
 } virDomainDeviceInfo, *virDomainDeviceInfoPtr;
 
 
diff --git a/src/qemu/qemu_domain_address.c b/src/qemu/qemu_domain_address.c
index b4ea906..457eae6 100644
--- a/src/qemu/qemu_domain_address.c
+++ b/src/qemu/qemu_domain_address.c
@@ -405,6 +405,385 @@ qemuDomainAssignARMVirtioMMIOAddresses(virDomainDefPtr 
def,
 }
 
 
+/**
+ * qemuDomainDeviceCalculatePCIConnectFlags:
+ *
+ * Lowest level function to determine PCI connectFlags for a
+ * device. This function relies on the next higher-level function
+ * determining the value for pcieFlags and virtioFlags in advance -
+ * this is to make it more efficient to call multiple times.
+ *
+ * @dev: The device to be checked
+ *
+ * @pcieFlags: flags to use for a known PCI Express device
+ *
+ * @virtioFlags: flags to use for a virtio device (properly vetted
+ *   for the current qemu binary and arch/machinetype)
+ *
+ * returns appropriate virDomainPCIConnectFlags for this device in
+ * this domain, or 0 if the device doesn't connect using PCI. There
+ * is no failure.
+ */
+static virDomainPCIConnectFlags
+qemuDomainDeviceCalculatePCIConnectFlags(virDomainDeviceDefPtr dev,
+ virDomainPCIConnectFlags pcieFlags
+ ATTRIBUTE_UNUSED,
+ virDomainPCIConnectFlags virtioFlags
+ ATTRIBUTE_UNUSED)
+{
+virDomainPCIConnectFlags pciFlags =  (VIR_PCI_CONNECT_TYPE_PCI_DEVICE |
+  VIR_PCI_CONNECT_HOTPLUGGABLE);
+
+switch ((virDomainDeviceType)dev->type) {
+case VIR_DOMAIN_DEVICE_CONTROLLER: {
+virDomainControllerDefPtr cont = dev->data.controller;
+
+switch ((virDomainControllerType)cont->type) {
+case VIR_DOMAIN_CONTROLLER_TYPE_PCI:
+return virDomainPCIControllerModelToConnectType(cont->model);
+
+case VIR_DOMAIN_CONTROLLER_TYPE_SATA:
+return pciFlags;
+
+case VIR_DOMAIN_CONTROLLER_TYPE_USB:
+switch ((virDomainControllerModelUSB)cont->model) {
+case VIR_DOMAIN_CONTROLLER_MODEL_USB_NEC_XHCI:
+return pciFlags;
+
+case VIR_DOMAIN_CONTROLLER_MODEL_USB_EHCI:
+case VIR_DOMAIN_CONTROLLER_MODEL_USB_ICH9_EHCI1:
+case VIR_DOMAIN_CONTROLLER_MODEL_USB_ICH9_UHCI1:
+case VIR_DOMAIN_CONTROLLER_MODEL_USB_ICH9_UHCI2:
+case VIR_DOMAIN_CONTROLLER_MODEL_USB_ICH9_UHCI3:
+case VIR_DOMAIN_CONTROLLER_MODEL_USB_VT82C686B_UHCI:
+case VIR_DOMAIN_CONTROLLER_MODEL_USB_PIIX3_UHCI:
+case VIR_DOMAIN_CONTROLLER_MODEL_USB_PIIX4_UHCI:
+case VIR_DOMAIN_CONTROLLER_MODEL_USB_PCI_OHCI:
+return pciFlags;
+
+case VIR_DOMAIN_CONTROLLER_MODEL_USB_QUSB1: /* xen only */
+case VIR_DOMAIN_CONTROLLER_MODEL_USB_QUSB2: /* xen only */
+case VIR_DOMAIN_CONTROLLER_MODEL_USB_NONE:
+case VIR_DOMAIN_CONTROLLER_MODEL_USB_LAST:
+/* should be 0 */
+return pciFlags;
+}
+
+case VIR_DOMAIN_CONTROLLER_TYPE_IDE:
+case VIR_DOMAIN_CONTROLLER_TYPE_SCSI:
+case 

[libvirt] [PATCH v4 08/25] conf: new function virDomainPCIAddressReserveNextAddr()

2016-10-14 Thread Laine Stump
There is an existing virDomainPCIAddressReserveNextSlot() which will
reserve all functions of the next available PCI slot. One place in the
qemu PCI address assignment code requires reserving a *single*
function of the next available PCI slot. This patch modifies and
renames virDomainPCIAddressReserveNextSlot() so that it can fulfill
both the original purpose and the need to reserve a single function.

(This is being done so that the abovementioned code in qemu can have
its "kind of open coded" solution replaced with a call to this new
function).
---

Changes: Fixed indentation and comments, and removed unnecessary
 setting of lastaddr.function and lastaddr.multi.

 src/conf/domain_addr.c   | 49 +++-
 src/conf/domain_addr.h   |  7 +++
 src/libvirt_private.syms |  1 +
 3 files changed, 52 insertions(+), 5 deletions(-)

diff --git a/src/conf/domain_addr.c b/src/conf/domain_addr.c
index 080d882..1710220 100644
--- a/src/conf/domain_addr.c
+++ b/src/conf/domain_addr.c
@@ -691,29 +691,68 @@ virDomainPCIAddressGetNextSlot(virDomainPCIAddressSetPtr 
addrs,
 return 0;
 }
 
+
+/**
+ * virDomainPCIAddressReserveNextAddr:
+ *
+ * find the next *completely unreserved* slot with compatible
+ * connection @flags, mark either one function or the entire
+ * slot as in-use (according to @function and @reserveEntireSlot),
+ * and set @dev->addr.pci with this newly reserved address.
+ *
+ * @addrs: a set of PCI addresses.
+ *
+ * @dev:   virDomainDeviceInfo that should get the new address.
+ *
+ * @flags: CONNECT_TYPE flags for the device that needs an address.
+ *
+ * @function:  which function on the slot to mark as reserved
+ * (if @reserveEntireSlot is false)
+ *
+ * @reserveEntireSlot: true to reserve all functions on the new slot,
+ *  false to reserve just @function
+ *
+ *
+ * returns 0 on success, or -1 on failure.
+ */
 int
-virDomainPCIAddressReserveNextSlot(virDomainPCIAddressSetPtr addrs,
+virDomainPCIAddressReserveNextAddr(virDomainPCIAddressSetPtr addrs,
virDomainDeviceInfoPtr dev,
-   virDomainPCIConnectFlags flags)
+   virDomainPCIConnectFlags flags,
+   unsigned int function,
+   bool reserveEntireSlot)
 {
 virPCIDeviceAddress addr;
+
 if (virDomainPCIAddressGetNextSlot(addrs, , flags) < 0)
 return -1;
 
-if (virDomainPCIAddressReserveSlot(addrs, , flags) < 0)
+addr.function = reserveEntireSlot ? 0 : function;
+
+if (virDomainPCIAddressReserveAddr(addrs, , flags, reserveEntireSlot, 
false) < 0)
 return -1;
 
+addrs->lastaddr = addr;
+addrs->lastFlags = flags;
+
 if (!addrs->dryRun) {
 dev->type = VIR_DOMAIN_DEVICE_ADDRESS_TYPE_PCI;
 dev->addr.pci = addr;
 }
 
-addrs->lastaddr = addr;
-addrs->lastFlags = flags;
 return 0;
 }
 
 
+int
+virDomainPCIAddressReserveNextSlot(virDomainPCIAddressSetPtr addrs,
+   virDomainDeviceInfoPtr dev,
+   virDomainPCIConnectFlags flags)
+{
+return virDomainPCIAddressReserveNextAddr(addrs, dev, flags, 0, true);
+}
+
+
 static char*
 virDomainCCWAddressAsString(virDomainDeviceCCWAddressPtr addr)
 {
diff --git a/src/conf/domain_addr.h b/src/conf/domain_addr.h
index 0072a08..904d060 100644
--- a/src/conf/domain_addr.h
+++ b/src/conf/domain_addr.h
@@ -160,6 +160,13 @@ int 
virDomainPCIAddressGetNextSlot(virDomainPCIAddressSetPtr addrs,
virDomainPCIConnectFlags flags)
 ATTRIBUTE_NONNULL(1) ATTRIBUTE_NONNULL(2);
 
+int virDomainPCIAddressReserveNextAddr(virDomainPCIAddressSetPtr addrs,
+   virDomainDeviceInfoPtr dev,
+   virDomainPCIConnectFlags flags,
+   unsigned int function,
+   bool reserveEntireSlot)
+ATTRIBUTE_NONNULL(1) ATTRIBUTE_NONNULL(2);
+
 int virDomainPCIAddressReserveNextSlot(virDomainPCIAddressSetPtr addrs,
virDomainDeviceInfoPtr dev,
virDomainPCIConnectFlags flags)
diff --git a/src/libvirt_private.syms b/src/libvirt_private.syms
index 55b6a24..9f9512a 100644
--- a/src/libvirt_private.syms
+++ b/src/libvirt_private.syms
@@ -102,6 +102,7 @@ virDomainPCIAddressFlagsCompatible;
 virDomainPCIAddressGetNextSlot;
 virDomainPCIAddressReleaseSlot;
 virDomainPCIAddressReserveAddr;
+virDomainPCIAddressReserveNextAddr;
 virDomainPCIAddressReserveNextSlot;
 virDomainPCIAddressReserveSlot;
 virDomainPCIAddressSetAlloc;
-- 
2.7.4

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list


[libvirt] [PATCH v4 13/25] qemu: set/use info->pciConnectFlags when validating/assigning PCI addresses

2016-10-14 Thread Laine Stump
Set pciConnectFlags in each device's DeviceInfo and then use those
flags later when validating existing addresses in
qemuDomainCollectPCIAddress() and when assigning new addresses with
qemuDomainPCIAddressReserveNextAddr() (rather than scattering the
logic about which devices need which type of slot all over the place).

Note that the exact flags set by
qemuDomainDeviceCalculatePCIConnectFlags() are different from the
flags previously set manually in qemuDomainCollectPCIAddress(), but
this doesn't matter because all validation of addresses in that case
ignores the setting of the HOTPLUGGABLE flag, and treats PCIE_DEVICE
and PCI_DEVICE the same (this lax checking was done on purpose,
because there are some things that we want to allow the user to
specify manually, e.g. assigning a PCIe device to a PCI slot, that we
*don't* ever want libvirt to do automatically. The flag settings that
we *really* want to match are 1) the old flag settings in
qemuDomainAssignDevicePCISlots() (which is HOTPLUGGABLE | PCI_DEVICE
for everything except PCI controllers) and the new flag settings done
by qemuDomainDeviceCalculatePCIConnectFlags() (which are currently
exactly that - HOTPLUGGABLE | PCI_DEVICE for everything except PCI
controllers).
---

Changes: expanded commit log to detail why these flags are different from those
 set in qemuDomainCollectPCIAddress().

 src/qemu/qemu_domain_address.c | 206 +++--
 1 file changed, 75 insertions(+), 131 deletions(-)

diff --git a/src/qemu/qemu_domain_address.c b/src/qemu/qemu_domain_address.c
index 457eae6..3a685e7 100644
--- a/src/qemu/qemu_domain_address.c
+++ b/src/qemu/qemu_domain_address.c
@@ -727,7 +727,7 @@ qemuDomainFillDevicePCIConnectFlagsIter(virDomainDefPtr def 
ATTRIBUTE_UNUSED,
  * 0 on success or -1 on failure (the only possibility of failure would
  * be some internal problem with virDomainDeviceInfoIterate())
  */
-static int ATTRIBUTE_UNUSED
+static int
 qemuDomainFillAllPCIConnectFlags(virDomainDefPtr def,
  virQEMUCapsPtr qemuCaps)
 {
@@ -787,21 +787,20 @@ qemuDomainFillDevicePCIConnectFlags(virDomainDefPtr def,
 static int
 qemuDomainPCIAddressReserveNextAddr(virDomainPCIAddressSetPtr addrs,
 virDomainDeviceInfoPtr dev,
-virDomainPCIConnectFlags flags,
 unsigned int function,
 bool reserveEntireSlot)
 {
-return virDomainPCIAddressReserveNextAddr(addrs, dev, flags,
+return virDomainPCIAddressReserveNextAddr(addrs, dev,
+  dev->pciConnectFlags,
   function, reserveEntireSlot);
 }
 
 
 static int
 qemuDomainPCIAddressReserveNextSlot(virDomainPCIAddressSetPtr addrs,
-virDomainDeviceInfoPtr dev,
-virDomainPCIConnectFlags flags)
+virDomainDeviceInfoPtr dev)
 {
-return qemuDomainPCIAddressReserveNextAddr(addrs, dev, flags, 0, true);
+return qemuDomainPCIAddressReserveNextAddr(addrs, dev, 0, true);
 }
 
 
@@ -815,9 +814,6 @@ qemuDomainCollectPCIAddress(virDomainDefPtr def 
ATTRIBUTE_UNUSED,
 int ret = -1;
 virPCIDeviceAddressPtr addr = >addr.pci;
 bool entireSlot;
-/* flags may be changed from default below */
-virDomainPCIConnectFlags flags = (VIR_PCI_CONNECT_HOTPLUGGABLE |
-  VIR_PCI_CONNECT_TYPE_PCI_DEVICE);
 
 if (!virDeviceInfoPCIAddressPresent(info) ||
 ((device->type == VIR_DOMAIN_DEVICE_HOSTDEV) &&
@@ -829,71 +825,6 @@ qemuDomainCollectPCIAddress(virDomainDefPtr def 
ATTRIBUTE_UNUSED,
 return 0;
 }
 
-/* Change flags according to differing requirements of different
- * devices.
- */
-switch (device->type) {
-case VIR_DOMAIN_DEVICE_CONTROLLER:
-switch (device->data.controller->type) {
-case  VIR_DOMAIN_CONTROLLER_TYPE_PCI:
-   flags = 
virDomainPCIControllerModelToConnectType(device->data.controller->model);
-break;
-
-case VIR_DOMAIN_CONTROLLER_TYPE_SATA:
-/* SATA controllers aren't hot-plugged, and can be put in
- * either a PCI or PCIe slot
- */
-flags = (VIR_PCI_CONNECT_TYPE_PCI_DEVICE
- | VIR_PCI_CONNECT_TYPE_PCIE_DEVICE);
-break;
-
-case VIR_DOMAIN_CONTROLLER_TYPE_USB:
-/* allow UHCI and EHCI controllers to be manually placed on
- * the PCIe bus (but don't put them there automatically)
- */
-switch (device->data.controller->model) {
-case VIR_DOMAIN_CONTROLLER_MODEL_USB_EHCI:
-case VIR_DOMAIN_CONTROLLER_MODEL_USB_ICH9_EHCI1:
-case VIR_DOMAIN_CONTROLLER_MODEL_USB_ICH9_UHCI1:
-case 

[libvirt] [PATCH v4 10/25] [ACKED] conf: make virDomainPCIAddressGetNextSlot() a local static function

2016-10-14 Thread Laine Stump
This function is no longer needed outside of domain_addr.c.
---
 src/conf/domain_addr.c   | 2 +-
 src/conf/domain_addr.h   | 5 -
 src/libvirt_private.syms | 1 -
 3 files changed, 1 insertion(+), 7 deletions(-)

diff --git a/src/conf/domain_addr.c b/src/conf/domain_addr.c
index 1710220..3a9e474 100644
--- a/src/conf/domain_addr.c
+++ b/src/conf/domain_addr.c
@@ -591,7 +591,7 @@ virDomainPCIAddressSetFree(virDomainPCIAddressSetPtr addrs)
 }
 
 
-int
+static int
 virDomainPCIAddressGetNextSlot(virDomainPCIAddressSetPtr addrs,
virPCIDeviceAddressPtr next_addr,
virDomainPCIConnectFlags flags)
diff --git a/src/conf/domain_addr.h b/src/conf/domain_addr.h
index 904d060..4d6d12a 100644
--- a/src/conf/domain_addr.h
+++ b/src/conf/domain_addr.h
@@ -155,11 +155,6 @@ int 
virDomainPCIAddressReleaseSlot(virDomainPCIAddressSetPtr addrs,
virPCIDeviceAddressPtr addr)
 ATTRIBUTE_NONNULL(1) ATTRIBUTE_NONNULL(2);
 
-int virDomainPCIAddressGetNextSlot(virDomainPCIAddressSetPtr addrs,
-   virPCIDeviceAddressPtr next_addr,
-   virDomainPCIConnectFlags flags)
-ATTRIBUTE_NONNULL(1) ATTRIBUTE_NONNULL(2);
-
 int virDomainPCIAddressReserveNextAddr(virDomainPCIAddressSetPtr addrs,
virDomainDeviceInfoPtr dev,
virDomainPCIConnectFlags flags,
diff --git a/src/libvirt_private.syms b/src/libvirt_private.syms
index 9f9512a..0c76f17 100644
--- a/src/libvirt_private.syms
+++ b/src/libvirt_private.syms
@@ -99,7 +99,6 @@ virDomainPCIAddressAsString;
 virDomainPCIAddressBusSetModel;
 virDomainPCIAddressEnsureAddr;
 virDomainPCIAddressFlagsCompatible;
-virDomainPCIAddressGetNextSlot;
 virDomainPCIAddressReleaseSlot;
 virDomainPCIAddressReserveAddr;
 virDomainPCIAddressReserveNextAddr;
-- 
2.7.4

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list


[libvirt] [PATCH v4 15/25] [NEW] qemu: set pciConnectFlags to 0 instead of PCI|HOTPLUGGABLE if device isn't PCI

2016-10-14 Thread Laine Stump
This patch cleans up the connect flags for certain types/models of
devices that aren't PCI to return 0. In the future that may be used as
an indicator to the caller about whether or not a device needs a PCI
address. For now it's just ignored, except for in
virDomainPCIAddressEnsureAddr() - called during device hotplug - (and
in some cases actually needs to be re-set to PCI|HOTPLUGGABLE just in
case someone (in some old config) has manually set a PCI address for a
device that isn't PCI.
---

This was previously a part of patch 12. split out to enable
demonstrating that it is a NOP.

 src/conf/domain_addr.c |  6 +
 src/qemu/qemu_domain_address.c | 54 +-
 2 files changed, 38 insertions(+), 22 deletions(-)

diff --git a/src/conf/domain_addr.c b/src/conf/domain_addr.c
index fcd5fc1..e25a63f 100644
--- a/src/conf/domain_addr.c
+++ b/src/conf/domain_addr.c
@@ -491,6 +491,12 @@ virDomainPCIAddressEnsureAddr(virDomainPCIAddressSetPtr 
addrs,
 int ret = -1;
 char *addrStr = NULL;
 
+/* if flags is 0, the particular model of this device on this
+ * machinetype doesn't need a PCI address, so we're done.
+ */
+if (!flags)
+   return 0;
+
 if (!(addrStr = virDomainPCIAddressAsString(>addr.pci)))
 goto cleanup;
 
diff --git a/src/qemu/qemu_domain_address.c b/src/qemu/qemu_domain_address.c
index 991cfa7..22d859e 100644
--- a/src/qemu/qemu_domain_address.c
+++ b/src/qemu/qemu_domain_address.c
@@ -465,8 +465,7 @@ 
qemuDomainDeviceCalculatePCIConnectFlags(virDomainDeviceDefPtr dev,
 case VIR_DOMAIN_CONTROLLER_MODEL_USB_QUSB2: /* xen only */
 case VIR_DOMAIN_CONTROLLER_MODEL_USB_NONE:
 case VIR_DOMAIN_CONTROLLER_MODEL_USB_LAST:
-/* should be 0 */
-return pciFlags;
+return 0;
 }
 
 case VIR_DOMAIN_CONTROLLER_TYPE_IDE:
@@ -495,8 +494,7 @@ 
qemuDomainDeviceCalculatePCIConnectFlags(virDomainDeviceDefPtr dev,
  */
 if (net->type == VIR_DOMAIN_NET_TYPE_HOSTDEV ||
 STREQ(net->model, "usb-net")) {
-/* should be 0 */
-return pciFlags;
+return 0;
 }
 return pciFlags;
 }
@@ -513,8 +511,7 @@ 
qemuDomainDeviceCalculatePCIConnectFlags(virDomainDeviceDefPtr dev,
 case VIR_DOMAIN_SOUND_MODEL_PCSPK:
 case VIR_DOMAIN_SOUND_MODEL_USB:
 case VIR_DOMAIN_SOUND_MODEL_LAST:
-/* should be 0 */
-return pciFlags;
+return 0;
 }
 
 case VIR_DOMAIN_DEVICE_DISK:
@@ -531,8 +528,7 @@ 
qemuDomainDeviceCalculatePCIConnectFlags(virDomainDeviceDefPtr dev,
 case VIR_DOMAIN_DISK_BUS_SATA:
 case VIR_DOMAIN_DISK_BUS_SD:
 case VIR_DOMAIN_DISK_BUS_LAST:
-/* should be 0 */
-return pciFlags;
+return 0;
 }
 
 case VIR_DOMAIN_DEVICE_HOSTDEV:
@@ -546,8 +542,7 @@ 
qemuDomainDeviceCalculatePCIConnectFlags(virDomainDeviceDefPtr dev,
 case VIR_DOMAIN_MEMBALLOON_MODEL_XEN:
 case VIR_DOMAIN_MEMBALLOON_MODEL_NONE:
 case VIR_DOMAIN_MEMBALLOON_MODEL_LAST:
-/* should be 0 (not PCI) */
-return pciFlags;
+return 0;
 }
 
 case VIR_DOMAIN_DEVICE_RNG:
@@ -556,8 +551,7 @@ 
qemuDomainDeviceCalculatePCIConnectFlags(virDomainDeviceDefPtr dev,
 return pciFlags;
 
 case VIR_DOMAIN_RNG_MODEL_LAST:
-/* should be 0 */
-return pciFlags;
+return 0;
 }
 
 case VIR_DOMAIN_DEVICE_WATCHDOG:
@@ -569,8 +563,7 @@ 
qemuDomainDeviceCalculatePCIConnectFlags(virDomainDeviceDefPtr dev,
 case VIR_DOMAIN_WATCHDOG_MODEL_IB700:
 case VIR_DOMAIN_WATCHDOG_MODEL_DIAG288:
 case VIR_DOMAIN_WATCHDOG_MODEL_LAST:
-/* should be 0 */
-return pciFlags;
+return 0;
 }
 
 case VIR_DOMAIN_DEVICE_VIDEO:
@@ -586,8 +579,7 @@ 
qemuDomainDeviceCalculatePCIConnectFlags(virDomainDeviceDefPtr dev,
 return pciFlags;
 
 case VIR_DOMAIN_VIDEO_TYPE_LAST:
-/* should be 0 */
-return pciFlags;
+return 0;
 }
 
 
@@ -604,8 +596,7 @@ 
qemuDomainDeviceCalculatePCIConnectFlags(virDomainDeviceDefPtr dev,
 case VIR_DOMAIN_INPUT_BUS_XEN:
 case VIR_DOMAIN_INPUT_BUS_PARALLELS:
 case VIR_DOMAIN_INPUT_BUS_LAST:
-/* should be 0 */
-return pciFlags;
+return 0;
 }
 
 case VIR_DOMAIN_DEVICE_CHR:
@@ -616,8 +607,7 @@ 
qemuDomainDeviceCalculatePCIConnectFlags(virDomainDeviceDefPtr dev,
 case VIR_DOMAIN_CHR_SERIAL_TARGET_TYPE_ISA:
 case VIR_DOMAIN_CHR_SERIAL_TARGET_TYPE_USB:
 case VIR_DOMAIN_CHR_SERIAL_TARGET_TYPE_LAST:
-/* should be 0 */
-return pciFlags;
+return 0;
 }
 
 /* These devices don't ever connect with PCI */
@@ -634,8 

[libvirt] [PATCH v4 04/25] [NEW] conf: add typedef for anonymous enum used for memballoon device model

2016-10-14 Thread Laine Stump
For some reason the values of memballoon model are set using an
anonymous enum, making it impossible to perform nice tricks like
demanding there are cases for all possible values in a switch. This
patch turns the anonymous enum into virDomainMemBalloonModel.
---
 src/conf/domain_conf.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/src/conf/domain_conf.h b/src/conf/domain_conf.h
index 3e85ae4..d415d2e 100644
--- a/src/conf/domain_conf.h
+++ b/src/conf/domain_conf.h
@@ -1536,13 +1536,13 @@ struct _virDomainRedirFilterDef {
 virDomainRedirFilterUSBDevDefPtr *usbdevs;
 };
 
-enum {
+typedef enum {
 VIR_DOMAIN_MEMBALLOON_MODEL_VIRTIO,
 VIR_DOMAIN_MEMBALLOON_MODEL_XEN,
 VIR_DOMAIN_MEMBALLOON_MODEL_NONE,
 
 VIR_DOMAIN_MEMBALLOON_MODEL_LAST
-};
+} virDomainMemBalloonModel;
 
 struct _virDomainMemballoonDef {
 int model;
-- 
2.7.4

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list


[libvirt] [PATCH v4 25/25] qemu: initially reserve one open pcie-root-port for hotplug

2016-10-14 Thread Laine Stump
For machinetypes with a pci-root bus (all legacy PCI), libvirt will
make a "fake" reservation for one extra slot prior to assigning
addresses to unaddressed PCI endpoint devices in the domain. This will
trigger auto-adding of a pci-bridge for the final device to be
assigned an address *if that device would have otherwise instead been
the last device on the last available pci-bridge*; thus it assures
that there will always be at least one slot left open in the domain's
bus topology for expansion (which is important both for hotplug (since
a new pci-bridge can't be added while the guest is running) as well as
for offline additions to the config (since adding a new device might
otherwise in some cases require re-addressing existing devices, which
we want to avoid)).

It's important to note that for the above case (legacy PCI), we must
check for the special case of all slots on all buses being occupied
*prior to assigning any addresses*, and avoid attempting to reserve
the extra address in that case, because there is no free address in
the existing topology, so no place to auto-add a pci-bridge for
expansion (i.e. it would always fail anyway). Since that condition can
only be reached by manual intervention, this is acceptable.

For machinetypes with pcie-root (Q35, aarch64 virt), libvirt's
methodology for automatically expanding the bus topology is different
- pcie-root-ports are plugged into slots (soon to be functions) of
pcie-root as needed, and the new endpoint devices are assigned to the
single slot in each pcie-root-port. This is done so that the devices
are, by default, hotpluggable (the slots of pcie-root don't support
hotplug, but the single slot of the pcie-root-port does). Since
pcie-root-ports can only be plugged into pcie-root, and we don't
auto-assign endpoint devices to the pcie-root slots, this means
topology expansion doesn't compete with endpoint devices for slots, so
we don't need to worry about checking for all "useful" slots being
free *prior* to assigning addresses to new endpoint devices - as a
matter of fact, if we attempt to reserve the open slots before the
used slots, it can lead to errors.

Instead this patch just reserves one slot for a "future potential"
PCIe device after doing the assignment for actual devices, but only
if the only PCI controller defined prior to starting address
assignment was pcie-root, and only if we auto-added at least one PCI
controller during address assignment.  This assures two things:

1) that reserving the open slots will only be done when the domain is
   initially defined, never at any time after, and

2) that if the user understands enough about PCI controllers that they
   are adding them manually, that we don't mess up their plan by
   adding extras - if they know enough to add one pcie-root-port, or
   to manually assign addresses such that no pcie-root-ports are
   needed, they know enough to add extra pcie-root-ports if they want
   them (this could be called the "libguestfs clause", since
   libguestfs needs to be able to create domains with as few
   devices/controllers as possible).

This is set to reserve a single free port for now, but could be
increased in the future if public sentiment goes in that direction
(it's easy to increase later, but essential impossible to decrease)
---

Change: now adds a single root-port instead of 4, and only does so
during initial definition, not at a later time.

 src/qemu/qemu_domain_address.c | 30 
 .../qemuxml2argv-bios-nvram-secure.args|  1 +
 .../qemuxml2argv-machine-smm-opt.args  |  1 +
 .../qemuxml2argv-q35-default-devices-only.args |  1 +
 .../qemuxml2argv-q35-pcie-autoadd.args |  1 +
 .../qemuxml2argv-q35-pm-disable-fallback.args  |  1 +
 .../qemuxml2argv-q35-pm-disable.args   |  1 +
 .../qemuxml2argv-q35-virt-manager-basic.args   |  1 +
 tests/qemuxml2argvtest.c   | 33 ++
 .../qemuxml2xmlout-q35-default-devices-only.xml|  5 
 .../qemuxml2xmlout-q35-pcie-autoadd.xml|  5 
 .../qemuxml2xmlout-q35-virt-manager-basic.xml  |  5 
 tests/qemuxml2xmltest.c| 19 +++--
 13 files changed, 96 insertions(+), 8 deletions(-)

diff --git a/src/qemu/qemu_domain_address.c b/src/qemu/qemu_domain_address.c
index 8c4a5de..f27d1e3 100644
--- a/src/qemu/qemu_domain_address.c
+++ b/src/qemu/qemu_domain_address.c
@@ -1937,6 +1937,36 @@ qemuDomainAssignPCIAddresses(virDomainDefPtr def,
 if (qemuDomainAssignDevicePCISlots(def, qemuCaps, addrs) < 0)
 goto cleanup;
 
+/* Only for *new* domains with pcie-root (and no other
+ * manually specified PCI controllers in the definition): If,
+ * after assigning addresses/reserving slots for all devices,
+ * we see that any extra buses have been auto-added, we
+ * understand that the application has left 

[libvirt] [PATCH v4 18/25] qemu: assign nec-xhci (USB3) controller to a PCIe address when appropriate

2016-10-14 Thread Laine Stump
The nec-usb-xhci device (which is a USB3 controller) has always
presented itself as a PCI device when plugged into a legacy PCI slot,
and a PCIe device when plugged into a PCIe slot, but libvirt has
always auto-assigned it to a legacy PCI slot.

This patch changes that behavior to auto-assign to a PCIe slot on
systems that have pcie-root (e.g. Q35 and aarch64/virt).

Since we don't yet auto-create pcie-*-port controllers on demand, this
means a config with an nec-xhci USB controller that has no PCI address
assigned will also need to have an otherwise-unused pcie-*-port
controller specified:

   
   

(this assumes there is an otherwise-unused slot on pcie-root to accept
the pcie-root-port)
---

Change: changed to fit reimplemented
qemuDomainDeviceCalculatePCIConnectFlags()

 src/qemu/qemu_domain_address.c |  2 +-
 tests/qemuxml2argvdata/qemuxml2argv-autoindex.args | 10 +++
 tests/qemuxml2argvdata/qemuxml2argv-q35-pcie.args  | 21 ++---
 tests/qemuxml2argvdata/qemuxml2argv-q35-pcie.xml   |  2 ++
 .../qemuxml2argv-q35-virtio-pci.args   |  7 ++---
 tests/qemuxml2argvtest.c   |  2 ++
 .../qemuxml2xmlout-autoindex.xml   | 10 +++
 .../qemuxml2xmloutdata/qemuxml2xmlout-q35-pcie.xml | 35 +-
 .../qemuxml2xmlout-q35-virtio-pci.xml  | 21 +
 tests/qemuxml2xmltest.c|  2 ++
 10 files changed, 49 insertions(+), 63 deletions(-)

diff --git a/src/qemu/qemu_domain_address.c b/src/qemu/qemu_domain_address.c
index 69e530e..5262ad3 100644
--- a/src/qemu/qemu_domain_address.c
+++ b/src/qemu/qemu_domain_address.c
@@ -446,7 +446,7 @@ 
qemuDomainDeviceCalculatePCIConnectFlags(virDomainDeviceDefPtr dev,
 case VIR_DOMAIN_CONTROLLER_TYPE_USB:
 switch ((virDomainControllerModelUSB)cont->model) {
 case VIR_DOMAIN_CONTROLLER_MODEL_USB_NEC_XHCI:
-return pciFlags;
+return pcieFlags;
 
 case VIR_DOMAIN_CONTROLLER_MODEL_USB_EHCI:
 case VIR_DOMAIN_CONTROLLER_MODEL_USB_ICH9_EHCI1:
diff --git a/tests/qemuxml2argvdata/qemuxml2argv-autoindex.args 
b/tests/qemuxml2argvdata/qemuxml2argv-autoindex.args
index 43b9661..fc14dc4 100644
--- a/tests/qemuxml2argvdata/qemuxml2argv-autoindex.args
+++ b/tests/qemuxml2argvdata/qemuxml2argv-autoindex.args
@@ -43,11 +43,11 @@ addr=0x1 \
 -device ich9-usb-uhci2,masterbus=usb2.0,firstport=2,bus=pci.2,addr=0x1.0x1 \
 -device ich9-usb-uhci3,masterbus=usb2.0,firstport=4,bus=pci.2,addr=0x1.0x2 \
 -device ich9-usb-ehci1,id=usb2,bus=pci.2,addr=0x1.0x7 \
--device nec-usb-xhci,id=usb3,bus=pci.2,addr=0x2 \
+-device nec-usb-xhci,id=usb3,bus=pci.5,addr=0x0 \
 -device 
ich9-usb-uhci1,masterbus=usb4.0,firstport=0,bus=pci.2,multifunction=on,\
-addr=0x3 \
--device ich9-usb-uhci2,masterbus=usb4.0,firstport=2,bus=pci.2,addr=0x3.0x1 \
--device ich9-usb-uhci3,masterbus=usb4.0,firstport=4,bus=pci.2,addr=0x3.0x2 \
--device ich9-usb-ehci1,id=usb4,bus=pci.2,addr=0x3.0x7 \
+addr=0x2 \
+-device ich9-usb-uhci2,masterbus=usb4.0,firstport=2,bus=pci.2,addr=0x2.0x1 \
+-device ich9-usb-uhci3,masterbus=usb4.0,firstport=4,bus=pci.2,addr=0x2.0x2 \
+-device ich9-usb-ehci1,id=usb4,bus=pci.2,addr=0x2.0x7 \
 -drive file=/dev/HostVG/QEMUGuest1,format=raw,if=none,id=drive-sata0-0-0 \
 -device ide-drive,bus=ide.0,drive=drive-sata0-0-0,id=sata0-0-0
diff --git a/tests/qemuxml2argvdata/qemuxml2argv-q35-pcie.args 
b/tests/qemuxml2argvdata/qemuxml2argv-q35-pcie.args
index d92e0b8..2738749 100644
--- a/tests/qemuxml2argvdata/qemuxml2argv-q35-pcie.args
+++ b/tests/qemuxml2argvdata/qemuxml2argv-q35-pcie.args
@@ -30,15 +30,12 @@ QEMU_AUDIO_DRV=none \
 -device ioh3420,port=0x58,chassis=12,id=pci.12,bus=pcie.0,addr=0xb \
 -device ioh3420,port=0x60,chassis=13,id=pci.13,bus=pcie.0,addr=0xc \
 -device ioh3420,port=0x68,chassis=14,id=pci.14,bus=pcie.0,addr=0xd \
--device ich9-usb-ehci1,id=usb,bus=pcie.0,addr=0x1d.0x7 \
--device 
ich9-usb-uhci1,masterbus=usb.0,firstport=0,bus=pcie.0,multifunction=on,\
-addr=0x1d \
--device ich9-usb-uhci2,masterbus=usb.0,firstport=2,bus=pcie.0,addr=0x1d.0x1 \
--device ich9-usb-uhci3,masterbus=usb.0,firstport=4,bus=pcie.0,addr=0x1d.0x2 \
+-device ioh3420,port=0x70,chassis=15,id=pci.15,bus=pcie.0,addr=0xe \
+-device nec-usb-xhci,id=usb,bus=pci.8,addr=0x0 \
 -device virtio-scsi-pci,id=scsi0,bus=pci.7,addr=0x0 \
 -device virtio-serial-pci,id=virtio-serial0,bus=pci.6,addr=0x0 \
 -drive file=/dev/HostVG/QEMUGuest1,format=raw,if=none,id=drive-virtio-disk1 \
--device virtio-blk-pci,bus=pci.8,addr=0x0,drive=drive-virtio-disk1,\
+-device virtio-blk-pci,bus=pci.9,addr=0x0,drive=drive-virtio-disk1,\
 id=virtio-disk1 \
 -fsdev local,security_model=passthrough,id=fsdev-fs0,path=/export/to/guest \
 -device virtio-9p-pci,id=fs0,fsdev=fsdev-fs0,mount_tag=/import/from/host,\
@@ -49,13 +46,13 @@ addr=0x0 \
 -netdev user,id=hostnet1 \
 -device 

[libvirt] [PATCH v4 05/25] [NEW] qemu: remove superfluous setting of addrs->nbuses

2016-10-14 Thread Laine Stump
This is already set by virDomainPCIAddressSetAlloc().
---
 src/qemu/qemu_domain_address.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/src/qemu/qemu_domain_address.c b/src/qemu/qemu_domain_address.c
index d2a3237..3926b18 100644
--- a/src/qemu/qemu_domain_address.c
+++ b/src/qemu/qemu_domain_address.c
@@ -556,7 +556,6 @@ qemuDomainPCIAddressSetCreate(virDomainDefPtr def,
 if ((addrs = virDomainPCIAddressSetAlloc(nbuses)) == NULL)
 return NULL;
 
-addrs->nbuses = nbuses;
 addrs->dryRun = dryRun;
 
 /* As a safety measure, set default model='pci-root' for first pci
-- 
2.7.4

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list


[libvirt] [PATCH v4 06/25] [NEW] qemu: make error message in qemuDomainPCIAddressSetCreate more clear.

2016-10-14 Thread Laine Stump
This error should only ever be seen by a developer anyway, but the
existing message made even less sense that this new version.
---
 src/qemu/qemu_domain_address.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/qemu/qemu_domain_address.c b/src/qemu/qemu_domain_address.c
index 3926b18..8628dc1 100644
--- a/src/qemu/qemu_domain_address.c
+++ b/src/qemu/qemu_domain_address.c
@@ -583,7 +583,7 @@ qemuDomainPCIAddressSetCreate(virDomainDefPtr def,
 if (idx >= addrs->nbuses) {
 virReportError(VIR_ERR_INTERNAL_ERROR,
_("Inappropriate new pci controller index %zu "
- "not found in addrs"), idx);
+ "exceeds addrs array length"), idx);
 goto error;
 }
 
-- 
2.7.4

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list


[libvirt] [PATCH v4 09/25] [ACKED] qemu: use virDomainPCIAddressReserveNextAddr in qemuDomainAssignDevicePCISlots

2016-10-14 Thread Laine Stump
instead of calling virDomainPCIAddressGetNextSlot() (which I want to
turn into a local static in domain_addr.c).
---

Change: fixed line length

 src/qemu/qemu_domain_address.c | 33 +++--
 1 file changed, 15 insertions(+), 18 deletions(-)

diff --git a/src/qemu/qemu_domain_address.c b/src/qemu/qemu_domain_address.c
index 8628dc1..fa52383 100644
--- a/src/qemu/qemu_domain_address.c
+++ b/src/qemu/qemu_domain_address.c
@@ -1005,7 +1005,6 @@ qemuDomainAssignDevicePCISlots(virDomainDefPtr def,
 {
 size_t i, j;
 virDomainPCIConnectFlags flags = 0; /* initialize to quiet gcc warning */
-virPCIDeviceAddress tmp_addr;
 
 /* PCI controllers */
 for (i = 0; i < def->ncontrollers; i++) {
@@ -1113,7 +1112,6 @@ qemuDomainAssignDevicePCISlots(virDomainDefPtr def,
 virPCIDeviceAddress addr = {0};
 bool foundAddr = false;
 
-memset(_addr, 0, sizeof(tmp_addr));
 for (j = 0; j < def->ncontrollers; j++) {
 if (IS_USB2_CONTROLLER(def->controllers[j]) &&
 def->controllers[j]->idx == cont->idx &&
@@ -1143,26 +1141,25 @@ qemuDomainAssignDevicePCISlots(virDomainDefPtr def,
 break;
 }
 
-if (!foundAddr) {
-/* This is the first part of the controller, so need
- * to find a free slot & then reserve a function */
-if (virDomainPCIAddressGetNextSlot(addrs, _addr, flags) < 
0)
+if (foundAddr) {
+/* Reserve this function on the slot we found */
+if (virDomainPCIAddressReserveAddr(addrs, , flags,
+   false, true) < 0)
 goto error;
 
-addr.bus = tmp_addr.bus;
-addr.slot = tmp_addr.slot;
+cont->info.type = VIR_DOMAIN_DEVICE_ADDRESS_TYPE_PCI;
+cont->info.addr.pci = addr;
+} else {
+/* This is the first part of the controller, so need
+ * to find a free slot & then reserve this function */
+if (virDomainPCIAddressReserveNextAddr(addrs, >info,
+   flags, addr.function,
+   false) < 0) {
+goto error;
+}
 
-addrs->lastaddr = addr;
-addrs->lastaddr.function = 0;
-addrs->lastaddr.multi = VIR_TRISTATE_SWITCH_ABSENT;
+cont->info.addr.pci.multi = addr.multi;
 }
-/* Finally we can reserve the slot+function */
-if (virDomainPCIAddressReserveAddr(addrs, , flags,
-   false, foundAddr) < 0)
-goto error;
-
-cont->info.type = VIR_DOMAIN_DEVICE_ADDRESS_TYPE_PCI;
-cont->info.addr.pci = addr;
 } else {
 if (virDomainPCIAddressReserveNextSlot(addrs,
>info, flags) < 0) {
-- 
2.7.4

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list


[libvirt] [PATCH v4 22/25] [ACKED] qemu: don't force-add a dmi-to-pci-bridge just on principle

2016-10-14 Thread Laine Stump
Now the a dmi-to-pci-bridge is automatically added just as it's needed
(when a pci-bridge is being added), we no longer have any need to
force-add one to every single Q35 domain.
---
 src/qemu/qemu_domain.c | 12 
 tests/qemuxml2argvdata/qemuxml2argv-pcie-root.args |  3 +-
 .../qemuxml2argv-q35-pcie-autoadd.args | 55 +++
 .../qemuxml2xmlout-pcie-root.xml   |  4 --
 .../qemuxml2xmlout-q35-pcie-autoadd.xml| 82 ++
 5 files changed, 67 insertions(+), 89 deletions(-)

diff --git a/src/qemu/qemu_domain.c b/src/qemu/qemu_domain.c
index aa54206..bd5c7ec 100644
--- a/src/qemu/qemu_domain.c
+++ b/src/qemu/qemu_domain.c
@@ -2084,18 +2084,6 @@ qemuDomainDefAddDefaultDevices(virDomainDefPtr def,
  
VIR_DOMAIN_CONTROLLER_MODEL_PCIE_ROOT)) {
 goto cleanup;
 }
-/* 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.
- *
- * 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;
 }
 
 if (addDefaultMemballoon && !def->memballoon) {
diff --git a/tests/qemuxml2argvdata/qemuxml2argv-pcie-root.args 
b/tests/qemuxml2argvdata/qemuxml2argv-pcie-root.args
index 7ef03d3..59a849f 100644
--- a/tests/qemuxml2argvdata/qemuxml2argv-pcie-root.args
+++ b/tests/qemuxml2argvdata/qemuxml2argv-pcie-root.args
@@ -15,5 +15,4 @@ QEMU_AUDIO_DRV=none \
 -nodefaults \
 -monitor unix:/tmp/lib/domain--1-q35-test/monitor.sock,server,nowait \
 -no-acpi \
--boot c \
--device i82801b11-bridge,id=pci.1,bus=pcie.0,addr=0x1e
+-boot c
diff --git a/tests/qemuxml2argvdata/qemuxml2argv-q35-pcie-autoadd.args 
b/tests/qemuxml2argvdata/qemuxml2argv-q35-pcie-autoadd.args
index 70c759e..daecf96 100644
--- a/tests/qemuxml2argvdata/qemuxml2argv-q35-pcie-autoadd.args
+++ b/tests/qemuxml2argvdata/qemuxml2argv-q35-pcie-autoadd.args
@@ -16,42 +16,41 @@ QEMU_AUDIO_DRV=none \
 -monitor unix:/tmp/lib/domain--1-q35-test/monitor.sock,server,nowait \
 -no-acpi \
 -boot c \
--device i82801b11-bridge,id=pci.1,bus=pcie.0,addr=0x1e \
--device ioh3420,port=0x10,chassis=2,id=pci.2,bus=pcie.0,addr=0x2 \
--device ioh3420,port=0x18,chassis=3,id=pci.3,bus=pcie.0,addr=0x3 \
--device ioh3420,port=0x20,chassis=4,id=pci.4,bus=pcie.0,addr=0x4 \
--device ioh3420,port=0x28,chassis=5,id=pci.5,bus=pcie.0,addr=0x5 \
--device ioh3420,port=0x30,chassis=6,id=pci.6,bus=pcie.0,addr=0x6 \
--device ioh3420,port=0x38,chassis=7,id=pci.7,bus=pcie.0,addr=0x7 \
--device ioh3420,port=0x40,chassis=8,id=pci.8,bus=pcie.0,addr=0x8 \
--device ioh3420,port=0x48,chassis=9,id=pci.9,bus=pcie.0,addr=0x9 \
--device ioh3420,port=0x50,chassis=10,id=pci.10,bus=pcie.0,addr=0xa \
--device ioh3420,port=0x58,chassis=11,id=pci.11,bus=pcie.0,addr=0xb \
--device ioh3420,port=0x60,chassis=12,id=pci.12,bus=pcie.0,addr=0xc \
--device ioh3420,port=0x68,chassis=13,id=pci.13,bus=pcie.0,addr=0xd \
--device ioh3420,port=0x70,chassis=14,id=pci.14,bus=pcie.0,addr=0xe \
--device nec-usb-xhci,id=usb,bus=pci.7,addr=0x0 \
--device virtio-scsi-pci,id=scsi0,bus=pci.6,addr=0x0 \
--device virtio-serial-pci,id=virtio-serial0,bus=pci.5,addr=0x0 \
+-device ioh3420,port=0x10,chassis=1,id=pci.1,bus=pcie.0,addr=0x2 \
+-device ioh3420,port=0x18,chassis=2,id=pci.2,bus=pcie.0,addr=0x3 \
+-device ioh3420,port=0x20,chassis=3,id=pci.3,bus=pcie.0,addr=0x4 \
+-device ioh3420,port=0x28,chassis=4,id=pci.4,bus=pcie.0,addr=0x5 \
+-device ioh3420,port=0x30,chassis=5,id=pci.5,bus=pcie.0,addr=0x6 \
+-device ioh3420,port=0x38,chassis=6,id=pci.6,bus=pcie.0,addr=0x7 \
+-device ioh3420,port=0x40,chassis=7,id=pci.7,bus=pcie.0,addr=0x8 \
+-device ioh3420,port=0x48,chassis=8,id=pci.8,bus=pcie.0,addr=0x9 \
+-device ioh3420,port=0x50,chassis=9,id=pci.9,bus=pcie.0,addr=0xa \
+-device ioh3420,port=0x58,chassis=10,id=pci.10,bus=pcie.0,addr=0xb \
+-device ioh3420,port=0x60,chassis=11,id=pci.11,bus=pcie.0,addr=0xc \
+-device ioh3420,port=0x68,chassis=12,id=pci.12,bus=pcie.0,addr=0xd \
+-device ioh3420,port=0x70,chassis=13,id=pci.13,bus=pcie.0,addr=0xe \
+-device nec-usb-xhci,id=usb,bus=pci.6,addr=0x0 \
+-device virtio-scsi-pci,id=scsi0,bus=pci.5,addr=0x0 \
+-device virtio-serial-pci,id=virtio-serial0,bus=pci.4,addr=0x0 \
 -drive file=/dev/HostVG/QEMUGuest1,format=raw,if=none,id=drive-virtio-disk1 \
--device virtio-blk-pci,bus=pci.8,addr=0x0,drive=drive-virtio-disk1,\
+-device virtio-blk-pci,bus=pci.7,addr=0x0,drive=drive-virtio-disk1,\
 id=virtio-disk1 \
 -fsdev 

[libvirt] [PATCH v9 2/5] conf: Introduce {default|chardev}_tls_x509_secret_uuid

2016-10-14 Thread John Ferlan
Add a new qemu.conf variables to store the UUID for the secret that could
be used to present credentials to access the TLS chardev.  Since this will
be a server level and it's possible to use some sort of default, introduce
both the default and chardev logic at the same time making the setting of
the chardev check for it's own value, then if not present checking whether
the default value had been set.

Signed-off-by: John Ferlan 
---
 src/qemu/libvirtd_qemu.aug |  2 ++
 src/qemu/qemu.conf | 24 
 src/qemu/qemu_conf.c   | 14 ++
 src/qemu/qemu_conf.h   |  2 ++
 src/qemu/test_libvirtd_qemu.aug.in |  2 ++
 5 files changed, 44 insertions(+)

diff --git a/src/qemu/libvirtd_qemu.aug b/src/qemu/libvirtd_qemu.aug
index 988201e..73ebeda 100644
--- a/src/qemu/libvirtd_qemu.aug
+++ b/src/qemu/libvirtd_qemu.aug
@@ -29,6 +29,7 @@ module Libvirtd_qemu =
(* Config entry grouped by function - same order as example config *)
let default_tls_entry = str_entry "default_tls_x509_cert_dir"
  | bool_entry "default_tls_x509_verify"
+ | str_entry "default_tls_x509_secret_uuid"
 
let vnc_entry = str_entry "vnc_listen"
  | bool_entry "vnc_auto_unix_socket"
@@ -51,6 +52,7 @@ module Libvirtd_qemu =
let chardev_entry = bool_entry "chardev_tls"
  | str_entry "chardev_tls_x509_cert_dir"
  | bool_entry "chardev_tls_x509_verify"
+ | str_entry "chardev_tls_x509_secret_uuid"
 
let nogfx_entry = bool_entry "nographics_allow_host_audio"
 
diff --git a/src/qemu/qemu.conf b/src/qemu/qemu.conf
index e4c2aae..493c171 100644
--- a/src/qemu/qemu.conf
+++ b/src/qemu/qemu.conf
@@ -28,6 +28,20 @@
 #
 #default_tls_x509_verify = 1
 
+#
+# Libvirt assumes the server-key.pem file is unencrypted by default.
+# To use an encrypted server-key.pem file, the password to decrypt the
+# the PEM file is required. This can be provided by creating a secret
+# object in libvirt and then to uncomment this setting to set the UUID
+# of the secret.
+#
+# NB This default all-zeros UUID will not work. Replace it with the
+# output from the UUID for the TLS secret from a 'virsh secret-list'
+# command and then uncomment the entry
+#
+#default_tls_x509_secret_uuid = "----"
+
+
 # VNC is configured to listen on 127.0.0.1 by default.
 # To make it listen on all public interfaces, uncomment
 # this next option.
@@ -214,6 +228,16 @@
 #chardev_tls_x509_verify = 1
 
 
+# Uncomment and use the following option to override the default secret
+# uuid provided in the default_tls_x509_secret_uuid parameter.
+#
+# NB This default all-zeros UUID will not work. Replace it with the
+# output from the UUID for the TLS secret from a 'virsh secret-list'
+# command and then uncomment the entry
+#
+#chardev_tls_x509_secret_uuid = "----"
+
+
 # By default, if no graphical front end is configured, libvirt will disable
 # QEMU audio output since directly talking to alsa/pulseaudio may not work
 # with various security settings. If you know what you're doing, enable
diff --git a/src/qemu/qemu_conf.c b/src/qemu/qemu_conf.c
index 635fa27..109668b 100644
--- a/src/qemu/qemu_conf.c
+++ b/src/qemu/qemu_conf.c
@@ -365,6 +365,7 @@ static void virQEMUDriverConfigDispose(void *obj)
 VIR_FREE(cfg->nvramDir);
 
 VIR_FREE(cfg->defaultTLSx509certdir);
+VIR_FREE(cfg->defaultTLSx509secretUUID);
 
 VIR_FREE(cfg->vncTLSx509certdir);
 VIR_FREE(cfg->vncListen);
@@ -377,6 +378,7 @@ static void virQEMUDriverConfigDispose(void *obj)
 VIR_FREE(cfg->spiceSASLdir);
 
 VIR_FREE(cfg->chardevTLSx509certdir);
+VIR_FREE(cfg->chardevTLSx509secretUUID);
 
 while (cfg->nhugetlbfs) {
 cfg->nhugetlbfs--;
@@ -446,6 +448,10 @@ int virQEMUDriverConfigLoadFile(virQEMUDriverConfigPtr cfg,
 goto cleanup;
 if (virConfGetValueBool(conf, "default_tls_x509_verify", 
>defaultTLSx509verify) < 0)
 goto cleanup;
+if (virConfGetValueString(conf, "default_tls_x509_secret_uuid",
+  >defaultTLSx509secretUUID) < 0)
+goto cleanup;
+
 if (virConfGetValueBool(conf, "vnc_auto_unix_socket", 
>vncAutoUnixSocket) < 0)
 goto cleanup;
 if (virConfGetValueBool(conf, "vnc_tls", >vncTLS) < 0)
@@ -513,6 +519,14 @@ int virQEMUDriverConfigLoadFile(virQEMUDriverConfigPtr cfg,
 goto cleanup;
 if (rv == 0)
 cfg->chardevTLSx509verify = cfg->defaultTLSx509verify;
+if (virConfGetValueString(conf, "chardev_tls_x509_secret_uuid",
+  >chardevTLSx509secretUUID) < 0)
+goto cleanup;
+if (!cfg->chardevTLSx509secretUUID && cfg->defaultTLSx509secretUUID) {
+if (VIR_STRDUP(cfg->chardevTLSx509secretUUID,
+   cfg->defaultTLSx509secretUUID) < 0)
+goto cleanup;
+}
 
 if 

[libvirt] [PATCH v9 1/5] domain: Add optional 'tls' attribute for TCP chardev

2016-10-14 Thread John Ferlan
Add an optional "tls='yes|no'" attribute for a TCP chardev for the
express purpose to disable setting up TLS for the specific chardev in
the event the qemu.conf settings have enabled hypervisor wide TLS for
serial TCP chardevs.

Signed-off-by: John Ferlan 
---
 docs/formatdomain.html.in  | 21 +
 docs/schemas/domaincommon.rng  |  5 +++
 src/conf/domain_conf.c | 22 +-
 src/conf/domain_conf.h |  1 +
 src/qemu/qemu_command.c|  3 +-
 src/qemu/qemu_hotplug.c|  3 +-
 ...uxml2argv-serial-tcp-tlsx509-chardev-notls.args | 30 +
 ...muxml2argv-serial-tcp-tlsx509-chardev-notls.xml | 50 ++
 .../qemuxml2argv-serial-tcp-tlsx509-chardev.xml|  2 +-
 tests/qemuxml2argvtest.c   |  3 ++
 ...xml2xmlout-serial-tcp-tlsx509-chardev-notls.xml |  1 +
 .../qemuxml2xmlout-serial-tcp-tlsx509-chardev.xml  |  2 +-
 tests/qemuxml2xmltest.c|  1 +
 13 files changed, 139 insertions(+), 5 deletions(-)
 create mode 100644 
tests/qemuxml2argvdata/qemuxml2argv-serial-tcp-tlsx509-chardev-notls.args
 create mode 100644 
tests/qemuxml2argvdata/qemuxml2argv-serial-tcp-tlsx509-chardev-notls.xml
 create mode 12 
tests/qemuxml2xmloutdata/qemuxml2xmlout-serial-tcp-tlsx509-chardev-notls.xml

diff --git a/docs/formatdomain.html.in b/docs/formatdomain.html.in
index 9051178..6145d65 100644
--- a/docs/formatdomain.html.in
+++ b/docs/formatdomain.html.in
@@ -6204,6 +6204,27 @@ qemu-kvm -net nic,model=? /dev/null
   /devices
   ...
 
+
+  Since 2.4.0, the optional attribute
+  tls can be used to control whether a serial chardev
+  TCP communication channel would utilize a hypervisor configured
+  TLS X.509 certificate environment in order to encrypt the data
+  channel. For the QEMU hypervisor usage of TLS is controlled by the
+  chardev_tls setting in file /etc/libvirt/qemu.conf. If
+  enabled, then by setting this attribute to "no" will disable usage
+  of the TLS environment for this particular serial TCP data channel.
+
+
+  ...
+  devices
+serial type="tcp"
+  source mode='connect' host="127.0.0.1" service="" tls="yes"/
+  protocol type="raw"/
+  target port="0"/
+/serial
+  /devices
+  ...
+
 UDP network console
 
 
diff --git a/docs/schemas/domaincommon.rng b/docs/schemas/domaincommon.rng
index 3106510..e6741bb 100644
--- a/docs/schemas/domaincommon.rng
+++ b/docs/schemas/domaincommon.rng
@@ -3453,6 +3453,11 @@
 
   
 
+
+  
+
+  
+
 
   
 
diff --git a/src/conf/domain_conf.c b/src/conf/domain_conf.c
index 93b34e0..9062544 100644
--- a/src/conf/domain_conf.c
+++ b/src/conf/domain_conf.c
@@ -1997,6 +1997,8 @@ virDomainChrSourceDefCopy(virDomainChrSourceDefPtr dest,
 
 if (VIR_STRDUP(dest->data.tcp.service, src->data.tcp.service) < 0)
 return -1;
+
+dest->data.tcp.haveTLS = src->data.tcp.haveTLS;
 break;
 
 case VIR_DOMAIN_CHR_TYPE_UNIX:
@@ -10038,6 +10040,7 @@ virDomainChrSourceDefParseXML(virDomainChrSourceDefPtr 
def,
 char *master = NULL;
 char *slave = NULL;
 char *append = NULL;
+char *haveTLS = NULL;
 int remaining = 0;
 
 while (cur != NULL) {
@@ -10045,6 +10048,8 @@ virDomainChrSourceDefParseXML(virDomainChrSourceDefPtr 
def,
 if (xmlStrEqual(cur->name, BAD_CAST "source")) {
 if (!mode)
 mode = virXMLPropString(cur, "mode");
+if (!haveTLS)
+haveTLS = virXMLPropString(cur, "tls");
 
 switch ((virDomainChrType) def->type) {
 case VIR_DOMAIN_CHR_TYPE_FILE:
@@ -10221,6 +10226,15 @@ virDomainChrSourceDefParseXML(virDomainChrSourceDefPtr 
def,
 def->data.tcp.listen = true;
 }
 
+if (haveTLS &&
+(def->data.tcp.haveTLS =
+ virTristateBoolTypeFromString(haveTLS)) <= 0) {
+virReportError(VIR_ERR_XML_ERROR,
+   _("unknown chardev 'tls' setting '%s'"),
+   haveTLS);
+goto error;
+}
+
 if (!protocol)
 def->data.tcp.protocol = VIR_DOMAIN_CHR_TCP_PROTOCOL_RAW;
 else if ((def->data.tcp.protocol =
@@ -10305,6 +10319,7 @@ virDomainChrSourceDefParseXML(virDomainChrSourceDefPtr 
def,
 VIR_FREE(append);
 VIR_FREE(logappend);
 VIR_FREE(logfile);
+VIR_FREE(haveTLS);
 
 return remaining;
 
@@ -21453,7 +21468,12 @@ virDomainChrSourceDefFormat(virBufferPtr buf,
 virBufferAsprintf(buf, "data.tcp.listen ? "bind" : "connect");
 virBufferEscapeString(buf, "host='%s' ", def->data.tcp.host);
-virBufferEscapeString(buf, "service='%s'/>\n", 

[libvirt] [PATCH v9 3/5] qemu: Introduce qemuDomainChardevPrivatePtr

2016-10-14 Thread John Ferlan
Modeled after the qemuDomainHostdevPrivatePtr (commit id '27726d8c'),
create a privateData pointer in the _virDomainChardevDef to allow storage
of private data for a hypervisor in order to at least temporarily store
secret data for usage during qemuBuildCommandLine.

NB: Since the qemu_parse_command (qemuParseCommandLine) code is not
expecting to restore the secret data, there's no need to add code
code to handle this new structure there.

Signed-off-by: John Ferlan 
---
 src/conf/domain_conf.c| 29 
 src/conf/domain_conf.h|  4 +++-
 src/libxl/libxl_domain.c  |  2 +-
 src/lxc/lxc_native.c  |  2 +-
 src/qemu/qemu_domain.c| 44 +++
 src/qemu/qemu_domain.h| 14 ++
 src/qemu/qemu_parse_command.c |  4 ++--
 src/vz/vz_sdk.c   |  2 +-
 src/xenconfig/xen_sxpr.c  |  2 +-
 src/xenconfig/xen_xl.c|  2 +-
 10 files changed, 89 insertions(+), 16 deletions(-)

diff --git a/src/conf/domain_conf.c b/src/conf/domain_conf.c
index 9062544..e4fa9ad 100644
--- a/src/conf/domain_conf.c
+++ b/src/conf/domain_conf.c
@@ -2127,6 +2127,8 @@ void virDomainChrDefFree(virDomainChrDefPtr def)
 VIR_FREE(def->seclabels);
 }
 
+virObjectUnref(def->privateData);
+
 VIR_FREE(def);
 }
 
@@ -10333,7 +10335,7 @@ virDomainChrSourceDefParseXML(virDomainChrSourceDefPtr 
def,
  * default port.
  */
 virDomainChrDefPtr
-virDomainChrDefNew(void)
+virDomainChrDefNew(virDomainXMLOptionPtr xmlopt)
 {
 virDomainChrDefPtr def = NULL;
 
@@ -10341,6 +10343,11 @@ virDomainChrDefNew(void)
 return NULL;
 
 def->target.port = -1;
+
+if (xmlopt && xmlopt->privateData.chardevNew &&
+!(def->privateData = xmlopt->privateData.chardevNew()))
+VIR_FREE(def);
+
 return def;
 }
 
@@ -10388,7 +10395,8 @@ virDomainChrDefNew(void)
  *
  */
 static virDomainChrDefPtr
-virDomainChrDefParseXML(xmlXPathContextPtr ctxt,
+virDomainChrDefParseXML(virDomainXMLOptionPtr xmlopt,
+xmlXPathContextPtr ctxt,
 xmlNodePtr node,
 virSecurityLabelDefPtr* vmSeclabels,
 int nvmSeclabels,
@@ -10400,7 +10408,7 @@ virDomainChrDefParseXML(xmlXPathContextPtr ctxt,
 virDomainChrDefPtr def;
 bool seenTarget = false;
 
-if (!(def = virDomainChrDefNew()))
+if (!(def = virDomainChrDefNew(xmlopt)))
 return NULL;
 
 type = virXMLPropString(node, "type");
@@ -13578,7 +13586,8 @@ virDomainDeviceDefParse(const char *xmlStr,
 goto error;
 break;
 case VIR_DOMAIN_DEVICE_CHR:
-if (!(dev->data.chr = virDomainChrDefParseXML(ctxt,
+if (!(dev->data.chr = virDomainChrDefParseXML(xmlopt,
+  ctxt,
   node,
   def->seclabels,
   def->nseclabels,
@@ -17197,7 +17206,8 @@ virDomainDefParseXML(xmlDocPtr xml,
 goto error;
 
 for (i = 0; i < n; i++) {
-virDomainChrDefPtr chr = virDomainChrDefParseXML(ctxt,
+virDomainChrDefPtr chr = virDomainChrDefParseXML(xmlopt,
+ ctxt,
  nodes[i],
  def->seclabels,
  def->nseclabels,
@@ -17224,7 +17234,8 @@ virDomainDefParseXML(xmlDocPtr xml,
 goto error;
 
 for (i = 0; i < n; i++) {
-virDomainChrDefPtr chr = virDomainChrDefParseXML(ctxt,
+virDomainChrDefPtr chr = virDomainChrDefParseXML(xmlopt,
+ ctxt,
  nodes[i],
  def->seclabels,
  def->nseclabels,
@@ -17253,7 +17264,8 @@ virDomainDefParseXML(xmlDocPtr xml,
 goto error;
 
 for (i = 0; i < n; i++) {
-virDomainChrDefPtr chr = virDomainChrDefParseXML(ctxt,
+virDomainChrDefPtr chr = virDomainChrDefParseXML(xmlopt,
+ ctxt,
  nodes[i],
  def->seclabels,
  def->nseclabels,
@@ -17272,7 +17284,8 @@ virDomainDefParseXML(xmlDocPtr xml,
 goto error;
 
 for (i = 0; i < n; i++) {
-virDomainChrDefPtr chr = virDomainChrDefParseXML(ctxt,
+virDomainChrDefPtr chr = virDomainChrDefParseXML(xmlopt,
+ ctxt,
  

[libvirt] [PATCH v9 4/5] qemu: Add a secret object to/for a chardev tcp with secret

2016-10-14 Thread John Ferlan
Add the secret object prior to the chardev tcp so the 'passwordid=' can
be added if the domain XML has a  for the chardev TLS.

Signed-off-by: John Ferlan 
---
 src/qemu/qemu_command.c| 32 ++-
 src/qemu/qemu_command.h|  1 +
 src/qemu/qemu_domain.c | 99 +-
 src/qemu/qemu_domain.h | 16 +++-
 src/qemu/qemu_hotplug.c|  1 +
 src/qemu/qemu_process.c|  6 +-
 ...xml2argv-serial-tcp-tlsx509-secret-chardev.args | 38 +
 ...uxml2argv-serial-tcp-tlsx509-secret-chardev.xml | 50 +++
 tests/qemuxml2argvtest.c   | 18 
 9 files changed, 252 insertions(+), 9 deletions(-)
 create mode 100644 
tests/qemuxml2argvdata/qemuxml2argv-serial-tcp-tlsx509-secret-chardev.args
 create mode 100644 
tests/qemuxml2argvdata/qemuxml2argv-serial-tcp-tlsx509-secret-chardev.xml

diff --git a/src/qemu/qemu_command.c b/src/qemu/qemu_command.c
index aaf7018..b2dfee0 100644
--- a/src/qemu/qemu_command.c
+++ b/src/qemu/qemu_command.c
@@ -695,6 +695,7 @@ qemuBuildRBDSecinfoURI(virBufferPtr buf,
  * @tlspath: path to the TLS credentials
  * @listen: boolen listen for client or server setting
  * @verifypeer: boolean to enable peer verification (form of authorization)
+ * @secalias: if one exists, the alias of the security object for passwordid
  * @qemuCaps: capabilities
  * @propsret: json properties to return
  *
@@ -706,6 +707,7 @@ int
 qemuBuildTLSx509BackendProps(const char *tlspath,
  bool isListen,
  bool verifypeer,
+ const char *secalias,
  virQEMUCapsPtr qemuCaps,
  virJSONValuePtr *propsret)
 {
@@ -731,6 +733,10 @@ qemuBuildTLSx509BackendProps(const char *tlspath,
  NULL) < 0)
 goto cleanup;
 
+if (secalias &&
+virJSONValueObjectAdd(*propsret, "s:passwordid", secalias, NULL) < 0)
+goto cleanup;
+
 ret = 0;
 
  cleanup:
@@ -745,6 +751,7 @@ qemuBuildTLSx509BackendProps(const char *tlspath,
  * @tlspath: path to the TLS credentials
  * @listen: boolen listen for client or server setting
  * @verifypeer: boolean to enable peer verification (form of authorization)
+ * @addpasswordid: boolean to handle adding passwordid to object
  * @inalias: Alias for the parent to generate object alias
  * @qemuCaps: capabilities
  *
@@ -757,6 +764,7 @@ qemuBuildTLSx509CommandLine(virCommandPtr cmd,
 const char *tlspath,
 bool isListen,
 bool verifypeer,
+bool addpasswordid,
 const char *inalias,
 virQEMUCapsPtr qemuCaps)
 {
@@ -764,11 +772,16 @@ qemuBuildTLSx509CommandLine(virCommandPtr cmd,
 char *objalias = NULL;
 virJSONValuePtr props = NULL;
 char *tmp = NULL;
+char *secalias = NULL;
 
-if (qemuBuildTLSx509BackendProps(tlspath, isListen, verifypeer,
- qemuCaps, ) < 0)
+if (addpasswordid &&
+!(secalias = qemuDomainGetSecretAESAlias(inalias, false)))
 return -1;
 
+if (qemuBuildTLSx509BackendProps(tlspath, isListen, verifypeer, secalias,
+ qemuCaps, ) < 0)
+goto cleanup;
+
 if (!(objalias = qemuAliasTLSObjFromChardevAlias(inalias)))
 goto cleanup;
 
@@ -784,6 +797,7 @@ qemuBuildTLSx509CommandLine(virCommandPtr cmd,
 virJSONValueFree(props);
 VIR_FREE(objalias);
 VIR_FREE(tmp);
+VIR_FREE(secalias);
 return ret;
 }
 
@@ -4946,6 +4960,7 @@ qemuBuildChrChardevStr(virLogManagerPtr logManager,
 if (qemuBuildTLSx509CommandLine(cmd, cfg->chardevTLSx509certdir,
 dev->data.tcp.listen,
 cfg->chardevTLSx509verify,
+!!cfg->chardevTLSx509secretUUID,
 alias, qemuCaps) < 0)
 goto error;
 
@@ -8542,6 +8557,19 @@ qemuBuildSerialCommandLine(virLogManagerPtr logManager,
 
 /* Use -chardev with -device if they are available */
 if (virQEMUCapsSupportsChardev(def, qemuCaps, serial)) {
+qemuDomainChardevPrivatePtr chardevPriv =
+QEMU_DOMAIN_CHARDEV_PRIVATE(serial);
+qemuDomainSecretInfoPtr secinfo = chardevPriv->secinfo;
+
+/* Add the secret object first if necessary. The
+ * secinfo is added only to a TCP serial device during
+ * qemuDomainSecretChardevPrepare. Subsequent called
+ * functions can just check the config fields */
+if (cfg->chardevTLS && cfg->chardevTLSx509secretUUID &&
+   

[libvirt] [PATCH v9 5/5] qemu: Add the ability to hotplug a secret object for TCP chardev TLS

2016-10-14 Thread John Ferlan
https://bugzilla.redhat.com/show_bug.cgi?id=1300776

Complete the implementation of support for TLS encryption on
chardev TCP transports by adding the hotplug ability of a secret
to generate the passwordid for the TLS object

Likewise, add the ability to hot unplug that secret object as well

Signed-off-by: John Ferlan 
---
 src/qemu/qemu_driver.c  |  2 +-
 src/qemu/qemu_hotplug.c | 62 +
 src/qemu/qemu_hotplug.h |  3 ++-
 tests/qemuhotplugtest.c |  2 +-
 4 files changed, 61 insertions(+), 8 deletions(-)

diff --git a/src/qemu/qemu_driver.c b/src/qemu/qemu_driver.c
index 8789c9d..5a1cf7b 100644
--- a/src/qemu/qemu_driver.c
+++ b/src/qemu/qemu_driver.c
@@ -7567,7 +7567,7 @@ qemuDomainAttachDeviceLive(virDomainObjPtr vm,
 break;
 
 case VIR_DOMAIN_DEVICE_CHR:
-ret = qemuDomainAttachChrDevice(driver, vm,
+ret = qemuDomainAttachChrDevice(conn, driver, vm,
 dev->data.chr);
 if (!ret) {
 alias = dev->data.chr->info.alias;
diff --git a/src/qemu/qemu_hotplug.c b/src/qemu/qemu_hotplug.c
index aad7fa1..69d562f 100644
--- a/src/qemu/qemu_hotplug.c
+++ b/src/qemu/qemu_hotplug.c
@@ -1690,7 +1690,8 @@ qemuDomainAttachChrDeviceAssignAddr(virDomainDefPtr def,
 return ret;
 }
 
-int qemuDomainAttachChrDevice(virQEMUDriverPtr driver,
+int qemuDomainAttachChrDevice(virConnectPtr conn,
+  virQEMUDriverPtr driver,
   virDomainObjPtr vm,
   virDomainChrDefPtr chr)
 {
@@ -1704,8 +1705,11 @@ int qemuDomainAttachChrDevice(virQEMUDriverPtr driver,
 char *charAlias = NULL;
 bool chardevAttached = false;
 bool tlsobjAdded = false;
+bool secobjAdded = false;
 virJSONValuePtr tlsProps = NULL;
 char *tlsAlias = NULL;
+virJSONValuePtr secProps = NULL;
+char *secAlias = NULL;
 bool need_release = false;
 
 if (chr->deviceType == VIR_DOMAIN_CHR_DEVICE_TYPE_CHANNEL &&
@@ -1729,12 +1733,30 @@ int qemuDomainAttachChrDevice(virQEMUDriverPtr driver,
 if (qemuDomainChrPreInsert(vmdef, chr) < 0)
 goto cleanup;
 
+if (qemuDomainSecretChardevPrepare(conn, driver, priv, chr) < 0)
+goto cleanup;
+
 if (cfg->chardevTLS &&
 dev->data.tcp.haveTLS != VIR_TRISTATE_BOOL_NO) {
+qemuDomainChardevPrivatePtr chardevPriv =
+QEMU_DOMAIN_CHARDEV_PRIVATE(chr);
+qemuDomainSecretInfoPtr secinfo = chardevPriv->secinfo;
+
+/* Add a secret object in order to access the TLS environment.
+ * The secinfo will only be created for serial TCP device. */
+if (secinfo) {
+if (qemuBuildSecretInfoProps(secinfo, ) < 0)
+goto cleanup;
+
+if (!(secAlias = qemuDomainGetSecretAESAlias(chr->info.alias,
+ false)))
+goto cleanup;
+}
+
 if (qemuBuildTLSx509BackendProps(cfg->chardevTLSx509certdir,
  dev->data.tcp.listen,
  cfg->chardevTLSx509verify,
- NULL,
+ secAlias,
  priv->qemuCaps,
  ) < 0)
 goto cleanup;
@@ -1745,6 +1767,15 @@ int qemuDomainAttachChrDevice(virQEMUDriverPtr driver,
 }
 
 qemuDomainObjEnterMonitor(driver, vm);
+if (secAlias) {
+rc = qemuMonitorAddObject(priv->mon, "secret",
+  secAlias, secProps);
+secProps = NULL;
+if (rc < 0)
+goto exit_monitor;
+secobjAdded = true;
+}
+
 if (tlsAlias) {
 rc = qemuMonitorAddObject(priv->mon, "tls-creds-x509",
   tlsAlias, tlsProps);
@@ -1775,6 +1806,8 @@ int qemuDomainAttachChrDevice(virQEMUDriverPtr driver,
 qemuDomainReleaseDeviceAddress(vm, >info, NULL);
 VIR_FREE(tlsAlias);
 virJSONValueFree(tlsProps);
+VIR_FREE(secAlias);
+virJSONValueFree(secProps);
 VIR_FREE(charAlias);
 VIR_FREE(devstr);
 virObjectUnref(cfg);
@@ -1782,6 +1815,8 @@ int qemuDomainAttachChrDevice(virQEMUDriverPtr driver,
 
  exit_monitor:
 orig_err = virSaveLastError();
+if (secobjAdded)
+ignore_value(qemuMonitorDelObject(priv->mon, secAlias));
 if (tlsobjAdded)
 ignore_value(qemuMonitorDelObject(priv->mon, tlsAlias));
 /* detach associated chardev on error */
@@ -4387,6 +4422,7 @@ int qemuDomainDetachChrDevice(virQEMUDriverPtr driver,
 virDomainDefPtr vmdef = vm->def;
 virDomainChrDefPtr tmpChr;
 char *objAlias = NULL;
+char *secAlias = NULL;
 char *devstr = NULL;
 
 if (!(tmpChr = virDomainChrFind(vmdef, chr))) {
@@ -4400,9 +4436,21 @@ int qemuDomainDetachChrDevice(virQEMUDriverPtr driver,
 
 

[libvirt] [PATCH v9 0/5] Add native TLS encrypted chardev TCP support

2016-10-14 Thread John Ferlan
v8: http://www.redhat.com/archives/libvir-list/2016-October/msg00306.html

Differences to v8

1. Alter patch 1 such that it's not choosing to add the tls object based
   on both a config and domain xml setting, rather that the decision point
   is to avoid adding the config setting if the domain is set to tls='no'

2. Alter patch 2 to remove the booleans - this impacts patch 4 and 5 insomuch
   as they need to key off whether the chardevTLSx509secretUUID is set or not.

John Ferlan (5):
  domain: Add optional 'tls' attribute for TCP chardev
  conf: Introduce {default|chardev}_tls_x509_secret_uuid
  qemu: Introduce qemuDomainChardevPrivatePtr
  qemu: Add a secret object to/for a chardev tcp with secret
  qemu: Add the ability to hotplug a secret object for TCP chardev TLS

 docs/formatdomain.html.in  |  21 +++
 docs/schemas/domaincommon.rng  |   5 +
 src/conf/domain_conf.c |  51 ++--
 src/conf/domain_conf.h |   5 +-
 src/libxl/libxl_domain.c   |   2 +-
 src/lxc/lxc_native.c   |   2 +-
 src/qemu/libvirtd_qemu.aug |   2 +
 src/qemu/qemu.conf |  24 
 src/qemu/qemu_command.c|  35 -
 src/qemu/qemu_command.h|   1 +
 src/qemu/qemu_conf.c   |  14 ++
 src/qemu/qemu_conf.h   |   2 +
 src/qemu/qemu_domain.c | 143 -
 src/qemu/qemu_domain.h |  30 -
 src/qemu/qemu_driver.c |   2 +-
 src/qemu/qemu_hotplug.c|  64 -
 src/qemu/qemu_hotplug.h|   3 +-
 src/qemu/qemu_parse_command.c  |   4 +-
 src/qemu/qemu_process.c|   6 +-
 src/qemu/test_libvirtd_qemu.aug.in |   2 +
 src/vz/vz_sdk.c|   2 +-
 src/xenconfig/xen_sxpr.c   |   2 +-
 src/xenconfig/xen_xl.c |   2 +-
 tests/qemuhotplugtest.c|   2 +-
 ...uxml2argv-serial-tcp-tlsx509-chardev-notls.args |  30 +
 ...muxml2argv-serial-tcp-tlsx509-chardev-notls.xml |  50 +++
 .../qemuxml2argv-serial-tcp-tlsx509-chardev.xml|   2 +-
 ...xml2argv-serial-tcp-tlsx509-secret-chardev.args |  38 ++
 ...uxml2argv-serial-tcp-tlsx509-secret-chardev.xml |  50 +++
 tests/qemuxml2argvtest.c   |  21 +++
 ...xml2xmlout-serial-tcp-tlsx509-chardev-notls.xml |   1 +
 .../qemuxml2xmlout-serial-tcp-tlsx509-chardev.xml  |   2 +-
 tests/qemuxml2xmltest.c|   1 +
 33 files changed, 584 insertions(+), 37 deletions(-)
 create mode 100644 
tests/qemuxml2argvdata/qemuxml2argv-serial-tcp-tlsx509-chardev-notls.args
 create mode 100644 
tests/qemuxml2argvdata/qemuxml2argv-serial-tcp-tlsx509-chardev-notls.xml
 create mode 100644 
tests/qemuxml2argvdata/qemuxml2argv-serial-tcp-tlsx509-secret-chardev.args
 create mode 100644 
tests/qemuxml2argvdata/qemuxml2argv-serial-tcp-tlsx509-secret-chardev.xml
 create mode 12 
tests/qemuxml2xmloutdata/qemuxml2xmlout-serial-tcp-tlsx509-chardev-notls.xml

-- 
2.7.4

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list


[libvirt] [PATCH v4 02/25] [ACKED but has additions] qemu: replace a lot of "def->controllers[i]" with equivalent "cont"

2016-10-14 Thread Laine Stump
There's no functional change here. This pointer was just used so many
times that the extra long lines became annoying.
---

Change: added more instances of the same change.

 src/qemu/qemu_domain_address.c | 208 ++---
 1 file changed, 111 insertions(+), 97 deletions(-)

diff --git a/src/qemu/qemu_domain_address.c b/src/qemu/qemu_domain_address.c
index dc67d51..e6abadf 100644
--- a/src/qemu/qemu_domain_address.c
+++ b/src/qemu/qemu_domain_address.c
@@ -220,18 +220,22 @@ qemuDomainAssignSpaprVIOAddresses(virDomainDefPtr def,
 }
 
 for (i = 0; i < def->ncontrollers; i++) {
-model = def->controllers[i]->model;
-if (def->controllers[i]->type == VIR_DOMAIN_CONTROLLER_TYPE_SCSI) {
+virDomainControllerDefPtr cont = def->controllers[i];
+
+model = cont->model;
+if (cont->type == VIR_DOMAIN_CONTROLLER_TYPE_SCSI) {
 if (qemuDomainSetSCSIControllerModel(def, qemuCaps, ) < 0)
 goto cleanup;
 }
 
 if (model == VIR_DOMAIN_CONTROLLER_MODEL_SCSI_IBMVSCSI &&
-def->controllers[i]->type == VIR_DOMAIN_CONTROLLER_TYPE_SCSI)
-def->controllers[i]->info.type = 
VIR_DOMAIN_DEVICE_ADDRESS_TYPE_SPAPRVIO;
-if (qemuDomainAssignSpaprVIOAddress(def, >controllers[i]->info,
-VIO_ADDR_SCSI) < 0)
+cont->type == VIR_DOMAIN_CONTROLLER_TYPE_SCSI) {
+cont->info.type = VIR_DOMAIN_DEVICE_ADDRESS_TYPE_SPAPRVIO;
+}
+if (qemuDomainAssignSpaprVIOAddress(def, >info,
+VIO_ADDR_SCSI) < 0) {
 goto cleanup;
+}
 }
 
 for (i = 0; i < def->nserials; i++) {
@@ -292,13 +296,13 @@ qemuDomainPrimeVirtioDeviceAddresses(virDomainDefPtr def,
 }
 
 for (i = 0; i < def->ncontrollers; i++) {
-if ((def->controllers[i]->type ==
- VIR_DOMAIN_CONTROLLER_TYPE_VIRTIO_SERIAL ||
- def->controllers[i]->type ==
- VIR_DOMAIN_CONTROLLER_TYPE_SCSI) &&
-def->controllers[i]->info.type ==
-VIR_DOMAIN_DEVICE_ADDRESS_TYPE_NONE)
-def->controllers[i]->info.type = type;
+virDomainControllerDefPtr cont = def->controllers[i];
+
+if ((cont->type == VIR_DOMAIN_CONTROLLER_TYPE_VIRTIO_SERIAL ||
+ cont->type == VIR_DOMAIN_CONTROLLER_TYPE_SCSI) &&
+cont->info.type == VIR_DOMAIN_DEVICE_ADDRESS_TYPE_NONE) {
+cont->info.type = type;
+}
 }
 
 if (def->memballoon &&
@@ -568,9 +572,10 @@ qemuDomainPCIAddressSetCreate(virDomainDefPtr def,
 }
 
 for (i = 0; i < def->ncontrollers; i++) {
-size_t idx = def->controllers[i]->idx;
+virDomainControllerDefPtr cont = def->controllers[i];
+size_t idx = cont->idx;
 
-if (def->controllers[i]->type != VIR_DOMAIN_CONTROLLER_TYPE_PCI)
+if (cont->type != VIR_DOMAIN_CONTROLLER_TYPE_PCI)
 continue;
 
 if (idx >= addrs->nbuses) {
@@ -580,8 +585,7 @@ qemuDomainPCIAddressSetCreate(virDomainDefPtr def,
 goto error;
 }
 
-if (virDomainPCIAddressBusSetModel(>buses[idx],
-   def->controllers[i]->model) < 0)
+if (virDomainPCIAddressBusSetModel(>buses[idx], cont->model) < 
0)
 goto error;
 }
 
@@ -611,44 +615,46 @@ qemuDomainValidateDevicePCISlotsPIIX3(virDomainDefPtr def,
 
 /* Verify that first IDE and USB controllers (if any) is on the PIIX3, fn 
1 */
 for (i = 0; i < def->ncontrollers; i++) {
+virDomainControllerDefPtr cont = def->controllers[i];
+
 /* First IDE controller lives on the PIIX3 at slot=1, function=1 */
-if (def->controllers[i]->type == VIR_DOMAIN_CONTROLLER_TYPE_IDE &&
-def->controllers[i]->idx == 0) {
-if (virDeviceInfoPCIAddressPresent(>controllers[i]->info)) {
-if (def->controllers[i]->info.addr.pci.domain != 0 ||
-def->controllers[i]->info.addr.pci.bus != 0 ||
-def->controllers[i]->info.addr.pci.slot != 1 ||
-def->controllers[i]->info.addr.pci.function != 1) {
+if (cont->type == VIR_DOMAIN_CONTROLLER_TYPE_IDE &&
+cont->idx == 0) {
+if (virDeviceInfoPCIAddressPresent(>info)) {
+if (cont->info.addr.pci.domain != 0 ||
+cont->info.addr.pci.bus != 0 ||
+cont->info.addr.pci.slot != 1 ||
+cont->info.addr.pci.function != 1) {
 virReportError(VIR_ERR_INTERNAL_ERROR, "%s",
_("Primary IDE controller must have PCI 
address 0:0:1.1"));
 goto cleanup;
 }
 } else {
-def->controllers[i]->info.type = 
VIR_DOMAIN_DEVICE_ADDRESS_TYPE_PCI;
-def->controllers[i]->info.addr.pci.domain = 

[libvirt] [PATCH v4 01/25] qemu: new functions qemuDomainMachineHasPCI[e]Root()

2016-10-14 Thread Laine Stump
These functions provide a simple one line method of learning if the
current domain has a pci-root or pcie-root bus.
---

Changes: "reversed polarity" of 2nd if clause as suggested by Andrea.

 src/qemu/qemu_domain.c | 30 ++
 src/qemu/qemu_domain.h |  2 ++
 2 files changed, 32 insertions(+)

diff --git a/src/qemu/qemu_domain.c b/src/qemu/qemu_domain.c
index 0c9416f..aa54206 100644
--- a/src/qemu/qemu_domain.c
+++ b/src/qemu/qemu_domain.c
@@ -5352,6 +5352,36 @@ qemuDomainMachineIsI440FX(const virDomainDef *def)
 
 
 bool
+qemuDomainMachineHasPCIRoot(const virDomainDef *def)
+{
+int root = virDomainControllerFind(def, VIR_DOMAIN_CONTROLLER_TYPE_PCI, 0);
+
+if (root < 0)
+return false;
+
+if (def->controllers[root]->model != VIR_DOMAIN_CONTROLLER_MODEL_PCI_ROOT)
+return false;
+
+return true;
+}
+
+
+bool
+qemuDomainMachineHasPCIeRoot(const virDomainDef *def)
+{
+int root = virDomainControllerFind(def, VIR_DOMAIN_CONTROLLER_TYPE_PCI, 0);
+
+if (root < 0)
+return false;
+
+if (def->controllers[root]->model != VIR_DOMAIN_CONTROLLER_MODEL_PCIE_ROOT)
+return false;
+
+return true;
+}
+
+
+bool
 qemuDomainMachineNeedsFDC(const virDomainDef *def)
 {
 char *p = STRSKIP(def->os.machine, "pc-q35-");
diff --git a/src/qemu/qemu_domain.h b/src/qemu/qemu_domain.h
index dee5d93..8302630 100644
--- a/src/qemu/qemu_domain.h
+++ b/src/qemu/qemu_domain.h
@@ -640,6 +640,8 @@ virDomainChrDefPtr qemuFindAgentConfig(virDomainDefPtr def);
 
 bool qemuDomainMachineIsQ35(const virDomainDef *def);
 bool qemuDomainMachineIsI440FX(const virDomainDef *def);
+bool qemuDomainMachineHasPCIRoot(const virDomainDef *def);
+bool qemuDomainMachineHasPCIeRoot(const virDomainDef *def);
 bool qemuDomainMachineNeedsFDC(const virDomainDef *def);
 bool qemuDomainMachineIsS390CCW(const virDomainDef *def);
 bool qemuDomainMachineIsVirt(const virDomainDef *def);
-- 
2.7.4

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list


Re: [libvirt] [PATCH v8 2/5] conf: Introduce {default|chardev}_tls_x509_secret_uuid

2016-10-14 Thread John Ferlan


On 10/14/2016 10:53 AM, Pavel Hrdina wrote:
> On Fri, Oct 07, 2016 at 07:00:27AM -0400, John Ferlan wrote:
>> Add a new qemu.conf variables to store the UUID for the secret that could
>> be used to present credentials to access the TLS chardev.  Since this will
>> be a server level and it's possible to use some sort of default, introduce
>> both the default and chardev logic at the same time making the setting of
>> the chardev check for it's own value, then if not present checking whether
>> the default value had been set.
>>
>> The chardevTLSx509haveUUID bool will be used as the marker for whether
>> the chardevTLSx509secretUUID was successfully read. In the future this
>> is how it'd determined whether to add the secret object for a TLS object.
>>
>> Signed-off-by: John Ferlan 
>> ---
>>  src/qemu/libvirtd_qemu.aug |  2 ++
>>  src/qemu/qemu.conf | 24 
>>  src/qemu/qemu_conf.c   | 22 ++
>>  src/qemu/qemu_conf.h   |  3 +++
>>  src/qemu/test_libvirtd_qemu.aug.in |  2 ++
>>  5 files changed, 53 insertions(+)
>>
>> diff --git a/src/qemu/libvirtd_qemu.aug b/src/qemu/libvirtd_qemu.aug
>> index 988201e..73ebeda 100644
>> --- a/src/qemu/libvirtd_qemu.aug
>> +++ b/src/qemu/libvirtd_qemu.aug
>> @@ -29,6 +29,7 @@ module Libvirtd_qemu =
>> (* Config entry grouped by function - same order as example config *)
>> let default_tls_entry = str_entry "default_tls_x509_cert_dir"
>>   | bool_entry "default_tls_x509_verify"
>> + | str_entry "default_tls_x509_secret_uuid"
>>  
>> let vnc_entry = str_entry "vnc_listen"
>>   | bool_entry "vnc_auto_unix_socket"
>> @@ -51,6 +52,7 @@ module Libvirtd_qemu =
>> let chardev_entry = bool_entry "chardev_tls"
>>   | str_entry "chardev_tls_x509_cert_dir"
>>   | bool_entry "chardev_tls_x509_verify"
>> + | str_entry "chardev_tls_x509_secret_uuid"
>>  
>> let nogfx_entry = bool_entry "nographics_allow_host_audio"
>>  
>> diff --git a/src/qemu/qemu.conf b/src/qemu/qemu.conf
>> index e4c2aae..f136fa9 100644
>> --- a/src/qemu/qemu.conf
>> +++ b/src/qemu/qemu.conf
>> @@ -28,6 +28,20 @@
>>  #
>>  #default_tls_x509_verify = 1
>>  
>> +#
>> +# Libvirt assumes the server-key.pem file is unencrypted by default.
>> +# To use an encrypted server-key.pem file, the password to decrypt the
> 
> s/ the//
> 

OK

>> +# the PEM file is requird. This can be provided by creating a secret

Fixed required too..

>> +# object in libvirt and then uncommenting this setting to set the UUID

changed uncommenting to "to uncomment"

>> +# UUID of the secret.
>> +#
>> +# NB This default all-zeros UUID will not work. Replace it with the
>> +# output from the UUID for the TLS secret from a 'virsh secret-list'
>> +# command and then uncomment the entry
>> +#
>> +#default_tls_x509_secret_uuid = "----"
>> +
>> +
>>  # VNC is configured to listen on 127.0.0.1 by default.
>>  # To make it listen on all public interfaces, uncomment
>>  # this next option.
>> @@ -214,6 +228,16 @@
>>  #chardev_tls_x509_verify = 1
>>  
>>  
>> +# Uncomment and use the following option to override the default secret
>> +# uuid provided in the default_tls_x509_secret_uuid parameter.
>> +#
>> +# NB This default all-zeros UUID will not work. Replace it with the
>> +# output from the UUID for the TLS secret from a 'virsh secret-list'
>> +# command and then uncomment the entry
>> +#
>> +#chardev_tls_x509_secret_uuid = "----"
>> +
>> +
>>  # By default, if no graphical front end is configured, libvirt will disable
>>  # QEMU audio output since directly talking to alsa/pulseaudio may not work
>>  # with various security settings. If you know what you're doing, enable
>> diff --git a/src/qemu/qemu_conf.c b/src/qemu/qemu_conf.c
>> index 635fa27..c650961 100644
>> --- a/src/qemu/qemu_conf.c
>> +++ b/src/qemu/qemu_conf.c
>> @@ -365,6 +365,7 @@ static void virQEMUDriverConfigDispose(void *obj)
>>  VIR_FREE(cfg->nvramDir);
>>  
>>  VIR_FREE(cfg->defaultTLSx509certdir);
>> +VIR_FREE(cfg->defaultTLSx509secretUUID);
>>  
>>  VIR_FREE(cfg->vncTLSx509certdir);
>>  VIR_FREE(cfg->vncListen);
>> @@ -377,6 +378,7 @@ static void virQEMUDriverConfigDispose(void *obj)
>>  VIR_FREE(cfg->spiceSASLdir);
>>  
>>  VIR_FREE(cfg->chardevTLSx509certdir);
>> +VIR_FREE(cfg->chardevTLSx509secretUUID);
>>  
>>  while (cfg->nhugetlbfs) {
>>  cfg->nhugetlbfs--;
>> @@ -424,6 +426,7 @@ int virQEMUDriverConfigLoadFile(virQEMUDriverConfigPtr 
>> cfg,
>>  int ret = -1;
>>  int rv;
>>  size_t i, j;
>> +bool defaultTLSx509haveUUID;
>>  char *stdioHandler = NULL;
>>  char *user = NULL, *group = NULL;
>>  char **controllers = NULL;
>> @@ -446,6 +449,12 @@ int virQEMUDriverConfigLoadFile(virQEMUDriverConfigPtr 
>> cfg,
>>  goto 

[libvirt] [PATCH] libvirtd: systemd: add special target for system shutdown

2016-10-14 Thread Nikolay Shirokovskiy
AFAIU we don't need special actions on rpm update to switch to using
virt-guest-shutdown.target. Domains started before update will
stay depend upon libvirt-guests.service, newly started domains
will depend upon virt-guest-shutdown.target. On reboot/shutdown
systemd will order stopping both old and new domains after
libvirt-guests.service.

Nikolay Shirokovskiy (1):
  libvirtd: systemd: add special target for system shutdown

 daemon/Makefile.am| 4 
 daemon/virt-guest-shutdown.target | 3 +++
 libvirt.spec.in   | 1 +
 src/util/virsystemd.c | 4 ++--
 tools/libvirt-guests.service.in   | 2 ++
 5 files changed, 12 insertions(+), 2 deletions(-)
 create mode 100644 daemon/virt-guest-shutdown.target

-- 
1.8.3.1

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list


[libvirt] [PATCH] libvirtd: systemd: add special target for system shutdown

2016-10-14 Thread Nikolay Shirokovskiy
It is already discussed in "[RFC] daemon: remove hardcode dep on 
libvirt-guests" [1].

Mgmt can use means to save/restore domains on system shutdown/boot other then
libvirt-guests.service. Thus we need to specify appropriate ordering dependency 
between
libvirtd, domains and save/restore service. This patch takes approach suggested
in RFC and introduces a systemd target, so that ordering can be built next way:

libvirtd -> domain -> virt-guest-shutdown.target -> save-restore.service.

This way domains are decoupled from specific shutdown service via intermediate
target.

[1] https://www.redhat.com/archives/libvir-list/2016-September/msg01353.html
---
 daemon/Makefile.am| 4 
 daemon/virt-guest-shutdown.target | 3 +++
 libvirt.spec.in   | 1 +
 src/util/virsystemd.c | 4 ++--
 tools/libvirt-guests.service.in   | 2 ++
 5 files changed, 12 insertions(+), 2 deletions(-)
 create mode 100644 daemon/virt-guest-shutdown.target

diff --git a/daemon/Makefile.am b/daemon/Makefile.am
index 927d16f..463db6e 100644
--- a/daemon/Makefile.am
+++ b/daemon/Makefile.am
@@ -67,6 +67,7 @@ EXTRA_DIST =  \
libvirt.rules   \
libvirtd.sasl   \
libvirtd.service.in \
+   virt-guest-shutdown.target  \
libvirtd.sysconf\
libvirtd.sysctl \
libvirtd.aug\
@@ -456,8 +457,11 @@ install-init-systemd: install-sysconfig libvirtd.service
$(MKDIR_P) $(DESTDIR)$(SYSTEMD_UNIT_DIR)
$(INSTALL_DATA) libvirtd.service \
  $(DESTDIR)$(SYSTEMD_UNIT_DIR)/libvirtd.service
+   $(INSTALL_DATA) virt-guest-shutdown.target \
+ $(DESTDIR)$(SYSTEMD_UNIT_DIR)/virt-guest-shutdown.target
 
 uninstall-init-systemd: uninstall-sysconfig
+   rm -f $(DESTDIR)$(SYSTEMD_UNIT_DIR)/virt-guest-shutdown.target
rm -f $(DESTDIR)$(SYSTEMD_UNIT_DIR)/libvirtd.service
rmdir $(DESTDIR)$(SYSTEMD_UNIT_DIR) || :
 else ! LIBVIRT_INIT_SCRIPT_SYSTEMD
diff --git a/daemon/virt-guest-shutdown.target 
b/daemon/virt-guest-shutdown.target
new file mode 100644
index 000..bf87652
--- /dev/null
+++ b/daemon/virt-guest-shutdown.target
@@ -0,0 +1,3 @@
+[Unit]
+Description=Libvirt guests shutdown
+Documentation=http://libvirt.org
diff --git a/libvirt.spec.in b/libvirt.spec.in
index 00b95b8..82a7363 100644
--- a/libvirt.spec.in
+++ b/libvirt.spec.in
@@ -1579,6 +1579,7 @@ exit 0
 
 %if %{with_systemd}
 %{_unitdir}/libvirtd.service
+%{_unitdir}/virt-guest-shutdown.target
 %{_unitdir}/virtlogd.service
 %{_unitdir}/virtlogd.socket
 %{_unitdir}/virtlockd.service
diff --git a/src/util/virsystemd.c b/src/util/virsystemd.c
index 604dcdd..c8837f9 100644
--- a/src/util/virsystemd.c
+++ b/src/util/virsystemd.c
@@ -370,7 +370,7 @@ int virSystemdCreateMachine(const char *name,
   3,
   "Slice", "s", slicename,
   "After", "as", 1, "libvirtd.service",
-  "Before", "as", 1, "libvirt-guests.service") < 0)
+  "Before", "as", 1, "virt-guest-shutdown.target") 
< 0)
 goto cleanup;
 
 if (error.level == VIR_ERR_ERROR) {
@@ -411,7 +411,7 @@ int virSystemdCreateMachine(const char *name,
   3,
   "Slice", "s", slicename,
   "After", "as", 1, "libvirtd.service",
-  "Before", "as", 1, "libvirt-guests.service") < 0)
+  "Before", "as", 1, "virt-guest-shutdown.target") 
< 0)
 goto cleanup;
 }
 
diff --git a/tools/libvirt-guests.service.in b/tools/libvirt-guests.service.in
index b4f54f2..d0ba655 100644
--- a/tools/libvirt-guests.service.in
+++ b/tools/libvirt-guests.service.in
@@ -1,9 +1,11 @@
 [Unit]
 Description=Suspend/Resume Running libvirt Guests
 Requires=libvirtd.service
+Requires=virt-guest-shutdown.target
 After=network.target
 After=time-sync.target
 After=libvirtd.service
+After=virt-guest-shutdown.target
 Documentation=man:libvirtd(8)
 Documentation=http://libvirt.org
 
-- 
1.8.3.1

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list


[libvirt] [PATCH v2] qemu: report block job errors from qemu to the user

2016-10-14 Thread Nikolay Shirokovskiy
---
 src/qemu/qemu_blockjob.c | 13 +--
 src/qemu/qemu_blockjob.h |  3 ++-
 src/qemu/qemu_domain.c   |  1 +
 src/qemu/qemu_domain.h   |  1 +
 src/qemu/qemu_driver.c   |  4 ++--
 src/qemu/qemu_migration.c| 54 +++-
 src/qemu/qemu_monitor.c  |  5 ++--
 src/qemu/qemu_monitor.h  |  4 +++-
 src/qemu/qemu_monitor_json.c |  4 +++-
 src/qemu/qemu_process.c  |  4 
 10 files changed, 68 insertions(+), 25 deletions(-)

diff --git a/src/qemu/qemu_blockjob.c b/src/qemu/qemu_blockjob.c
index 83a5a3f..30beeeb 100644
--- a/src/qemu/qemu_blockjob.c
+++ b/src/qemu/qemu_blockjob.c
@@ -33,6 +33,7 @@
 #include "virstoragefile.h"
 #include "virthread.h"
 #include "virtime.h"
+#include "viralloc.h"
 
 #define VIR_FROM_THIS VIR_FROM_QEMU
 
@@ -53,16 +54,24 @@ VIR_LOG_INIT("qemu.qemu_blockjob");
 int
 qemuBlockJobUpdate(virQEMUDriverPtr driver,
virDomainObjPtr vm,
-   virDomainDiskDefPtr disk)
+   virDomainDiskDefPtr disk,
+   char **error)
 {
 qemuDomainDiskPrivatePtr diskPriv = QEMU_DOMAIN_DISK_PRIVATE(disk);
 int status = diskPriv->blockJobStatus;
 
+if (error)
+*error = NULL;
+
 if (status != -1) {
 qemuBlockJobEventProcess(driver, vm, disk,
  diskPriv->blockJobType,
  diskPriv->blockJobStatus);
 diskPriv->blockJobStatus = -1;
+if (error)
+VIR_STEAL_PTR(*error, diskPriv->blockJobError);
+else
+VIR_FREE(diskPriv->blockJobError);
 }
 
 return status;
@@ -241,6 +250,6 @@ qemuBlockJobSyncEnd(virQEMUDriverPtr driver,
 virDomainDiskDefPtr disk)
 {
 VIR_DEBUG("disk=%s", disk->dst);
-qemuBlockJobUpdate(driver, vm, disk);
+qemuBlockJobUpdate(driver, vm, disk, NULL);
 QEMU_DOMAIN_DISK_PRIVATE(disk)->blockJobSync = false;
 }
diff --git a/src/qemu/qemu_blockjob.h b/src/qemu/qemu_blockjob.h
index 775ce95..c452edc 100644
--- a/src/qemu/qemu_blockjob.h
+++ b/src/qemu/qemu_blockjob.h
@@ -27,7 +27,8 @@
 
 int qemuBlockJobUpdate(virQEMUDriverPtr driver,
virDomainObjPtr vm,
-   virDomainDiskDefPtr disk);
+   virDomainDiskDefPtr disk,
+   char **error);
 void qemuBlockJobEventProcess(virQEMUDriverPtr driver,
   virDomainObjPtr vm,
   virDomainDiskDefPtr disk,
diff --git a/src/qemu/qemu_domain.c b/src/qemu/qemu_domain.c
index 0c9416f..307d83a 100644
--- a/src/qemu/qemu_domain.c
+++ b/src/qemu/qemu_domain.c
@@ -774,6 +774,7 @@ qemuDomainDiskPrivateDispose(void *obj)
 
 qemuDomainSecretInfoFree(>secinfo);
 qemuDomainSecretInfoFree(>encinfo);
+VIR_FREE(priv->blockJobError);
 }
 
 
diff --git a/src/qemu/qemu_domain.h b/src/qemu/qemu_domain.h
index dee5d93..c470cbf 100644
--- a/src/qemu/qemu_domain.h
+++ b/src/qemu/qemu_domain.h
@@ -290,6 +290,7 @@ struct _qemuDomainDiskPrivate {
 /* for some synchronous block jobs, we need to notify the owner */
 int blockJobType;   /* type of the block job from the event */
 int blockJobStatus; /* status of the finished block job */
+char *blockJobError; /* block job completed event error */
 bool blockJobSync; /* the block job needs synchronized termination */
 
 bool migrating; /* the disk is being migrated */
diff --git a/src/qemu/qemu_driver.c b/src/qemu/qemu_driver.c
index 8789c9d..bc7f840 100644
--- a/src/qemu/qemu_driver.c
+++ b/src/qemu/qemu_driver.c
@@ -16326,13 +16326,13 @@ qemuDomainBlockJobAbort(virDomainPtr dom,
  VIR_DOMAIN_BLOCK_JOB_CANCELED);
 } else {
 qemuDomainDiskPrivatePtr diskPriv = QEMU_DOMAIN_DISK_PRIVATE(disk);
-qemuBlockJobUpdate(driver, vm, disk);
+qemuBlockJobUpdate(driver, vm, disk, NULL);
 while (diskPriv->blockjob) {
 if (virDomainObjWait(vm) < 0) {
 ret = -1;
 goto endjob;
 }
-qemuBlockJobUpdate(driver, vm, disk);
+qemuBlockJobUpdate(driver, vm, disk, NULL);
 }
 }
 }
diff --git a/src/qemu/qemu_migration.c b/src/qemu/qemu_migration.c
index 1c4a80c..1762648 100644
--- a/src/qemu/qemu_migration.c
+++ b/src/qemu/qemu_migration.c
@@ -1859,17 +1859,25 @@ qemuMigrationDriveMirrorReady(virQEMUDriverPtr driver,
 for (i = 0; i < vm->def->ndisks; i++) {
 virDomainDiskDefPtr disk = vm->def->disks[i];
 qemuDomainDiskPrivatePtr diskPriv = QEMU_DOMAIN_DISK_PRIVATE(disk);
+char *error;
 
 if (!diskPriv->migrating)
 continue;
 
-status = qemuBlockJobUpdate(driver, vm, disk);
+status = qemuBlockJobUpdate(driver, vm, disk, );
 if (status == VIR_DOMAIN_BLOCK_JOB_FAILED) {
-

[libvirt] [PATCH v2] qemu: report block job errors from qemu to the user

2016-10-14 Thread Nikolay Shirokovskiy
So that you can see nice report on migration:

"error: operation failed: migration of disk sda failed: No space left on device"

diff from v1:
1. drop 1 patch. Avoiding default label in switches is desired style.
2. drop 2 patch. I do not investigate enough to touch that place.
3. fix 3 patch 
  a) as suggested by Jiri
* fix leaks
* s/hint/error/g
* don't show  in error message
* take suggested code simplifications
  b) extra
* print error string from qemu to log in case we have to drop it

Nikolay Shirokovskiy (1):
  qemu: report block job errors from qemu to the user

 src/qemu/qemu_blockjob.c | 13 +--
 src/qemu/qemu_blockjob.h |  3 ++-
 src/qemu/qemu_domain.c   |  1 +
 src/qemu/qemu_domain.h   |  1 +
 src/qemu/qemu_driver.c   |  4 ++--
 src/qemu/qemu_migration.c| 54 +++-
 src/qemu/qemu_monitor.c  |  5 ++--
 src/qemu/qemu_monitor.h  |  4 +++-
 src/qemu/qemu_monitor_json.c |  4 +++-
 src/qemu/qemu_process.c  |  4 
 10 files changed, 68 insertions(+), 25 deletions(-)

-- 
1.8.3.1

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list


[libvirt] [PATCH] qemu_driver: unlink new domain cfg file when rollbak

2016-10-14 Thread Chen Hanxiao
From: Chen Hanxiao 

If we failed to unlink old dom cfg file, we goto rollback.
But inside rollback, we fogot to unlink the new dom cfg file.
This patch fixes this issue.

Signed-off-by: Chen Hanxiao 
---
 src/qemu/qemu_driver.c | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/src/qemu/qemu_driver.c b/src/qemu/qemu_driver.c
index e6f845d..3f4a2fb 100644
--- a/src/qemu/qemu_driver.c
+++ b/src/qemu/qemu_driver.c
@@ -19869,6 +19869,7 @@ qemuDomainRenameCallback(virDomainObjPtr vm,
 char *new_dom_name = NULL;
 char *old_dom_name = NULL;
 char *old_dom_cfg_file = NULL;
+char *new_dom_cfg_file = NULL;
 
 virCheckFlags(0, ret);
 
@@ -19882,6 +19883,11 @@ qemuDomainRenameCallback(virDomainObjPtr vm,
 goto cleanup;
 }
 
+if (!(new_dom_cfg_file = virDomainConfigFile(cfg->configDir,
+ new_dom_name))) {
+goto cleanup;
+}
+
 event_old = virDomainEventLifecycleNewFromObj(vm,
 VIR_DOMAIN_EVENT_UNDEFINED,
 
VIR_DOMAIN_EVENT_UNDEFINED_RENAMED);
@@ -19909,6 +19915,7 @@ qemuDomainRenameCallback(virDomainObjPtr vm,
 
  cleanup:
 VIR_FREE(old_dom_cfg_file);
+VIR_FREE(new_dom_cfg_file);
 VIR_FREE(old_dom_name);
 VIR_FREE(new_dom_name);
 qemuDomainEventQueue(driver, event_old);
@@ -19922,6 +19929,10 @@ qemuDomainRenameCallback(virDomainObjPtr vm,
 vm->def->name = old_dom_name;
 old_dom_name = NULL;
 }
+
+if (virFileExists(new_dom_cfg_file))
+unlink(new_dom_cfg_file);
+
 goto cleanup;
 }
 
-- 
1.8.3.1


--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list


Re: [libvirt] [PATCH 1/1] qemu: host NUMA hugepage policy without guest NUMA

2016-10-14 Thread Martin Kletzander

On Fri, Oct 14, 2016 at 11:52:22AM +1100, Sam Bobroff wrote:

On Thu, Oct 13, 2016 at 11:34:43AM +0200, Martin Kletzander wrote:

On Thu, Oct 13, 2016 at 11:34:16AM +1100, Sam Bobroff wrote:
>On Wed, Oct 12, 2016 at 10:27:50AM +0200, Martin Kletzander wrote:
>>On Wed, Oct 12, 2016 at 03:04:53PM +1100, Sam Bobroff wrote:
>>>At the moment, guests that are backed by hugepages in the host are
>>>only able to use policy to control the placement of those hugepages
>>>on a per-(guest-)CPU basis. Policy applied globally is ignored.
>>>
>>>Such guests would use  and
>>>a  block with  but no >>.../> elements.
>>>
>>>This patch corrects this by, in this specific case, changing the QEMU
>>>command line from "-mem-prealloc -mem-path=..." (which cannot
>>>specify NUMA policy) to "-object memory-backend-file ..." (which can).
>>>
>>>Note: This is not visible to the guest and does not appear to create
>>>a migration incompatibility.
>>>
>>
>>It could make sense, I haven't tried yet, though.  However, I still
>>don't see the point in using memory-backend-file.  Is it that when you
>>don't have cpuset cgroup the allocation doesn't work well?  Because it
>>certainly does work for me.
>
>Thanks for taking a look at this :-)
>
>The point of using a memory-backend-file is that with it, the NUMA policy can
>be specified to QEMU, but with -mem-path it can't. It seems to be a way to tell
>QEMU to apply NUMA policy in the right place. It does seem odd to me to use
>memory-backend-file without attaching the backend to a guest NUMA node, but it
>seems to do the right thing in this case. (If there are guest NUMA nodes, or if
>hugepages aren't being used, policy is correctly applied.)
>
>I'll describe my test case in detail, perhaps there's something I don't 
understand
>happening.
>
>* I set up a machine with two (fake) NUMA nodes (0 and 1), with 2G of hugepages
> on node 1, and none on node 0.
>
>* I create a 2G guest using virt-install:
>
>virt-install --name ppc --memory=2048 --disk ~/tmp/tmp.qcow2 --cdrom 
~/tmp/ubuntu-16.04-server-ppc64el.iso --wait 0 --virt-type qemu --memorybacking 
hugepages=on --graphics vnc --arch ppc64le
>
>* I "virsh destroy" and then "virsh edit" to add this block to the guest XML:
>
> 
>
> 
>
>* "virsh start", and the machine starts (I believe it should fail due to 
insufficient memory satasfying the policy).
>* "numastat -p $(pidof qemu-system-ppc64)" shows something like this:
>
>Per-node process memory usage (in MBs) for PID 8048 (qemu-system-ppc)
>  Node 0  Node 1   Total
> --- --- ---
>Huge 0.00 2048.00 2048.00
>Heap 8.120.008.12
>Stack0.030.000.03
>Private 35.806.10   41.90
>  --- --- ---
>Total   43.95 2054.10 2098.05
>
>So it looks like it's allocated hugepages from node 1, isn't this violating the
>policy I set via numatune?
>

Oh, now I get it.  We are doing our best to apply that policy to qemu
even when we don't have this option.  However, using this works even
better (which is probably* what we want).  And that's the reasoning
behind this.

* I'm saying probably because when I was adding numactl binding to be
  used together with cgroups, I was told that we couldn't change the
  binding afterwards and it's bad.  I feel like we could do something
  with that and it would help us in the future, but there needs to be a
  discussion, I guess.  Because I might be one of the few =)

So to recapitulate that, there are three options how to affect the
allocation of qemu's memory:

1) numactl (libnuma): it works as expected, but cannot be changed later

2) cgroups: so strict it has to be applied after qemu started, due to
   that it doesn't work right, especially for stuff that gets all
   pre-allocated (like hugepages).  it can be changed later, but it
   won't always mean the memory will migrate, so upon change there is
   no guarantee.  If it's unavailable, we fallback to (1) anyway

3) memory-backing-file's host-nodes=: this works as expected, but
   cannot be used with older QEMUs, cannot be changed later and in some
   cases (not your particular one) it might screw up migration if it
   wasn't used before.

Selecting the best option from these, plus making the code work with
every possibility (erroring out when you want to change the memory node
and we had to use (1) for example) is a pain.  We should really think
about that and reorganize these things for the better of the future.
Otherwise we're going to get overwhelm ourselves.  Cc'ing Peter to get
his thoughts as well as he worked on some parts of this as well.

Martin


Thanks for the explanation, and I agree (I'm already a bit overwhelmed!) :-)

What do you mean by "changed later"? Do 

Re: [libvirt] [PATCH v3 19/18] [RFC] qemu: assure there are always at least 4 open pcie-root-ports for hotplug

2016-10-14 Thread Andrea Bolognani
On Thu, 2016-09-29 at 15:20 -0400, Laine Stump wrote:
> For machinetypes with a pci-root bus (all legacy PCI), libvirt will
> make a "fake" reservation for one extra slot prior to assigning
> addresses to unaddressed PCI endpoint devices in the domain. This will
> trigger auto-adding of a pci-bridge for the final device to be
> assigned an address *if that device would have otherwise instead been
> the last device on the last available pci-bridge*; thus it assures
> that there will always be at least one slot left open in the domains
> bus topology for expansion (which is important both for hotplug (since
> a new pci-bridge can't be added while the guest is running) as well as
> for coldplug (since adding a new device might otherwise in some cases
> require re-addressing existing devices, which we want to avoid)).
> 
> It's important to note that for this (legacy PCI) case, we must check
> for the special case of all slots on all buses being occupied *prior
> to assigning any addresses*, and avoid attempting to reserve the extra
> address in that case, because there is no free address in the existing
> topology, so no place to auto-add a pci-bridge for expansion. Since
> that condition can only be reached by manual intervention, this is
> acceptable.
> 
> For machinetypes with pcie-root, libvirt's methodology for
> automatically expanding the bus topology is different -
> pcie-root-ports are plugged into slots (soon to be functions) of
> pcie-root as needed, and the new endpoint devices are assigned to the
> single slot in each pcie-root-port. This is done so that the devices
> are, by default, hotpluggable (the slots of pcie-root don't support
> hotplug, but the single slot of the pcie-root-port does). Since
> pcie-root-ports can only be plugged into pcie-root, and we don't
> auto-assign endpoint devices to those slots, this means topology
> expansion doesn't compete with endpoint devices for slots, so we don't
> need to worry about checking for all "useful" slots being free prior
> to assigning addresses to new endpoint devices - as a matter of fact,
> if we attempt to reserve the fake slots before the useful slots, it
> can lead to errors.
> 
> Instead this patch just reserves slots for "fake" devices after doing
> the assignment for actual devices - if there were already enough
> unoccupied pcie-root-ports, then none will be added; if not, then
> enough will be added to support the desired (hardcoded) potential
> number of hotplugged devices.
> 
> Since there hasn't been any other concrete suggestion for the number
> of "available hotpluggable slots" libvirt should assure, this patch
> uses "4" as the answer (thanks Drew!) Alternatives could be:
> 
> 0 - hotplug would only work if the user had thought to add an extra
> pcie-root to the config *as an extra step after adding and saving each
> new device*. (this would preclude creating a new domain that had a
> pcie-root-port available for hotplug - the extra modify/save step
> would be needed even during initial domain creation, and would need to
> be repeated every time a device was added to the domain)
> 
> 1 - this is the *minimum* number of hotpluggable slots libvirt
> guarantees for legacy PCI domains (with pci-root). Of course on
> average these domains are more likely to have *15* slots available
> (half of the slots on a pci-bridge).
> 
> "anything else" - really any choice made for this is going to be
> considered wrong by *somebody*. I hope we can all agree that "0" is a
> wrong choice, just because it will require so much ongoing
> babysitting.
> 
> A couple of us have brought up the idea of having
> "availableHotplugSlots" be configurable in the domain. There has also
> been sentiment against that. Perhaps it could be configurable in
> qemu.conf? (I don't really like that either, though - I think
> everything about the domain should be self-contained in the domain
> XML, and if something is tunable, it should be tunable separately for
> each domain).
> 
> In the absense of anything configurable, we will need to pick a number
> though. I've done that here, and now we can argue about it (or not :-)

As we have already agreed on a slightly different approach,x
eg. doing pretty much exactly this, but only if the
configuration provided by the user contains no PCI controller
(except possibly for pcie-root), I think it's fair to say:

NACK

-- 
Andrea Bolognani / Red Hat / Virtualization

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [PATCH v8 1/5] domain: Add optional 'tls' attribute for TCP chardev

2016-10-14 Thread John Ferlan


On 10/14/2016 09:18 AM, Pavel Hrdina wrote:
> On Fri, Oct 07, 2016 at 07:00:26AM -0400, John Ferlan wrote:
>> Add an optional "tls='yes'" option for a TCP chardev for the
>> express purpose to enable setting up TLS for the chardev. This
>> will assume that the qemu.conf settings have been adjusted as
>> well as the environment configured properly.
>>
>> Signed-off-by: John Ferlan 
>> ---
>>  docs/formatdomain.html.in  | 21 +
>>  docs/schemas/domaincommon.rng  |  5 +++
>>  src/conf/domain_conf.c | 22 +-
>>  src/conf/domain_conf.h |  1 +
>>  src/qemu/qemu_command.c|  3 +-
>>  src/qemu/qemu_hotplug.c|  3 +-
>>  ...emuxml2argv-serial-tcp-tlsx509-chardev-tls.args | 30 +
>>  ...qemuxml2argv-serial-tcp-tlsx509-chardev-tls.xml | 50 
>> ++
>>  .../qemuxml2argv-serial-tcp-tlsx509-chardev.xml|  2 +-
>>  tests/qemuxml2argvtest.c   |  3 ++
>>  ...muxml2xmlout-serial-tcp-tlsx509-chardev-tls.xml |  1 +
>>  .../qemuxml2xmlout-serial-tcp-tlsx509-chardev.xml  |  2 +-
>>  tests/qemuxml2xmltest.c|  1 +
>>  13 files changed, 139 insertions(+), 5 deletions(-)
>>  create mode 100644 
>> tests/qemuxml2argvdata/qemuxml2argv-serial-tcp-tlsx509-chardev-tls.args
>>  create mode 100644 
>> tests/qemuxml2argvdata/qemuxml2argv-serial-tcp-tlsx509-chardev-tls.xml
>>  create mode 12 
>> tests/qemuxml2xmloutdata/qemuxml2xmlout-serial-tcp-tlsx509-chardev-tls.xml
>>
>> diff --git a/docs/formatdomain.html.in b/docs/formatdomain.html.in
>> index 1266e9d..010530e 100644
>> --- a/docs/formatdomain.html.in
>> +++ b/docs/formatdomain.html.in
>> @@ -6203,6 +6203,27 @@ qemu-kvm -net nic,model=? /dev/null
>>/devices
>>...
>>  
>> +
>> +  Since 2.4.0, some hypervisors support using
>> +  a TLS X.509 certificate environment in order to encrypt all serial TCP
>> +  connections via a hypervisor configuration option. In order to enable
>> +  TLS for the domain an optional attribute tls can be set 
>> to
>> +  "yes". Combined with the hypervisor's capability to utilize the TLS
>> +  environment allows for the character device to use the encrypted
>> +  communication. If the attribute is not present, then the default
>> +  setting is "no".
> 
> This is not correct in case of QEMU.  Before this patch the default was based 
> on
> chardev_tls from qemu.conf.  After this patch the default will be "no" even if
> you set chardev_tls=1 and that breaks behavior of libvirt.  The test case
> "serial-tcp-tlsx509-chardev-tls" where you had to add tls="yes" should also 
> work
> without this change.
> 
> This patch needs to be modified to take chardev_tls=1 in account and add tests
> to make sure that we don't break it in the future.
> 

This change was in response to v5 (and v6) review comments from Daniel :

v5: http://www.redhat.com/archives/libvir-list/2016-September/msg00294.html

v6: http://www.redhat.com/archives/libvir-list/2016-September/msg00317.html

I read those review requests as we need a way to be able to disable TLS
on a chardev on a domain by domain and even chardev by chardev basis
rather than it being the default enabled for every domain and every
chardev in the domain.

Could you elaborate how it breaks the behavior of libvirt?  Currently a
chardev doesn't have any TLS attribute - that qemu.conf change is from
already agreed upon changes. This set of changes should have been able
to go with those, but they've languished on the least through a release
cycle (2.3.0), so while it may appear that something is one way - it in
a way isn't.  Right now it's just pixie/fairy dust and a pipe dream.


John

> Pavel
> 
>> +
>> +
>> +  ...
>> +  devices
>> +serial type="tcp"
>> +  source mode='connect' host="127.0.0.1" service="" 
>> tls="yes"/
>> +  protocol type="raw"/
>> +  target port="0"/
>> +/serial
>> +  /devices
>> +  ...
>> +
>>  UDP network console
>>  
>>  
>> diff --git a/docs/schemas/domaincommon.rng b/docs/schemas/domaincommon.rng
>> index 6eeb4e9..362b90d 100644
>> --- a/docs/schemas/domaincommon.rng
>> +++ b/docs/schemas/domaincommon.rng
>> @@ -3453,6 +3453,11 @@
>>  
>>
>>  
>> +
>> +  
>> +
>> +  
>> +
>>  
>>
>>  
>> diff --git a/src/conf/domain_conf.c b/src/conf/domain_conf.c
>> index f562323..1f7c43f 100644
>> --- a/src/conf/domain_conf.c
>> +++ b/src/conf/domain_conf.c
>> @@ -1961,6 +1961,8 @@ virDomainChrSourceDefCopy(virDomainChrSourceDefPtr 
>> dest,
>>  
>>  if (VIR_STRDUP(dest->data.tcp.service, src->data.tcp.service) < 0)
>>  return -1;
>> +
>> +dest->data.tcp.haveTLS = src->data.tcp.haveTLS;
>>  break;
>>  
>>  case 

Re: [libvirt] [PATCH 7/8] qemu: Support newer ivshmem device variants

2016-10-14 Thread Martin Kletzander

On Fri, Oct 07, 2016 at 12:20:19PM -0400, John Ferlan wrote:



On 09/27/2016 08:24 AM, Martin Kletzander wrote:

QEMU added support for ivshmem-plain and ivshmem-doorbell.  Those are
reworked varians of legacy ivshmem that are compatible from the guest
POV, but not from host's POV and have sane specification and handling.



It seems less "added support for" and more "forced libvirt to choose"
between one or the other as of qemu v2.6.



Well, not really, it's not removed from newer QEMU, it's just deprecated.


Details about the newer device type can be found in qemu's commit
5400c02b90bb:

  http://git.qemu.org/?p=qemu.git;a=commit;h=5400c02b90bb

Signed-off-by: Martin Kletzander 
---
 src/qemu/qemu_command.c| 88 +-
 src/qemu/qemu_command.h| 10 +++
 .../qemuxml2argv-shmem-plain-doorbell.args | 43 +++
 .../qemuxml2argv-shmem-plain-doorbell.xml  | 63 
 tests/qemuxml2argvtest.c   |  3 +
 5 files changed, 204 insertions(+), 3 deletions(-)
 create mode 100644 
tests/qemuxml2argvdata/qemuxml2argv-shmem-plain-doorbell.args
 create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-shmem-plain-doorbell.xml

diff --git a/src/qemu/qemu_command.c b/src/qemu/qemu_command.c
index aa8cff80e8b1..29f7130ef911 100644
--- a/src/qemu/qemu_command.c
+++ b/src/qemu/qemu_command.c
@@ -8456,6 +8456,39 @@ qemuBuildShmemDevLegacyStr(virDomainDefPtr def,
 return NULL;
 }

+char *
+qemuBuildShmemDevStr(virDomainDefPtr def,
+ virDomainShmemDefPtr shmem,
+ virQEMUCapsPtr qemuCaps)
+{
+virBuffer buf = VIR_BUFFER_INITIALIZER;
+
+virBufferAsprintf(, "%s", 
virDomainShmemModelTypeToString(shmem->model));
+virBufferAsprintf(, ",id=%s", shmem->info.alias);
+
+if (shmem->server.enabled)
+virBufferAsprintf(, ",chardev=char%s", shmem->info.alias);
+else
+virBufferAsprintf(, ",memdev=shmmem-%s", shmem->info.alias);
+
+if (shmem->msi.vectors)
+virBufferAsprintf(, ",vectors=%u", shmem->msi.vectors);
+if (shmem->msi.ioeventfd) {
+virBufferAsprintf(, ",ioeventfd=%s",
+  virTristateSwitchTypeToString(shmem->msi.ioeventfd));
+}
+
+if (qemuBuildDeviceAddressStr(, def, >info, qemuCaps) < 0) {
+virBufferFreeAndReset();
+return NULL;
+}
+
+if (virBufferCheckError() < 0)


Still would need to FreeAndReset - I'd be OK if it were an || to the
previous if, although I know that causes agita for others.



Well, not really.  The content gets free()'d whenever the buf->error is
set, so it is already cleared if there was an error.


I suppose you could to the error: label path/option too.


+return NULL;
+
+return virBufferContentAndReset();
+}
+
 static char *
 qemuBuildShmemBackendChrStr(virLogManagerPtr logManager,
 virCommandPtr cmd,
@@ -8476,6 +8509,50 @@ qemuBuildShmemBackendChrStr(virLogManagerPtr logManager,
 return devstr;
 }

+
+virJSONValuePtr
+qemuBuildShmemBackendMemProps(virDomainShmemDefPtr shmem)
+{
+char *mem_path = NULL;
+virJSONValuePtr ret = NULL;
+
+if (virAsprintf(_path, "/dev/shm/%s", shmem->name) < 0)
+return NULL;
+
+virJSONValueObjectCreate(,
+ "s:mem-path", mem_path,
+ "U:size", shmem->size,
+ NULL);


Hmm... perhaps not so much of an issue as previously thought... This
will only be called for the -plain anyway and well shmem->size had
better not be zero (since you're using "U:")..

So still leaves me wondering if we should fail if a size is provided for
-doorbell



OK, I added that.


+
+VIR_FREE(mem_path);
+return ret;
+}
+
+
+static char *
+qemuBuildShmemBackendMemStr(virDomainShmemDefPtr shmem)
+{
+char *ret = NULL;
+char *alias = NULL;
+virJSONValuePtr props = qemuBuildShmemBackendMemProps(shmem);
+
+if (!props)
+return NULL;
+
+if (virAsprintf(, "shmmem-%s", shmem->info.alias) < 0)
+goto cleanup;
+
+ret = virQEMUBuildObjectCommandlineFromJSON("memory-backend-file",
+alias,
+props);
+ cleanup:
+VIR_FREE(alias);
+virJSONValueFree(props);
+
+return ret;
+}
+
+
 static int
 qemuBuildShmemCommandLine(virLogManagerPtr logManager,
   virCommandPtr cmd,
@@ -8518,10 +8595,15 @@ qemuBuildShmemCommandLine(virLogManagerPtr logManager,
 break;



Should there be caps checks for :

QEMU_CAPS_DEVICE_IVSHMEM_PLAIN
QEMU_CAPS_DEVICE_IVSHMEM_DOORBELL



Sure, I should've added that, good point.


You added the caps in the xml2argvtest, so I'd expect them...  Obviously
they wouldn't work on qemu 2.5 or earlier.

As long as the memory leak is handled and there's an answer for the caps
checks, this 

Re: [libvirt] [PATCH v3] Fixes virsh save-restore/migration when memory detach not in LIFO

2016-10-14 Thread John Ferlan


On 10/04/2016 09:06 AM, Nitesh Konkar wrote:
> Currently the migration stream references the memory
> blocks by name (which is supplied by libvirt) rather
> than by there order. With the current code that is
> assigning aliases for memory backend objects this
> won't happen and since qemu is treating the memory
> object links differently migration does not work in
> such case.
> 
> This patch ensures slot number alocation for the memory

allocation

> modules beforehand and assign alias accordingly. This
> keeps slot numbers consistent with the aliases always.
> 
> Signed-off-by: Nitesh Konkar 
> ---
>  src/conf/domain_conf.h  |  1 +
>  src/qemu/qemu_alias.c   | 36 +---
>  src/qemu/qemu_alias.h   |  6 --
>  src/qemu/qemu_domain.c  |  3 +++
>  src/qemu/qemu_hotplug.c |  5 -
>  5 files changed, 37 insertions(+), 14 deletions(-)
> 

I believe Peter's review of your v2 mentioned a few other things... In
particular test cases... but also a subtle point about partial manual
assignment of slots by a user which I'm not sure you covered in the new
AssignSlot method below.

I'll make note of a few things below...

> diff --git a/src/conf/domain_conf.h b/src/conf/domain_conf.h
> index fd3ae8e..22b5fe1 100644
> --- a/src/conf/domain_conf.h
> +++ b/src/conf/domain_conf.h
> @@ -2145,6 +2145,7 @@ struct _virDomainDef {
>  
>  virDomainBlkiotune blkio;
>  virDomainMemtune mem;
> +virBitmapPtr memslotsptr;

This wouldn't belong here - it would belong in _qemuDomainObjPrivate.
You're not saving this data the user visible XML and this is not
something generic, rather it's qemu specific.

I think it would need to be saved in the "running" XML so that future
restart/reloads of running domains would have it.

You'll see that the structure already has a couple of virBitmapPtr
fields which you could use as a "model" to find all the places you'd
need to touch (and the history of how they got into private).

>  
>  virDomainVcpuDefPtr *vcpus;
>  size_t maxvcpus;
> diff --git a/src/qemu/qemu_alias.c b/src/qemu/qemu_alias.c
> index cc83fec..8deb054 100644
> --- a/src/qemu/qemu_alias.c
> +++ b/src/qemu/qemu_alias.c
> @@ -332,21 +332,34 @@ qemuAssignDeviceRNGAlias(virDomainDefPtr def,
>  }
>  
>  
> -int
> -qemuAssignDeviceMemoryAlias(virDomainDefPtr def,
> -virDomainMemoryDefPtr mem)
> +void
> +qemuAssignDeviceMemorySlot(virDomainDefPtr def,
> +   virDomainMemoryDefPtr mem)

This should not go in qemu_alias.c - it seems to belong in qemu_domain
and thus would be appropriately named such as:

qemuDomainDeviceAssignMemorySlot (or something that starts with
qemuDomain - I'm not the "best" at creating names).


>  {
>  size_t i;
> -int maxidx = 0;
> -int idx;
> +int minidx = 0;
>  
> -for (i = 0; i < def->nmems; i++) {
> -if ((idx = qemuDomainDeviceAliasIndex(>mems[i]->info, "dimm")) 
> >= maxidx)
> -maxidx = idx + 1;
> +if (mem->info.addr.dimm.base) {
> +minidx = mem->info.addr.dimm.slot;
> +} else {
> +for (i = 0; i < def->mem.memory_slots; i++) {
> +if (!virBitmapIsBitSet(def->memslotsptr, i)) {
> +minidx = i;
> +break;
> +}
> +}

Are you looking for something like virBitmapNextClearBit?

>  }
>  
> -if (virAsprintf(>info.alias, "dimm%d", maxidx) < 0)
> -return -1;
> +ignore_value(virBitmapSetBit(def->memslotsptr, minidx));
> +mem->info.addr.dimm.slot = minidx;
> +}
> +
> +
> +int
> +qemuAssignDeviceMemoryAlias(virDomainMemoryDefPtr mem)
> +{

Right here you'll want to call your method to assign the slot...  Since
the two places where slot assignment is done (qemuAssignDeviceAliases
and qemuDomainAttachMemory) have that call first...

> +if (virAsprintf(>info.alias, "dimm%d", mem->info.addr.dimm.slot) < 
> 0)
> + return -1;
>  
>  return 0;

FWIW:
If this only had the virAsprintf, it could have just simply been:

return virAsprintf(...);

>  }
> @@ -475,7 +488,8 @@ qemuAssignDeviceAliases(virDomainDefPtr def, 
> virQEMUCapsPtr qemuCaps)
>  return -1;
>  }
>  for (i = 0; i < def->nmems; i++) {
> -if (virAsprintf(>mems[i]->info.alias, "dimm%zu", i) < 0)
> +qemuAssignDeviceMemorySlot(def, def->mems[i]);
> +if (virAsprintf(>mems[i]->info.alias, "dimm%d", 
> def->mems[i]->info.addr.dimm.slot) < 0)

Similar to [1] below, when these two things are "paired up" - that says
to me the qemuAssignDeviceAliases should be handling that memory slot

Not doing the virAsprintf here allows one common place to generate the
alias...

>  return -1;
>  }
>  
> diff --git a/src/qemu/qemu_alias.h b/src/qemu/qemu_alias.h
> index 11d9fde..c6cb568 100644
> --- a/src/qemu/qemu_alias.h
> +++ b/src/qemu/qemu_alias.h
> @@ -57,8 +57,10 @@ int qemuAssignDeviceRedirdevAlias(virDomainDefPtr def,
>  int 

Re: [libvirt] [PATCH rfc v2 0/8] fspool: backend directory

2016-10-14 Thread John Ferlan
[...]

>>
>> I have written this lines as a part of  GPLv2+ boilerplate:
>> https://www.redhat.com/archives/libvir-list/2016-August/msg01160.html,
>> which I took from
>> other libvirt parts. And I guess it was naturally to change name and
>> company, don't you?
>> And again, if you insist I can leave out the author/copyright as it
>> wasn't the aim of this series.
> 
> Indeed, storage pool is very similar to FS pool but their items are not
> - volumes (block devices)
> versus filesystems (directory trees). And intention here was to
> introduce a *new API*, which is
> also very different from storage pool one, effectivly introducing a new
> driver. As driver
> boundaries crossing isn't favored, the code was simply borrowed,
> following earlier practice used
> by libvirt to get new drivers implemented.
> 
> John, keeping all said above in mind, do you think it's worth trying to
> reuse common code while
> introducing a new API? It won't allow us to leave existing code
> untouched and it will increase the
> series even more.
>  

Sorry - just haven't been able to keep up with my work and all the
activity on this list lately.

Here's my point - if you find yourself copying a function from one
driver to another for the express purpose that you cannot cross driver
boundaries, then perhaps your first thought should be - can the copied
code can go in an existing or a new src/util/vir*.c file and be used in
both places. I think there are synergies in the existing code...

Another thought that occurs to me - I cannot recall if it's been
mentioned in this context or not (short term memory isn't what it used
to be!). IIUC the model is to use these trees more for containers, then
I would hope the security is "built in" very tightly rather than being
an added on after thought. One particularly thorny area is NFS storage
pools (and well directory trees) especially w/r/t root_squash or not. In
any case, I can only imagine that for container consumers - being "held"
to certain security rules will be very important.

One final thought, if the existing 'storage driver' is for BLOCK storage
and this new driver is a 'File System Storage Driver', then rather than
using 'fspool' (which is really confusing IMO) maybe the base driver is
"fs_storage". So that means we create a "src/fs_storage" and start from
there.  The 'fs' was just not descriptive enough.

Since it's a File System Storage Driver that's essentially exposing
entire directories, is there really a need for a "pool" concept? Isn't
the driver providing that alone? IOW: The implementation is a pool.
What else other than a directory would something like this expose? Is
there something else that could be envisioned that would add to the
(from patch 1) virFSItemType?

John

Oh and please let's not drop 12K lines of new code into one series -
please!  Rome wasn't built in a day and certainly it's very hard to
commit the time to review 12K lines of code in one series. A logical
progression to the finish line is fine.


[...]

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list


Re: [libvirt] [PATCH v3 19/18] [RFC] qemu: assure there are always at least 4 open pcie-root-ports for hotplug

2016-10-14 Thread Laine Stump

On 10/14/2016 09:13 AM, Andrea Bolognani wrote:

On Thu, 2016-09-29 at 15:20 -0400, Laine Stump wrote:

In the absense of anything configurable, we will need to pick a number
though. I've done that here, and now we can argue about it (or not :-)

Ján raised an interesting point: whatever number we choose,
no matter how wrong doing so is, some user or application
will end up relying on us providing at least that many
hotpluggable ports, so there's no going back.

For that reason, I would recommend leaving just a single
empty hotpluggable port for now, and raise the number in
the future if we find out that one's definitely not enough.


That makes sense. I've already updated the patch per our conversation in 
the other thread, but will update it further to reflect this idea as well.


--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [PATCH v8 1/5] domain: Add optional 'tls' attribute for TCP chardev

2016-10-14 Thread Pavel Hrdina
On Fri, Oct 14, 2016 at 09:32:45AM -0400, John Ferlan wrote:
> 
> 
> On 10/14/2016 09:18 AM, Pavel Hrdina wrote:
> > On Fri, Oct 07, 2016 at 07:00:26AM -0400, John Ferlan wrote:
> >> Add an optional "tls='yes'" option for a TCP chardev for the
> >> express purpose to enable setting up TLS for the chardev. This
> >> will assume that the qemu.conf settings have been adjusted as
> >> well as the environment configured properly.
> >>
> >> Signed-off-by: John Ferlan 
> >> ---
> >>  docs/formatdomain.html.in  | 21 +
> >>  docs/schemas/domaincommon.rng  |  5 +++
> >>  src/conf/domain_conf.c | 22 +-
> >>  src/conf/domain_conf.h |  1 +
> >>  src/qemu/qemu_command.c|  3 +-
> >>  src/qemu/qemu_hotplug.c|  3 +-
> >>  ...emuxml2argv-serial-tcp-tlsx509-chardev-tls.args | 30 +
> >>  ...qemuxml2argv-serial-tcp-tlsx509-chardev-tls.xml | 50 
> >> ++
> >>  .../qemuxml2argv-serial-tcp-tlsx509-chardev.xml|  2 +-
> >>  tests/qemuxml2argvtest.c   |  3 ++
> >>  ...muxml2xmlout-serial-tcp-tlsx509-chardev-tls.xml |  1 +
> >>  .../qemuxml2xmlout-serial-tcp-tlsx509-chardev.xml  |  2 +-
> >>  tests/qemuxml2xmltest.c|  1 +
> >>  13 files changed, 139 insertions(+), 5 deletions(-)
> >>  create mode 100644 
> >> tests/qemuxml2argvdata/qemuxml2argv-serial-tcp-tlsx509-chardev-tls.args
> >>  create mode 100644 
> >> tests/qemuxml2argvdata/qemuxml2argv-serial-tcp-tlsx509-chardev-tls.xml
> >>  create mode 12 
> >> tests/qemuxml2xmloutdata/qemuxml2xmlout-serial-tcp-tlsx509-chardev-tls.xml
> >>
> >> diff --git a/docs/formatdomain.html.in b/docs/formatdomain.html.in
> >> index 1266e9d..010530e 100644
> >> --- a/docs/formatdomain.html.in
> >> +++ b/docs/formatdomain.html.in
> >> @@ -6203,6 +6203,27 @@ qemu-kvm -net nic,model=? /dev/null
> >>/devices
> >>...
> >>  
> >> +
> >> +  Since 2.4.0, some hypervisors support 
> >> using
> >> +  a TLS X.509 certificate environment in order to encrypt all serial 
> >> TCP
> >> +  connections via a hypervisor configuration option. In order to 
> >> enable
> >> +  TLS for the domain an optional attribute tls can be 
> >> set to
> >> +  "yes". Combined with the hypervisor's capability to utilize the TLS
> >> +  environment allows for the character device to use the encrypted
> >> +  communication. If the attribute is not present, then the default
> >> +  setting is "no".
> > 
> > This is not correct in case of QEMU.  Before this patch the default was 
> > based on
> > chardev_tls from qemu.conf.  After this patch the default will be "no" even 
> > if
> > you set chardev_tls=1 and that breaks behavior of libvirt.  The test case
> > "serial-tcp-tlsx509-chardev-tls" where you had to add tls="yes" should also 
> > work
> > without this change.
> > 
> > This patch needs to be modified to take chardev_tls=1 in account and add 
> > tests
> > to make sure that we don't break it in the future.
> > 
> 
> This change was in response to v5 (and v6) review comments from Daniel :
> 
> v5: http://www.redhat.com/archives/libvir-list/2016-September/msg00294.html
> 
> v6: http://www.redhat.com/archives/libvir-list/2016-September/msg00317.html
> 
> I read those review requests as we need a way to be able to disable TLS
> on a chardev on a domain by domain and even chardev by chardev basis
> rather than it being the default enabled for every domain and every
> chardev in the domain.
> 
> Could you elaborate how it breaks the behavior of libvirt?  Currently a
> chardev doesn't have any TLS attribute - that qemu.conf change is from
> already agreed upon changes. This set of changes should have been able
> to go with those, but they've languished on the least through a release
> cycle (2.3.0), so while it may appear that something is one way - it in
> a way isn't.  Right now it's just pixie/fairy dust and a pipe dream.

The thing is that with libvirt-2.3.0 you can set chardev_tls=1 in qemu.conf and
therefore all chardevs for all domains uses TLS to encrypt communication.  This
patch introduces a new 'tls' attribute and its default value is 'no' and that
means if the user upgrades from libvirt-2.3.0 to libvirt-2.4.0 all chardevs stop
encrypting communication unless he sets tls="yes" for every single chardev in
every single domain.

The correct solution is:

- if chardev_tls is set to 1 and tls attribute is not configured in the XML
the default after starting the domain should be tls=yes

- if chardev_tls is not set and tls attribute is not configured in the XML
the default after starting the domain should be tls=no

Pavel

> 
> 
> John
> 
> > Pavel
> > 
> >> +
> >> +
> >> +  ...
> >> +  devices
> >> +serial type="tcp"
> >> +  source mode='connect' host="127.0.0.1" service="" 
> 

Re: [libvirt] [PATCH v8 1/5] domain: Add optional 'tls' attribute for TCP chardev

2016-10-14 Thread Pavel Hrdina
On Fri, Oct 07, 2016 at 07:00:26AM -0400, John Ferlan wrote:
> Add an optional "tls='yes'" option for a TCP chardev for the
> express purpose to enable setting up TLS for the chardev. This
> will assume that the qemu.conf settings have been adjusted as
> well as the environment configured properly.
> 
> Signed-off-by: John Ferlan 
> ---
>  docs/formatdomain.html.in  | 21 +
>  docs/schemas/domaincommon.rng  |  5 +++
>  src/conf/domain_conf.c | 22 +-
>  src/conf/domain_conf.h |  1 +
>  src/qemu/qemu_command.c|  3 +-
>  src/qemu/qemu_hotplug.c|  3 +-
>  ...emuxml2argv-serial-tcp-tlsx509-chardev-tls.args | 30 +
>  ...qemuxml2argv-serial-tcp-tlsx509-chardev-tls.xml | 50 
> ++
>  .../qemuxml2argv-serial-tcp-tlsx509-chardev.xml|  2 +-
>  tests/qemuxml2argvtest.c   |  3 ++
>  ...muxml2xmlout-serial-tcp-tlsx509-chardev-tls.xml |  1 +
>  .../qemuxml2xmlout-serial-tcp-tlsx509-chardev.xml  |  2 +-
>  tests/qemuxml2xmltest.c|  1 +
>  13 files changed, 139 insertions(+), 5 deletions(-)
>  create mode 100644 
> tests/qemuxml2argvdata/qemuxml2argv-serial-tcp-tlsx509-chardev-tls.args
>  create mode 100644 
> tests/qemuxml2argvdata/qemuxml2argv-serial-tcp-tlsx509-chardev-tls.xml
>  create mode 12 
> tests/qemuxml2xmloutdata/qemuxml2xmlout-serial-tcp-tlsx509-chardev-tls.xml
> 
> diff --git a/docs/formatdomain.html.in b/docs/formatdomain.html.in
> index 1266e9d..010530e 100644
> --- a/docs/formatdomain.html.in
> +++ b/docs/formatdomain.html.in
> @@ -6203,6 +6203,27 @@ qemu-kvm -net nic,model=? /dev/null
>/devices
>...
>  
> +
> +  Since 2.4.0, some hypervisors support using
> +  a TLS X.509 certificate environment in order to encrypt all serial TCP
> +  connections via a hypervisor configuration option. In order to enable
> +  TLS for the domain an optional attribute tls can be set to
> +  "yes". Combined with the hypervisor's capability to utilize the TLS
> +  environment allows for the character device to use the encrypted
> +  communication. If the attribute is not present, then the default
> +  setting is "no".

This is not correct in case of QEMU.  Before this patch the default was based on
chardev_tls from qemu.conf.  After this patch the default will be "no" even if
you set chardev_tls=1 and that breaks behavior of libvirt.  The test case
"serial-tcp-tlsx509-chardev-tls" where you had to add tls="yes" should also work
without this change.

This patch needs to be modified to take chardev_tls=1 in account and add tests
to make sure that we don't break it in the future.

Pavel

> +
> +
> +  ...
> +  devices
> +serial type="tcp"
> +  source mode='connect' host="127.0.0.1" service="" 
> tls="yes"/
> +  protocol type="raw"/
> +  target port="0"/
> +/serial
> +  /devices
> +  ...
> +
>  UDP network console
>  
>  
> diff --git a/docs/schemas/domaincommon.rng b/docs/schemas/domaincommon.rng
> index 6eeb4e9..362b90d 100644
> --- a/docs/schemas/domaincommon.rng
> +++ b/docs/schemas/domaincommon.rng
> @@ -3453,6 +3453,11 @@
>  
>
>  
> +
> +  
> +
> +  
> +
>  
>
>  
> diff --git a/src/conf/domain_conf.c b/src/conf/domain_conf.c
> index f562323..1f7c43f 100644
> --- a/src/conf/domain_conf.c
> +++ b/src/conf/domain_conf.c
> @@ -1961,6 +1961,8 @@ virDomainChrSourceDefCopy(virDomainChrSourceDefPtr dest,
>  
>  if (VIR_STRDUP(dest->data.tcp.service, src->data.tcp.service) < 0)
>  return -1;
> +
> +dest->data.tcp.haveTLS = src->data.tcp.haveTLS;
>  break;
>  
>  case VIR_DOMAIN_CHR_TYPE_UNIX:
> @@ -,6 +10001,7 @@ virDomainChrSourceDefParseXML(virDomainChrSourceDefPtr 
> def,
>  char *master = NULL;
>  char *slave = NULL;
>  char *append = NULL;
> +char *haveTLS = NULL;
>  int remaining = 0;
>  
>  while (cur != NULL) {
> @@ -10006,6 +10009,8 @@ 
> virDomainChrSourceDefParseXML(virDomainChrSourceDefPtr def,
>  if (xmlStrEqual(cur->name, BAD_CAST "source")) {
>  if (!mode)
>  mode = virXMLPropString(cur, "mode");
> +if (!haveTLS)
> +haveTLS = virXMLPropString(cur, "tls");
>  
>  switch ((virDomainChrType) def->type) {
>  case VIR_DOMAIN_CHR_TYPE_FILE:
> @@ -10182,6 +10187,15 @@ 
> virDomainChrSourceDefParseXML(virDomainChrSourceDefPtr def,
>  def->data.tcp.listen = true;
>  }
>  
> +if (haveTLS &&
> +(def->data.tcp.haveTLS =
> + virTristateBoolTypeFromString(haveTLS)) <= 0) {
> +virReportError(VIR_ERR_XML_ERROR,
> +   

Re: [libvirt] [PATCH 1/2] conf: add disk cache tuning parameters after qemu

2016-10-14 Thread Denis V. Lunev
On 10/05/2016 10:43 AM, Nikolay Shirokovskiy wrote:
> adding cc
>
> On 26.09.2016 13:36, Nikolay Shirokovskiy wrote:
>>
>> On 26.09.2016 13:04, Peter Krempa wrote:
>>> On Mon, Sep 26, 2016 at 12:15:42 +0300, Nikolay Shirokovskiy wrote:
 On 26.09.2016 12:01, Peter Krempa wrote:
>>> [...]
>>>
 Sorry, I forget to write down the motivation.

 Internally qemu uses 3 orthogonal flags to configure disk cache. They
 are exposed in interface too quite long time ago (29c4e2b). All-in-one
 cache parameter that libvirt uses now do not provide all possible
 values (5 vs 8). For example absent combination of direct + no flush (no 
 sync)
 is useful to speed up tests.
>>> Well, if there are useful combinations we can add them to the existing
>>> cache setting.
>>>
 So I decided to provide new possibilities just as qemu does - keep
 old parameter and use new ones to tune over.
>>> I don't think this is a good idea at all. It's very qemu specific and
>>> can be mapped to existing elements.
>>>
>>> Peter
>>>
>> Well up until now libvirt cache settings are exactly the same as the qemu 
>> ones. I thought
>> it would be inconsistent to intordocuce new name and then map internallly to 
>> qemu. Another point is that these 3 parameters are probably not that qemu 
>> specific.
>>
>> Nikolay
>>
>> --
>> libvir-list mailing list
>> libvir-list@redhat.com
>> https://www.redhat.com/mailman/listinfo/libvir-list
>>
the problem is that current modes are a little bit adhoc.
The describe non-trivial combination of 3 parameters,
which could be tuned on/off independently. That is why
it would be more clear to use the approach with separate
flags.

Den

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list


Re: [libvirt] [PATCH] util: Fix build on s390

2016-10-14 Thread Andreas Krebbel
On 10/07/2016 12:43 PM, Jiri Denemark wrote:
> GCC on s390 complains
> 
> util/virconf.c: In function 'virConfGetValueSizeT':
> util/virconf.c:1220:9: error: format '%zu' expects argument of type
> 'size_t', but argument 9 has type 'unsigned int' [-Werror=format=]
> 
> Signed-off-by: Jiri Denemark 
> ---
>  src/util/virconf.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/src/util/virconf.c b/src/util/virconf.c
> index 3e49f41..1372389 100644
> --- a/src/util/virconf.c
> +++ b/src/util/virconf.c
> @@ -1219,7 +1219,7 @@ int virConfGetValueSizeT(virConfPtr conf,
>  if (((unsigned long long)cval->l) > SIZE_MAX) {
>  virReportError(VIR_ERR_INTERNAL_ERROR,
> _("%s: value for '%s' parameter must be in range 
> 0:%zu"),
> -   conf->filename, setting, SIZE_MAX);
> +   conf->filename, setting, (size_t) SIZE_MAX);
>  return -1;
>  }
>  #endif

S/390 32 bit uses an "unsigned long" as size_t while every other 32 bit target 
uses "unsigned int".
The __SIZE_MAX__ predefined macro generated by GCC itself handles this 
correctly by defining it as
4294967295UL. However, the stdint.h header defines it as 4294967295U. So in the 
end we probably have
to fix the Glibc header. This workaround is ok I think. Directly using 
__SIZE_MAX__ instead of
SIZE_MAX would not be portable.

-Andreas-


--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list


Re: [libvirt] [PATCH] util: Fix build on s390

2016-10-14 Thread Andreas Krebbel
On 10/07/2016 12:43 PM, Jiri Denemark wrote:
> GCC on s390 complains
> 
> util/virconf.c: In function 'virConfGetValueSizeT':
> util/virconf.c:1220:9: error: format '%zu' expects argument of type
> 'size_t', but argument 9 has type 'unsigned int' [-Werror=format=]
> 
> Signed-off-by: Jiri Denemark 
> ---
>  src/util/virconf.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/src/util/virconf.c b/src/util/virconf.c
> index 3e49f41..1372389 100644
> --- a/src/util/virconf.c
> +++ b/src/util/virconf.c
> @@ -1219,7 +1219,7 @@ int virConfGetValueSizeT(virConfPtr conf,
>  if (((unsigned long long)cval->l) > SIZE_MAX) {
>  virReportError(VIR_ERR_INTERNAL_ERROR,
> _("%s: value for '%s' parameter must be in range 
> 0:%zu"),
> -   conf->filename, setting, SIZE_MAX);
> +   conf->filename, setting, (size_t) SIZE_MAX);
>  return -1;
>  }
>  #endif

I've just noticed that a colleague fixed that already quite some time ago in 
Glibc. So please update:

commit 26011b5cfa6a1a8d8005d65f11d97498444a4e95
Author: Stefan Liebler 
Date:   Mon Mar 24 16:46:51 2014 +0100

S390: Define SIZE_MAX as unsigned long (BZ #16712).

diff --git a/ChangeLog b/ChangeLog
index 4da1027..c0d13ab 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,5 +1,15 @@
 2014-03-24  Stefan Liebler 

+   [BZ #16712]
+   * sysdeps/s390/s390-32/bits/wordsize.h
+   (__WORDSIZE32_SIZE_ULONG): New define.
+   * sysdeps/s390/s390-64/bits/wordsize.h
+   (__WORDSIZE32_SIZE_ULONG): Likewise.
+   * sysdeps/generic/stdint.h (SIZE_MAX):
+   Define as UL if __WORDSIZE32_SIZE_ULONG.

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list


Re: [libvirt] [PATCH v3 19/18] [RFC] qemu: assure there are always at least 4 open pcie-root-ports for hotplug

2016-10-14 Thread Andrea Bolognani
On Fri, 2016-10-14 at 16:54 +0200, Ján Tomko wrote:
> Also, would it be possible to make this feature of leaving
> free hot-pluggable slots opt-in?
> 
> E.g. a  without an index
> would be considered a port where we should not put devices
> with auto-assigned addresses.
> 
> (This might actually be more ugly than the proposed solution,
> or the 'freeHotplugSlots' attribute, but I dislike implicit
> device additions after having model='none' memballoon and usb
> controller)

If we can find a way to make it opt-in without it turning
out incredibly ugly (eg. 'freeHotplugSlots' or similar
paramers) or requiring too much knowledge from the users /
management applications (eg. "you have x legacy PCI devices
and y PCI Express devices, that means adding x + y + z + 3
pcie-root-ports before passing the XML to libvirt") I'm all
for that. So far we haven't been able to come up with
anything like that, though :)

I think the current proposal is fairly okay because it allows
for easy opt-out, and if we reduce the number of extra ports
to just one as per your comments I don't think people will
care at all. As far as I'm concerned, that's a very good
balance; it's certainly better than the status quo of adding
a completely useless dmi-to-pci-bridge + pci-bridge
combination to every single q35 guest.

-- 
Andrea Bolognani / Red Hat / Virtualization

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [PATCH v8 1/5] domain: Add optional 'tls' attribute for TCP chardev

2016-10-14 Thread Pavel Hrdina
On Fri, Oct 14, 2016 at 10:58:12AM -0400, John Ferlan wrote:
> [...]
> >>
> >> UGH... mea culpa - in my mind the TLS hadn't been added to the chardev
> >> yet and that was the rest of this series...  Of course the rest of this
> >> series is adding the passphrase for the environment ().
> >>
> >> If I could have got that review earlier, then this situation wouldn't be
> >> a problem (see in my mind it wasn't).
> >>
> >> If a domain is already running, then encryption is occurring and this
> >> setting has no effect except for hotplug.
> >>
> >> If we were using encryption in 2.3.0... stopped our domain... installed
> >> 2.4.0... started our domain, then yes, I see/agree  Frustrating
> >> since there's really no "simple" way to determine this.
> >>
> >>>
> >>> The correct solution is:
> >>>
> >>> - if chardev_tls is set to 1 and tls attribute is not configured in 
> >>> the XML
> >>> the default after starting the domain should be tls=yes
> >>
> >> So IOW:
> >>
> >> +if (cfg->chardevTLS &&
> >> +dev->data.tcp.haveTLS == VIR_TRISTATE_BOOL_YES) {
> >>
> >> changes to
> >>
> >> +if (cfg->chardevTLS &&
> >> +dev->data.tcp.haveTLS != VIR_TRISTATE_BOOL_NO) {
> >>
> >> or (haveTLS == YES || haveTLS == ABSENT)
> >>
> >> This of course is essentially the logic from v6 which said disableTLS on
> >> a case by case basis All we have now is the positive form...
> >>
> >> So for both qemuBuildChrChardevStr and qemuDomainAttachChrDevice I'd
> >> have a similar change.  Does that suffice and do you need to see the 
> >> change?
> > 
> > I think that we should reflect the state in live XML if the attribute 
> > exists.
> > 
> > Add a code to qemuProcessPrepareDomain() that will set dev->data.tcp.haveTLS
> > to config value if dev->data.tcp.haveTLS == VIR_TRISTATE_BOOL_ABSENT and in
> > qemuBuildChrChardevStr() you can just check if
> > dev->data.tcp.haveTLS == VIR_TRISTATE_BOOL_YES.  This will also ensure that
> > the live XML contains the 'tls' attribute.  But make sure, that migration 
> > works
> > properly for all combinations.
> > 
> 
> I don't see the advantage... Altering the running domain would involve

The advantage is in case when the chardevTLS is set but the offline XML doesn't
have 'tls' attribute configured.  If the domain is started than it's perfectly
clear from the live XML that the tls is enabled or not.

> messing in qemuProcessAttach and setting the attribute for the domain if
> chardevTLS is set *BUT* how do we know without a bit of introspection if
> that domain was started with TLS and is using TLS? (IOW: looking at the
> running domain for tls-creds-x509). Additionally, someone could have

Well, we do that introspection and we must do it to properly detect what has
been used to start that domain.  The domain XML should reflect the current state
as closely as possible.

> changed the chardevTLS setting in qemu.conf after the domain was
> initially started and thus it wouldn't have it, so setting it blindly

Yes, someone can change the chardevTLS after the domain was started and it won't
break anything.  If the domain is destroyed and started again, everything works,
if the domain is saved and started again it will start with TLS encryption
enabled.  If someone removes certificates from qemu.conf and completely disable
TLS encryption and the domain was saved with TLS encryption configured it's
desirable that it should error out while restoring that domain.

> would probably have disastrous results.
> 
> Altering a domain definition during qemuProcessPrepareDomain (e.g.
> domain startup time) still has no way of determining if that domain had
> ever been started using TLS if it's not in the XML.

I don't understand why we need to know if the domain had ever been started using
TLS?  

> Finally, yeah migration is the final nail in the coffin for this. How
> does one migrate from 2.4 to 2.3 if 2.3 doesn't have this attribute we
> just quietly set to YES for them?

Well if the attribute is set to YES and the chardevTLS is set to 1 or if the
attribute is set to NO and chardevTLS is set to 0 we can safely remove the
attribute from migratable XML, because it's on user to ensure that the
configuration is properly set on both sides, for other cases that migration
should not be allowed because whether the encryption is enabled or not could be
changed.

Pavel

> I think the != NO is the safest solution (plus some adjustment to the
> formatdomain.html.in in order to describe this situation).
> 
> John
> 
> > I guess a another version would be better if you agree with exposing current
> > state into live XML.
> > 
> > Pavel
> > 
> >>> - if chardev_tls is not set and tls attribute is not configured in 
> >>> the XML
> >>> the default after starting the domain should be tls=no
> >>>
> >>
> >> We're not getting anywhere if chardev_tls is not set.
> >>
> >> John
> >>
> >> [...]
> >>
> >> --
> >> libvir-list mailing list
> >> libvir-list@redhat.com
> >> 

Re: [libvirt] [PATCH 8/8] qemu: Add support for hot/cold-(un)plug of shmem devices

2016-10-14 Thread Martin Kletzander

On Fri, Oct 07, 2016 at 01:05:29PM -0400, John Ferlan wrote:



On 09/27/2016 08:24 AM, Martin Kletzander wrote:

This is needed in order to migrate a domain with shmem devices as that
is not allowed to migrate.


Sure, but how would anyone know since the migration fails... Not sure
where could/should describe it, but perhaps something nice to be
described somewhere...



Because they'll get "migration with shmem device is not supported"
message when they try it.



Signed-off-by: Martin Kletzander 
---
 src/qemu/qemu_driver.c |  39 +++-
 src/qemu/qemu_hotplug.c| 247 -
 src/qemu/qemu_hotplug.h|   6 +
 tests/qemuhotplugtest.c|  21 ++
 .../qemuhotplug-ivshmem-doorbell-detach.xml|   7 +
 .../qemuhotplug-ivshmem-doorbell.xml   |   4 +
 .../qemuhotplug-ivshmem-plain-detach.xml   |   6 +
 .../qemuhotplug-ivshmem-plain.xml  |   3 +
 ...muhotplug-base-live+ivshmem-doorbell-detach.xml |   1 +
 .../qemuhotplug-base-live+ivshmem-doorbell.xml |  65 ++
 .../qemuhotplug-base-live+ivshmem-plain-detach.xml |   1 +
 .../qemuhotplug-base-live+ivshmem-plain.xml|  58 +
 12 files changed, 453 insertions(+), 5 deletions(-)
 create mode 100644 
tests/qemuhotplugtestdevices/qemuhotplug-ivshmem-doorbell-detach.xml
 create mode 100644 
tests/qemuhotplugtestdevices/qemuhotplug-ivshmem-doorbell.xml
 create mode 100644 
tests/qemuhotplugtestdevices/qemuhotplug-ivshmem-plain-detach.xml
 create mode 100644 tests/qemuhotplugtestdevices/qemuhotplug-ivshmem-plain.xml
 create mode 12 
tests/qemuhotplugtestdomains/qemuhotplug-base-live+ivshmem-doorbell-detach.xml
 create mode 100644 
tests/qemuhotplugtestdomains/qemuhotplug-base-live+ivshmem-doorbell.xml
 create mode 12 
tests/qemuhotplugtestdomains/qemuhotplug-base-live+ivshmem-plain-detach.xml
 create mode 100644 
tests/qemuhotplugtestdomains/qemuhotplug-base-live+ivshmem-plain.xml


Jeez someday I should try to learn how to use these hotplug tests ;-)



I have some reworks of that in the works too, so if you'd like that you
can finish the series ;)


[...]


diff --git a/src/qemu/qemu_hotplug.c b/src/qemu/qemu_hotplug.c
index 72dd93bbe467..03d75be5e3d7 100644
--- a/src/qemu/qemu_hotplug.c
+++ b/src/qemu/qemu_hotplug.c
@@ -2242,6 +2242,131 @@ qemuDomainAttachHostDevice(virConnectPtr conn,
 return -1;
 }

+
+int
+qemuDomainAttachShmemDevice(virQEMUDriverPtr driver,
+virDomainObjPtr vm,
+virDomainShmemDefPtr shmem)
+{
+int ret = -1;
+char *shmstr = NULL;
+char *charAlias = NULL;
+char *memAlias = NULL;
+bool release_backing = false;
+bool release_address = true;
+virErrorPtr orig_err = NULL;
+virJSONValuePtr props = NULL;
+qemuDomainObjPrivatePtr priv = vm->privateData;
+
+switch ((virDomainShmemModel)shmem->model) {
+case VIR_DOMAIN_SHMEM_MODEL_IVSHMEM_PLAIN:
+case VIR_DOMAIN_SHMEM_MODEL_IVSHMEM_DOORBELL:



This is where I'd expect the capabilities checks to be



Now it's added in the qemuBuildShmemDevStr(), so it will work inherently.


[...]


@@ -3486,6 +3611,61 @@ qemuDomainRemoveRNGDevice(virQEMUDriverPtr driver,
 }


+static int
+qemuDomainRemoveShmemDevice(virQEMUDriverPtr driver,
+virDomainObjPtr vm,
+virDomainShmemDefPtr shmem)
+{
+int rc;
+int ret = -1;
+ssize_t idx = -1;
+char *charAlias = NULL;
+char *memAlias = NULL;
+qemuDomainObjPrivatePtr priv = vm->privateData;
+virObjectEventPtr event = NULL;
+
+VIR_DEBUG("Removing shmem device %s from domain %p %s",
+  shmem->info.alias, vm, vm->def->name);
+
+if (shmem->server.enabled) {
+if (virAsprintf(, "char%s", shmem->info.alias) < 0)
+return -1;
+} else {
+if (virAsprintf(, "shmmem-%s", shmem->info.alias) < 0)
+return -1;
+}
+
+qemuDomainObjEnterMonitor(driver, vm);
+
+if (shmem->server.enabled)
+rc = qemuMonitorDetachCharDev(priv->mon, charAlias);
+else
+rc = qemuMonitorDelObject(priv->mon, memAlias);
+
+if (qemuDomainObjExitMonitor(driver, vm) < 0)
+goto cleanup;
+
+virDomainAuditShmem(vm, shmem, "detach", rc == 0);
+
+if (rc < 0)
+goto cleanup;
+
+event = virDomainEventDeviceRemovedNewFromObj(vm, shmem->info.alias);
+qemuDomainEventQueue(driver, event);
+
+if ((idx = virDomainShmemDefFind(vm->def, shmem)) >= 0)
+virDomainShmemDefRemove(vm->def, idx);
+qemuDomainReleaseDeviceAddress(vm, >info, NULL);


I think there be a virDomainShmemDefFree(shmem) here, right?  The
virDomainShmemDefRemove only removes shmem from the list



Yes, thanks for noticing.


@@ -4105,6 +4288,68 @@ int qemuDomainDetachHostDevice(virQEMUDriverPtr driver,
 return 

Re: [libvirt] [PATCH v3 19/18] [RFC] qemu: assure there are always at least 4 open pcie-root-ports for hotplug

2016-10-14 Thread Ján Tomko

On Fri, Oct 14, 2016 at 03:13:16PM +0200, Andrea Bolognani wrote:

On Thu, 2016-09-29 at 15:20 -0400, Laine Stump wrote:

In the absense of anything configurable, we will need to pick a number
though. I've done that here, and now we can argue about it (or not :-)


Ján raised an interesting point:


[in person, there is no mailing list link]


whatever number we choose,
no matter how wrong doing so is, some user or application
will end up relying on us providing at least that many
hotpluggable ports, so there's no going back.

For that reason, I would recommend leaving just a single
empty hotpluggable port for now, and raise the number in
the future if we find out that one's definitely not enough.



Also, would it be possible to make this feature of leaving
free hot-pluggable slots opt-in?

E.g. a  without an index
would be considered a port where we should not put devices
with auto-assigned addresses.

(This might actually be more ugly than the proposed solution,
or the 'freeHotplugSlots' attribute, but I dislike implicit
device additions after having model='none' memballoon and usb
controller)

Jan


signature.asc
Description: Digital signature
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [PATCH v8 1/5] domain: Add optional 'tls' attribute for TCP chardev

2016-10-14 Thread John Ferlan
[...]
>>
>> UGH... mea culpa - in my mind the TLS hadn't been added to the chardev
>> yet and that was the rest of this series...  Of course the rest of this
>> series is adding the passphrase for the environment ().
>>
>> If I could have got that review earlier, then this situation wouldn't be
>> a problem (see in my mind it wasn't).
>>
>> If a domain is already running, then encryption is occurring and this
>> setting has no effect except for hotplug.
>>
>> If we were using encryption in 2.3.0... stopped our domain... installed
>> 2.4.0... started our domain, then yes, I see/agree  Frustrating
>> since there's really no "simple" way to determine this.
>>
>>>
>>> The correct solution is:
>>>
>>> - if chardev_tls is set to 1 and tls attribute is not configured in the 
>>> XML
>>> the default after starting the domain should be tls=yes
>>
>> So IOW:
>>
>> +if (cfg->chardevTLS &&
>> +dev->data.tcp.haveTLS == VIR_TRISTATE_BOOL_YES) {
>>
>> changes to
>>
>> +if (cfg->chardevTLS &&
>> +dev->data.tcp.haveTLS != VIR_TRISTATE_BOOL_NO) {
>>
>> or (haveTLS == YES || haveTLS == ABSENT)
>>
>> This of course is essentially the logic from v6 which said disableTLS on
>> a case by case basis All we have now is the positive form...
>>
>> So for both qemuBuildChrChardevStr and qemuDomainAttachChrDevice I'd
>> have a similar change.  Does that suffice and do you need to see the change?
> 
> I think that we should reflect the state in live XML if the attribute exists.
> 
> Add a code to qemuProcessPrepareDomain() that will set dev->data.tcp.haveTLS
> to config value if dev->data.tcp.haveTLS == VIR_TRISTATE_BOOL_ABSENT and in
> qemuBuildChrChardevStr() you can just check if
> dev->data.tcp.haveTLS == VIR_TRISTATE_BOOL_YES.  This will also ensure that
> the live XML contains the 'tls' attribute.  But make sure, that migration 
> works
> properly for all combinations.
> 

I don't see the advantage... Altering the running domain would involve
messing in qemuProcessAttach and setting the attribute for the domain if
chardevTLS is set *BUT* how do we know without a bit of introspection if
that domain was started with TLS and is using TLS? (IOW: looking at the
running domain for tls-creds-x509). Additionally, someone could have
changed the chardevTLS setting in qemu.conf after the domain was
initially started and thus it wouldn't have it, so setting it blindly
would probably have disastrous results.

Altering a domain definition during qemuProcessPrepareDomain (e.g.
domain startup time) still has no way of determining if that domain had
ever been started using TLS if it's not in the XML.

Finally, yeah migration is the final nail in the coffin for this. How
does one migrate from 2.4 to 2.3 if 2.3 doesn't have this attribute we
just quietly set to YES for them?

I think the != NO is the safest solution (plus some adjustment to the
formatdomain.html.in in order to describe this situation).

John

> I guess a another version would be better if you agree with exposing current
> state into live XML.
> 
> Pavel
> 
>>> - if chardev_tls is not set and tls attribute is not configured in the 
>>> XML
>>> the default after starting the domain should be tls=no
>>>
>>
>> We're not getting anywhere if chardev_tls is not set.
>>
>> John
>>
>> [...]
>>
>> --
>> libvir-list mailing list
>> libvir-list@redhat.com
>> https://www.redhat.com/mailman/listinfo/libvir-list

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list


Re: [libvirt] [Qemu-devel] [PATCH v6 3/3] target-i386: Return runnability information on query-cpu-definitions

2016-10-14 Thread Eduardo Habkost
On Tue, Oct 11, 2016 at 04:13:44PM +0200, Igor Mammedov wrote:
> On Fri,  7 Oct 2016 17:29:02 -0300
> Eduardo Habkost  wrote:
> 
> > Fill the "unavailable-features" field on the x86 implementation
> > of query-cpu-definitions.
> > 
> > Cc: Jiri Denemark 
> > Cc: libvir-list@redhat.com
> > Signed-off-by: Eduardo Habkost 
> Reviewed-by: Igor Mammedov 

Thanks. Applied to x86-next.

-- 
Eduardo

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list


Re: [libvirt] [PATCH v8 1/5] domain: Add optional 'tls' attribute for TCP chardev

2016-10-14 Thread Pavel Hrdina
On Fri, Oct 14, 2016 at 10:16:19AM -0400, John Ferlan wrote:
> 
> 
> On 10/14/2016 09:49 AM, Pavel Hrdina wrote:
> > On Fri, Oct 14, 2016 at 09:32:45AM -0400, John Ferlan wrote:
> >>
> >>
> >> On 10/14/2016 09:18 AM, Pavel Hrdina wrote:
> >>> On Fri, Oct 07, 2016 at 07:00:26AM -0400, John Ferlan wrote:
>  Add an optional "tls='yes'" option for a TCP chardev for the
>  express purpose to enable setting up TLS for the chardev. This
>  will assume that the qemu.conf settings have been adjusted as
>  well as the environment configured properly.
> 
>  Signed-off-by: John Ferlan 
>  ---
>   docs/formatdomain.html.in  | 21 +
>   docs/schemas/domaincommon.rng  |  5 +++
>   src/conf/domain_conf.c | 22 +-
>   src/conf/domain_conf.h |  1 +
>   src/qemu/qemu_command.c|  3 +-
>   src/qemu/qemu_hotplug.c|  3 +-
>   ...emuxml2argv-serial-tcp-tlsx509-chardev-tls.args | 30 +
>   ...qemuxml2argv-serial-tcp-tlsx509-chardev-tls.xml | 50 
>  ++
>   .../qemuxml2argv-serial-tcp-tlsx509-chardev.xml|  2 +-
>   tests/qemuxml2argvtest.c   |  3 ++
>   ...muxml2xmlout-serial-tcp-tlsx509-chardev-tls.xml |  1 +
>   .../qemuxml2xmlout-serial-tcp-tlsx509-chardev.xml  |  2 +-
>   tests/qemuxml2xmltest.c|  1 +
>   13 files changed, 139 insertions(+), 5 deletions(-)
>   create mode 100644 
>  tests/qemuxml2argvdata/qemuxml2argv-serial-tcp-tlsx509-chardev-tls.args
>   create mode 100644 
>  tests/qemuxml2argvdata/qemuxml2argv-serial-tcp-tlsx509-chardev-tls.xml
>   create mode 12 
>  tests/qemuxml2xmloutdata/qemuxml2xmlout-serial-tcp-tlsx509-chardev-tls.xml
> 
>  diff --git a/docs/formatdomain.html.in b/docs/formatdomain.html.in
>  index 1266e9d..010530e 100644
>  --- a/docs/formatdomain.html.in
>  +++ b/docs/formatdomain.html.in
>  @@ -6203,6 +6203,27 @@ qemu-kvm -net nic,model=? /dev/null
> /devices
> ...
>   
>  +
>  +  Since 2.4.0, some hypervisors support 
>  using
>  +  a TLS X.509 certificate environment in order to encrypt all 
>  serial TCP
>  +  connections via a hypervisor configuration option. In order to 
>  enable
>  +  TLS for the domain an optional attribute tls can be 
>  set to
>  +  "yes". Combined with the hypervisor's capability to utilize the 
>  TLS
>  +  environment allows for the character device to use the encrypted
>  +  communication. If the attribute is not present, then the default
>  +  setting is "no".
> >>>
> >>> This is not correct in case of QEMU.  Before this patch the default was 
> >>> based on
> >>> chardev_tls from qemu.conf.  After this patch the default will be "no" 
> >>> even if
> >>> you set chardev_tls=1 and that breaks behavior of libvirt.  The test case
> >>> "serial-tcp-tlsx509-chardev-tls" where you had to add tls="yes" should 
> >>> also work
> >>> without this change.
> >>>
> >>> This patch needs to be modified to take chardev_tls=1 in account and add 
> >>> tests
> >>> to make sure that we don't break it in the future.
> >>>
> >>
> >> This change was in response to v5 (and v6) review comments from Daniel :
> >>
> >> v5: http://www.redhat.com/archives/libvir-list/2016-September/msg00294.html
> >>
> >> v6: http://www.redhat.com/archives/libvir-list/2016-September/msg00317.html
> >>
> >> I read those review requests as we need a way to be able to disable TLS
> >> on a chardev on a domain by domain and even chardev by chardev basis
> >> rather than it being the default enabled for every domain and every
> >> chardev in the domain.
> >>
> >> Could you elaborate how it breaks the behavior of libvirt?  Currently a
> >> chardev doesn't have any TLS attribute - that qemu.conf change is from
> >> already agreed upon changes. This set of changes should have been able
> >> to go with those, but they've languished on the least through a release
> >> cycle (2.3.0), so while it may appear that something is one way - it in
> >> a way isn't.  Right now it's just pixie/fairy dust and a pipe dream.
> > 
> > The thing is that with libvirt-2.3.0 you can set chardev_tls=1 in qemu.conf 
> > and
> > therefore all chardevs for all domains uses TLS to encrypt communication.  
> > This
> > patch introduces a new 'tls' attribute and its default value is 'no' and 
> > that
> > means if the user upgrades from libvirt-2.3.0 to libvirt-2.4.0 all chardevs 
> > stop
> > encrypting communication unless he sets tls="yes" for every single chardev 
> > in
> > every single domain.
> 
> 
> UGH... mea culpa - in my mind the TLS hadn't been added to the chardev
> yet and that was the rest of this series...  Of 

Re: [libvirt] [Qemu-devel] [PATCH] fixup! target-i386: x86_cpu_load_features() function

2016-10-14 Thread Eduardo Habkost
On Tue, Oct 11, 2016 at 01:41:30PM +0200, Igor Mammedov wrote:
[...]
> > 
> > Oops, leftover from v5. Thanks for spotting that! Fixup below.
> > 
> > Signed-off-by: Eduardo Habkost 
> Reviewed-by: Igor Mammedov 

Thanks. Patch + fixup applied to x86-next.

-- 
Eduardo

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list


[libvirt] [PATCH 2/2] libssh_transport: add new libssh-based transport

2016-10-14 Thread Pino Toscano
Implement a new libssh transport, which uses libssh to communicate with
remote hosts, and use it in virNetSockets.

This new transport supports all the common ssh authentication methods,
making use of libvirt's auth callbacks for interaction with the user.

Most of the functionalities and implementation are based on the libssh2
transport.
---
 config-post.h |2 +
 configure.ac  |3 +
 include/libvirt/virterror.h   |2 +
 m4/virt-libssh.m4 |   26 +
 src/Makefile.am   |   21 +-
 src/libvirt_libssh.syms   |   22 +
 src/remote/remote_driver.c|   41 ++
 src/rpc/virnetclient.c|  123 
 src/rpc/virnetclient.h|   13 +
 src/rpc/virnetlibsshsession.c | 1267 +
 src/rpc/virnetlibsshsession.h |   80 +++
 src/rpc/virnetsocket.c|  179 ++
 src/rpc/virnetsocket.h|   13 +
 src/util/virerror.c   |9 +-
 14 files changed, 1798 insertions(+), 3 deletions(-)
 create mode 100644 m4/virt-libssh.m4
 create mode 100644 src/libvirt_libssh.syms
 create mode 100644 src/rpc/virnetlibsshsession.c
 create mode 100644 src/rpc/virnetlibsshsession.h

diff --git a/config-post.h b/config-post.h
index 6eb63db..090cc28 100644
--- a/config-post.h
+++ b/config-post.h
@@ -36,6 +36,7 @@
 # undef WITH_DTRACE_PROBES
 # undef WITH_GNUTLS
 # undef WITH_GNUTLS_GCRYPT
+# undef WITH_LIBSSH
 # undef WITH_MACVTAP
 # undef WITH_NUMACTL
 # undef WITH_SASL
@@ -60,6 +61,7 @@
 # undef WITH_DTRACE_PROBES
 # undef WITH_GNUTLS
 # undef WITH_GNUTLS_GCRYPT
+# undef WITH_LIBSSH
 # undef WITH_MACVTAP
 # undef WITH_NUMACTL
 # undef WITH_SASL
diff --git a/configure.ac b/configure.ac
index dfc536f..f526f41 100644
--- a/configure.ac
+++ b/configure.ac
@@ -218,6 +218,7 @@ if test "$with_remote" = "no" ; then
   with_gnutls=no
   with_ssh2=no
   with_sasl=no
+  with_libssh=no
 fi
 # Stateful drivers are useful only when building the daemon.
 if test "$with_libvirtd" = "no" ; then
@@ -260,6 +261,7 @@ LIBVIRT_CHECK_UDEV
 LIBVIRT_CHECK_WIRESHARK
 LIBVIRT_CHECK_NSS
 LIBVIRT_CHECK_YAJL
+LIBVIRT_CHECK_LIBSSH
 
 AC_MSG_CHECKING([for CPUID instruction])
 AC_COMPILE_IFELSE([AC_LANG_PROGRAM(
@@ -2786,6 +2788,7 @@ LIBVIRT_RESULT_DBUS
 LIBVIRT_RESULT_FUSE
 LIBVIRT_RESULT_GLUSTER
 LIBVIRT_RESULT_HAL
+LIBVIRT_RESULT_LIBSSH
 LIBVIRT_RESULT_NETCF
 LIBVIRT_RESULT_NUMACTL
 LIBVIRT_RESULT_OPENWSMAN
diff --git a/include/libvirt/virterror.h b/include/libvirt/virterror.h
index efe83aa..2efee8f 100644
--- a/include/libvirt/virterror.h
+++ b/include/libvirt/virterror.h
@@ -131,6 +131,7 @@ typedef enum {
 VIR_FROM_XENXL = 64,/* Error from Xen xl config code */
 
 VIR_FROM_PERF = 65, /* Error from perf */
+VIR_FROM_LIBSSH = 66,   /* Error from libssh connection transport */
 
 # ifdef VIR_ENUM_SENTINELS
 VIR_ERR_DOMAIN_LAST
@@ -317,6 +318,7 @@ typedef enum {
 VIR_ERR_NO_CLIENT = 96, /* Client was not found */
 VIR_ERR_AGENT_UNSYNCED = 97,/* guest agent replies with wrong id
to guest-sync command */
+VIR_ERR_LIBSSH = 98,/* error in libssh transport driver */
 } virErrorNumber;
 
 /**
diff --git a/m4/virt-libssh.m4 b/m4/virt-libssh.m4
new file mode 100644
index 000..88ece21
--- /dev/null
+++ b/m4/virt-libssh.m4
@@ -0,0 +1,26 @@
+dnl The libssh.so library
+dnl
+dnl Copyright (C) 2016 Red Hat, Inc.
+dnl
+dnl This library is free software; you can redistribute it and/or
+dnl modify it under the terms of the GNU Lesser General Public
+dnl License as published by the Free Software Foundation; either
+dnl version 2.1 of the License, or (at your option) any later version.
+dnl
+dnl This library is distributed in the hope that it will be useful,
+dnl but WITHOUT ANY WARRANTY; without even the implied warranty of
+dnl MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+dnl Lesser General Public License for more details.
+dnl
+dnl You should have received a copy of the GNU Lesser General Public
+dnl License along with this library.  If not, see
+dnl .
+dnl
+
+AC_DEFUN([LIBVIRT_CHECK_LIBSSH],[
+  LIBVIRT_CHECK_PKG([LIBSSH], [libssh], [0.7])
+])
+
+AC_DEFUN([LIBVIRT_RESULT_LIBSSH],[
+  LIBVIRT_RESULT_LIB([LIBSSH])
+])
diff --git a/src/Makefile.am b/src/Makefile.am
index 8ee5567..4a6ccf3 100644
--- a/src/Makefile.am
+++ b/src/Makefile.am
@@ -2126,6 +2126,12 @@ else ! WITH_ATOMIC_OPS_PTHREAD
 SYM_FILES += $(srcdir)/libvirt_atomic.syms
 endif ! WITH_ATOMIC_OPS_PTHREAD
 
+if WITH_LIBSSH
+USED_SYM_FILES += $(srcdir)/libvirt_libssh.syms
+else ! WITH_LIBSSH
+SYM_FILES += $(srcdir)/libvirt_libssh.syms
+endif ! WITH_LIBSSH
+
 EXTRA_DIST += \
libvirt_public.syms \
libvirt_lxc.syms\
@@ -2203,7 +2209,8 @@ libvirt_admin_la_CFLAGS += \
$(YAJL_CFLAGS)  \
$(SSH2_CFLAGS)  \

[libvirt] [PATCH 1/2] virNetSocket: allow to not close FD

2016-10-14 Thread Pino Toscano
Add an internal variable to mark the FD as "not owned" by the
virNetSocket, in case the internal implementation takes the actual
ownership of the descriptor; this avoids a warning when closing the
socket, as the FD would be invalid.
---
 src/rpc/virnetsocket.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/src/rpc/virnetsocket.c b/src/rpc/virnetsocket.c
index 405f5ba..05f20a5 100644
--- a/src/rpc/virnetsocket.c
+++ b/src/rpc/virnetsocket.c
@@ -77,6 +77,7 @@ struct _virNetSocket {
 pid_t pid;
 int errfd;
 bool client;
+bool ownsFd;
 
 /* Event callback fields */
 virNetSocketIOFunc func;
@@ -248,6 +249,7 @@ static virNetSocketPtr virNetSocketNew(virSocketAddrPtr 
localAddr,
 sock->errfd = errfd;
 sock->pid = pid;
 sock->watch = -1;
+sock->ownsFd = true;
 
 /* Disable nagle for TCP sockets */
 if (sock->localAddr.data.sa.sa_family == AF_INET ||
@@ -1202,7 +1204,8 @@ void virNetSocketDispose(void *obj)
 virObjectUnref(sock->sshSession);
 #endif
 
-VIR_FORCE_CLOSE(sock->fd);
+if (sock->ownsFd)
+VIR_FORCE_CLOSE(sock->fd);
 VIR_FORCE_CLOSE(sock->errfd);
 
 virProcessAbort(sock->pid);
-- 
2.7.4

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list


[libvirt] [PATCH 0/2] RFC: New libssh transport

2016-10-14 Thread Pino Toscano
Hi,

this series introduces a new libssh transport in libvirt, based on the
libssh C library.  This library supports what libssh2 does, and more:
- easier API for known_hosts handling (there's a ticket upstream to
  request extensions for it, but what is implemented now works well)
- potential GSSAPI authentication (not enabled yet because of a libssh
  bug [1]
- easier API for ssh-agent support

TODO:
- implement the keyboard-interactive authentication method
- more testing than my own

The implementation for the new transport is based on the libssh2 one,
hence it shares origin and style.

[1] https://red.libssh.org/issues/242

Thanks,


Pino Toscano (2):
  virNetSocket: allow to not close FD
  libssh_transport: add new libssh-based transport

 config-post.h |2 +
 configure.ac  |3 +
 include/libvirt/virterror.h   |2 +
 m4/virt-libssh.m4 |   26 +
 src/Makefile.am   |   21 +-
 src/libvirt_libssh.syms   |   22 +
 src/remote/remote_driver.c|   41 ++
 src/rpc/virnetclient.c|  123 
 src/rpc/virnetclient.h|   13 +
 src/rpc/virnetlibsshsession.c | 1267 +
 src/rpc/virnetlibsshsession.h |   80 +++
 src/rpc/virnetsocket.c|  184 +-
 src/rpc/virnetsocket.h|   13 +
 src/util/virerror.c   |9 +-
 14 files changed, 1802 insertions(+), 4 deletions(-)
 create mode 100644 m4/virt-libssh.m4
 create mode 100644 src/libvirt_libssh.syms
 create mode 100644 src/rpc/virnetlibsshsession.c
 create mode 100644 src/rpc/virnetlibsshsession.h

-- 
2.7.4

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list


Re: [libvirt] [PATCH v8 1/5] domain: Add optional 'tls' attribute for TCP chardev

2016-10-14 Thread John Ferlan


On 10/14/2016 09:49 AM, Pavel Hrdina wrote:
> On Fri, Oct 14, 2016 at 09:32:45AM -0400, John Ferlan wrote:
>>
>>
>> On 10/14/2016 09:18 AM, Pavel Hrdina wrote:
>>> On Fri, Oct 07, 2016 at 07:00:26AM -0400, John Ferlan wrote:
 Add an optional "tls='yes'" option for a TCP chardev for the
 express purpose to enable setting up TLS for the chardev. This
 will assume that the qemu.conf settings have been adjusted as
 well as the environment configured properly.

 Signed-off-by: John Ferlan 
 ---
  docs/formatdomain.html.in  | 21 +
  docs/schemas/domaincommon.rng  |  5 +++
  src/conf/domain_conf.c | 22 +-
  src/conf/domain_conf.h |  1 +
  src/qemu/qemu_command.c|  3 +-
  src/qemu/qemu_hotplug.c|  3 +-
  ...emuxml2argv-serial-tcp-tlsx509-chardev-tls.args | 30 +
  ...qemuxml2argv-serial-tcp-tlsx509-chardev-tls.xml | 50 
 ++
  .../qemuxml2argv-serial-tcp-tlsx509-chardev.xml|  2 +-
  tests/qemuxml2argvtest.c   |  3 ++
  ...muxml2xmlout-serial-tcp-tlsx509-chardev-tls.xml |  1 +
  .../qemuxml2xmlout-serial-tcp-tlsx509-chardev.xml  |  2 +-
  tests/qemuxml2xmltest.c|  1 +
  13 files changed, 139 insertions(+), 5 deletions(-)
  create mode 100644 
 tests/qemuxml2argvdata/qemuxml2argv-serial-tcp-tlsx509-chardev-tls.args
  create mode 100644 
 tests/qemuxml2argvdata/qemuxml2argv-serial-tcp-tlsx509-chardev-tls.xml
  create mode 12 
 tests/qemuxml2xmloutdata/qemuxml2xmlout-serial-tcp-tlsx509-chardev-tls.xml

 diff --git a/docs/formatdomain.html.in b/docs/formatdomain.html.in
 index 1266e9d..010530e 100644
 --- a/docs/formatdomain.html.in
 +++ b/docs/formatdomain.html.in
 @@ -6203,6 +6203,27 @@ qemu-kvm -net nic,model=? /dev/null
/devices
...
  
 +
 +  Since 2.4.0, some hypervisors support 
 using
 +  a TLS X.509 certificate environment in order to encrypt all serial 
 TCP
 +  connections via a hypervisor configuration option. In order to 
 enable
 +  TLS for the domain an optional attribute tls can be 
 set to
 +  "yes". Combined with the hypervisor's capability to utilize the TLS
 +  environment allows for the character device to use the encrypted
 +  communication. If the attribute is not present, then the default
 +  setting is "no".
>>>
>>> This is not correct in case of QEMU.  Before this patch the default was 
>>> based on
>>> chardev_tls from qemu.conf.  After this patch the default will be "no" even 
>>> if
>>> you set chardev_tls=1 and that breaks behavior of libvirt.  The test case
>>> "serial-tcp-tlsx509-chardev-tls" where you had to add tls="yes" should also 
>>> work
>>> without this change.
>>>
>>> This patch needs to be modified to take chardev_tls=1 in account and add 
>>> tests
>>> to make sure that we don't break it in the future.
>>>
>>
>> This change was in response to v5 (and v6) review comments from Daniel :
>>
>> v5: http://www.redhat.com/archives/libvir-list/2016-September/msg00294.html
>>
>> v6: http://www.redhat.com/archives/libvir-list/2016-September/msg00317.html
>>
>> I read those review requests as we need a way to be able to disable TLS
>> on a chardev on a domain by domain and even chardev by chardev basis
>> rather than it being the default enabled for every domain and every
>> chardev in the domain.
>>
>> Could you elaborate how it breaks the behavior of libvirt?  Currently a
>> chardev doesn't have any TLS attribute - that qemu.conf change is from
>> already agreed upon changes. This set of changes should have been able
>> to go with those, but they've languished on the least through a release
>> cycle (2.3.0), so while it may appear that something is one way - it in
>> a way isn't.  Right now it's just pixie/fairy dust and a pipe dream.
> 
> The thing is that with libvirt-2.3.0 you can set chardev_tls=1 in qemu.conf 
> and
> therefore all chardevs for all domains uses TLS to encrypt communication.  
> This
> patch introduces a new 'tls' attribute and its default value is 'no' and that
> means if the user upgrades from libvirt-2.3.0 to libvirt-2.4.0 all chardevs 
> stop
> encrypting communication unless he sets tls="yes" for every single chardev in
> every single domain.


UGH... mea culpa - in my mind the TLS hadn't been added to the chardev
yet and that was the rest of this series...  Of course the rest of this
series is adding the passphrase for the environment ().

If I could have got that review earlier, then this situation wouldn't be
a problem (see in my mind it wasn't).

If a domain is already running, then encryption is occurring and this
setting has no effect 

Re: [libvirt] Qemu: create empty cdrom

2016-10-14 Thread Stefan Hajnoczi
On Fri, Feb 5, 2016 at 2:56 PM, Gromak Yuriy  wrote:
> Qemu is latest from master branch.
> Tryingto start a domain, which is connected toa blankcdrom:
>
> 
>   
>   
>   
>   
> 
>
> But I get an error:
>
> qemu-system-x86_64: -drive
> if=none,id=drive-scsi0-0-1-0,readonly=on,format=raw: Can't use 'raw' as a
> block driver for the protocol level.

Mathieu hit the same problem with a QEMU 2.6 backport for Debian
jessie.  His libvirt version is based on 1.2.9.

QEMU began printing this error starting from version 2.6.0.

I think newer libvirt versions have compensated.  There is no error
when I use Mathieu's domain XML with libvirt based on 1.3.3 (Fedora
24).

Looks like you need a modern libvirt to run against a modern QEMU.

Stefan

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list


Re: [libvirt] [PATCH 7/8] qemu: Support newer ivshmem device variants

2016-10-14 Thread John Ferlan
[...]

>>> +char *
>>> +qemuBuildShmemDevStr(virDomainDefPtr def,
>>> + virDomainShmemDefPtr shmem,
>>> + virQEMUCapsPtr qemuCaps)
>>> +{
>>> +virBuffer buf = VIR_BUFFER_INITIALIZER;
>>> +
>>> +virBufferAsprintf(, "%s",
>>> virDomainShmemModelTypeToString(shmem->model));
>>> +virBufferAsprintf(, ",id=%s", shmem->info.alias);
>>> +
>>> +if (shmem->server.enabled)
>>> +virBufferAsprintf(, ",chardev=char%s", shmem->info.alias);
>>> +else
>>> +virBufferAsprintf(, ",memdev=shmmem-%s",
>>> shmem->info.alias);
>>> +
>>> +if (shmem->msi.vectors)
>>> +virBufferAsprintf(, ",vectors=%u", shmem->msi.vectors);
>>> +if (shmem->msi.ioeventfd) {
>>> +virBufferAsprintf(, ",ioeventfd=%s",
>>> + 
>>> virTristateSwitchTypeToString(shmem->msi.ioeventfd));
>>> +}
>>> +
>>> +if (qemuBuildDeviceAddressStr(, def, >info, qemuCaps)
>>> < 0) {
>>> +virBufferFreeAndReset();
>>> +return NULL;
>>> +}
>>> +
>>> +if (virBufferCheckError() < 0)
>>
>> Still would need to FreeAndReset - I'd be OK if it were an || to the
>> previous if, although I know that causes agita for others.
>>
> 
> Well, not really.  The content gets free()'d whenever the buf->error is
> set, so it is already cleared if there was an error.
> 

That's not how I read/see other callers of virBufferCheckError and I see
no free in virBufferCheckErrorInternal


John

[...]

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list


Re: [libvirt] [PATCH 8/8] qemu: Add support for hot/cold-(un)plug of shmem devices

2016-10-14 Thread Martin Kletzander

On Fri, Oct 14, 2016 at 10:25:26AM -0400, John Ferlan wrote:


[...]



+int
+qemuDomainDetachShmemDevice(virQEMUDriverPtr driver,
+virDomainObjPtr vm,
+virDomainDeviceDefPtr dev)
+{
+int ret = -1;
+ssize_t idx = -1;
+virErrorPtr orig_err = NULL;
+virDomainShmemDefPtr shmem = NULL;
+qemuDomainObjPrivatePtr priv = vm->privateData;
+
+if ((idx = virDomainShmemDefFind(vm->def, dev->data.shmem) < 0)) {
+virReportError(VIR_ERR_OPERATION_INVALID, "%s",
+   _("device not present in domain
configuration"));
+return -1;
+}
+
+shmem = vm->def->shmems[idx];
+
+switch ((virDomainShmemModel)shmem->model) {
+case VIR_DOMAIN_SHMEM_MODEL_IVSHMEM_PLAIN:
+case VIR_DOMAIN_SHMEM_MODEL_IVSHMEM_DOORBELL:
+break;
+
+case VIR_DOMAIN_SHMEM_MODEL_IVSHMEM:
+virReportError(VIR_ERR_OPERATION_UNSUPPORTED,
+   _("live detach of shmem model '%s' is not
supported"),
+   virDomainShmemModelTypeToString(shmem->model));
+/* fall-through */
+case VIR_DOMAIN_SHMEM_MODEL_LAST:
+return -1;
+}
+
+qemuDomainMarkDeviceForRemoval(vm, >info);
+qemuDomainObjEnterMonitor(driver, vm);
+
+ret = qemuMonitorDelDevice(priv->mon, shmem->info.alias);
+
+if (ret < 0)
+orig_err = virSaveLastError();
+
+if (qemuDomainObjExitMonitor(driver, vm) < 0)
+ret = -1;
+
+if (ret == 0) {
+if ((ret = qemuDomainWaitForDeviceRemoval(vm)) == 1) {
+qemuDomainReleaseDeviceAddress(vm, >info, NULL);
+ret = qemuDomainRemoveDevice(driver, vm, dev);


Why not a direct qemuDomainRemoveShmemDevice(driver, vm, shmem);

It's the pattern other code uses - just concern over the difference - it
does result in the same call eventually.



What other code?  It doesn't necessarily result in the same call every
time.  That's what qemuDomainWaitForDeviceRemoval() is for.  We
shouldn't remove it from the definition if QEMU didn't actually remove
it.



Most callers to qemuDomainWaitForDeviceRemoval except
qemuDomainDetachChrDevice which throws in release device address, but
still calls its RemoveChrDevice directly rather than the generic
RemoveDevice call.



Oh, I misunderstood that, you meant qemuDomainRemoveShmemDevice() instead
of qemuDomainRemoveDevice().  Yes, I can do that, I left the Device
there because I was using the actual device for something in one of the
versions before posting it and then haven't changed it back.


John


signature.asc
Description: Digital signature
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

[libvirt] [PATCH 0/4] qemuBuildHostNetStr cleanups

2016-10-14 Thread Ján Tomko
This is not a blurb.

Ján Tomko (4):
  qemuBuildHostNetStr: use type_sep earlier
  qemuBuildHostNetStr: do not start options with a comma
  qemuBuildHostNetStr: move stray VIR_DOMAIN_NET_TYPE_INTERNAL
  qemuBuildHostNetStr: remove dead code

 src/qemu/qemu_command.c | 49 +
 1 file changed, 21 insertions(+), 28 deletions(-)

-- 
2.7.3

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

[libvirt] [PATCH 2/4] qemuBuildHostNetStr: do not start options with a comma

2016-10-14 Thread Ján Tomko
Put the comma at the end and trim it later for consistency.
---
 src/qemu/qemu_command.c | 15 ---
 1 file changed, 8 insertions(+), 7 deletions(-)

diff --git a/src/qemu/qemu_command.c b/src/qemu/qemu_command.c
index eba7ba9..80ebe51 100644
--- a/src/qemu/qemu_command.c
+++ b/src/qemu/qemu_command.c
@@ -3742,19 +3742,18 @@ qemuBuildHostNetStr(virDomainNetDefPtr net,
 }
 
 if (vlan >= 0) {
-virBufferAsprintf(, "vlan=%d", vlan);
+virBufferAsprintf(, "vlan=%d,", vlan);
 if (net->info.alias)
-virBufferAsprintf(, ",name=host%s",
-  net->info.alias);
+virBufferAsprintf(, "name=host%s,", net->info.alias);
 } else {
-virBufferAsprintf(, "id=host%s", net->info.alias);
+virBufferAsprintf(, "id=host%s,", net->info.alias);
 }
 
 if (is_tap) {
 if (vhostfdSize) {
-virBufferAddLit(, ",vhost=on,");
+virBufferAddLit(, "vhost=on,");
 if (vhostfdSize == 1) {
-virBufferAsprintf(, "vhostfd=%s", vhostfd[0]);
+virBufferAsprintf(, "vhostfd=%s,", vhostfd[0]);
 } else {
 virBufferAddLit(, "vhostfds=");
 for (i = 0; i < vhostfdSize; i++) {
@@ -3762,14 +3761,16 @@ qemuBuildHostNetStr(virDomainNetDefPtr net,
 virBufferAddChar(, ':');
 virBufferAdd(, vhostfd[i], -1);
 }
+virBufferAddChar(, ',');
 }
 }
 if (net->tune.sndbuf_specified)
-virBufferAsprintf(, ",sndbuf=%lu", net->tune.sndbuf);
+virBufferAsprintf(, "sndbuf=%lu,", net->tune.sndbuf);
 }
 
 virObjectUnref(cfg);
 
+virBufferTrim(, ",", -1);
 if (virBufferCheckError() < 0)
 return NULL;
 
-- 
2.7.3

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list


[libvirt] [PATCH 3/4] qemuBuildHostNetStr: move stray VIR_DOMAIN_NET_TYPE_INTERNAL

2016-10-14 Thread Ján Tomko
This network type is only used by the vbox driver and it does not
make sense to group it with VIR_DOMAIN_NET_TYPE_USER.

Introduced by commit 1dcbef8.
---
 src/qemu/qemu_command.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/src/qemu/qemu_command.c b/src/qemu/qemu_command.c
index 80ebe51..19ee652 100644
--- a/src/qemu/qemu_command.c
+++ b/src/qemu/qemu_command.c
@@ -3719,7 +3719,6 @@ qemuBuildHostNetStr(virDomainNetDefPtr net,
 break;
 
 case VIR_DOMAIN_NET_TYPE_USER:
-case VIR_DOMAIN_NET_TYPE_INTERNAL:
 virBufferAsprintf(, "user%c", type_sep);
 break;
 
@@ -3737,6 +3736,8 @@ qemuBuildHostNetStr(virDomainNetDefPtr net,
   net->driver.virtio.queues);
 break;
 
+case VIR_DOMAIN_NET_TYPE_INTERNAL:
+/* Not supported by QEMU driver */
 case VIR_DOMAIN_NET_TYPE_LAST:
 break;
 }
-- 
2.7.3

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list


[libvirt] [PATCH 1/4] qemuBuildHostNetStr: use type_sep earlier

2016-10-14 Thread Ján Tomko
When hotplugging networks with ancient QEMUs not supporting
QEMU_CAPS_NETDEV, we use space instead of a comma as the separator
between the network type and other options.

Except for "user", all the network types pass other options
and use up the first separator by the time we get to the section
that adds the alias (or vlan for QEMUs without CAPS_NETDEV).

Since the alias/vlan is mandatory, convert all preceding code to add
the separator at the end, removing the need to rewrite type_sep for
all types but NET_TYPE_USER.
---
 src/qemu/qemu_command.c | 28 +++-
 1 file changed, 11 insertions(+), 17 deletions(-)

diff --git a/src/qemu/qemu_command.c b/src/qemu/qemu_command.c
index 21fd85c..eba7ba9 100644
--- a/src/qemu/qemu_command.c
+++ b/src/qemu/qemu_command.c
@@ -3674,7 +3674,7 @@ qemuBuildHostNetStr(virDomainNetDefPtr net,
 /* for one tapfd 'fd=' shall be used,
  * for more than one 'fds=' is the right choice */
 if (tapfdSize == 1) {
-virBufferAsprintf(, "fd=%s", tapfd[0]);
+virBufferAsprintf(, "fd=%s,", tapfd[0]);
 } else {
 virBufferAddLit(, "fds=");
 for (i = 0; i < tapfdSize; i++) {
@@ -3682,49 +3682,45 @@ qemuBuildHostNetStr(virDomainNetDefPtr net,
 virBufferAddChar(, ':');
 virBufferAdd(, tapfd[i], -1);
 }
+virBufferAddChar(, ',');
 }
-type_sep = ',';
 is_tap = true;
 break;
 
 case VIR_DOMAIN_NET_TYPE_CLIENT:
-virBufferAsprintf(, "socket%cconnect=%s:%d",
+virBufferAsprintf(, "socket%cconnect=%s:%d,",
   type_sep,
   net->data.socket.address,
   net->data.socket.port);
-type_sep = ',';
 break;
 
 case VIR_DOMAIN_NET_TYPE_SERVER:
-virBufferAsprintf(, "socket%clisten=%s:%d",
+virBufferAsprintf(, "socket%clisten=%s:%d,",
   type_sep,
   net->data.socket.address ? net->data.socket.address
   : "",
   net->data.socket.port);
-type_sep = ',';
 break;
 
 case VIR_DOMAIN_NET_TYPE_MCAST:
-virBufferAsprintf(, "socket%cmcast=%s:%d",
+virBufferAsprintf(, "socket%cmcast=%s:%d,",
   type_sep,
   net->data.socket.address,
   net->data.socket.port);
-type_sep = ',';
 break;
 
 case VIR_DOMAIN_NET_TYPE_UDP:
-virBufferAsprintf(, "socket%cudp=%s:%d,localaddr=%s:%d",
+virBufferAsprintf(, "socket%cudp=%s:%d,localaddr=%s:%d,",
   type_sep,
   net->data.socket.address,
   net->data.socket.port,
   net->data.socket.localaddr,
   net->data.socket.localport);
-type_sep = ',';
 break;
 
 case VIR_DOMAIN_NET_TYPE_USER:
 case VIR_DOMAIN_NET_TYPE_INTERNAL:
-virBufferAddLit(, "user");
+virBufferAsprintf(, "user%c", type_sep);
 break;
 
 case VIR_DOMAIN_NET_TYPE_HOSTDEV:
@@ -3733,12 +3729,11 @@ qemuBuildHostNetStr(virDomainNetDefPtr net,
 return NULL;
 
 case VIR_DOMAIN_NET_TYPE_VHOSTUSER:
-virBufferAsprintf(, "vhost-user%cchardev=char%s",
+virBufferAsprintf(, "vhost-user%cchardev=char%s,",
   type_sep,
   net->info.alias);
-type_sep = ',';
 if (net->driver.virtio.queues > 1)
-virBufferAsprintf(, ",queues=%u",
+virBufferAsprintf(, "queues=%u,",
   net->driver.virtio.queues);
 break;
 
@@ -3747,13 +3742,12 @@ qemuBuildHostNetStr(virDomainNetDefPtr net,
 }
 
 if (vlan >= 0) {
-virBufferAsprintf(, "%cvlan=%d", type_sep, vlan);
+virBufferAsprintf(, "vlan=%d", vlan);
 if (net->info.alias)
 virBufferAsprintf(, ",name=host%s",
   net->info.alias);
 } else {
-virBufferAsprintf(, "%cid=host%s",
-  type_sep, net->info.alias);
+virBufferAsprintf(, "id=host%s", net->info.alias);
 }
 
 if (is_tap) {
-- 
2.7.3

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list


[libvirt] [PATCH 4/4] qemuBuildHostNetStr: remove dead code

2016-10-14 Thread Ján Tomko
This function is never called for VIR_DOMAIN_NET_TYPE_HOSTDEV,
and the dead code comment agrees.

Introduced by commit 1dcbef8a.
---
 src/qemu/qemu_command.c | 7 ++-
 1 file changed, 2 insertions(+), 5 deletions(-)

diff --git a/src/qemu/qemu_command.c b/src/qemu/qemu_command.c
index 19ee652..adeb906 100644
--- a/src/qemu/qemu_command.c
+++ b/src/qemu/qemu_command.c
@@ -3722,11 +3722,6 @@ qemuBuildHostNetStr(virDomainNetDefPtr net,
 virBufferAsprintf(, "user%c", type_sep);
 break;
 
-case VIR_DOMAIN_NET_TYPE_HOSTDEV:
-/* Should have been handled earlier via PCI/USB hotplug code. */
-virObjectUnref(cfg);
-return NULL;
-
 case VIR_DOMAIN_NET_TYPE_VHOSTUSER:
 virBufferAsprintf(, "vhost-user%cchardev=char%s,",
   type_sep,
@@ -3736,6 +3731,8 @@ qemuBuildHostNetStr(virDomainNetDefPtr net,
   net->driver.virtio.queues);
 break;
 
+case VIR_DOMAIN_NET_TYPE_HOSTDEV:
+/* Should have been handled earlier via PCI/USB hotplug code. */
 case VIR_DOMAIN_NET_TYPE_INTERNAL:
 /* Not supported by QEMU driver */
 case VIR_DOMAIN_NET_TYPE_LAST:
-- 
2.7.3

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list


Re: [libvirt] [PATCH 8/8] qemu: Add support for hot/cold-(un)plug of shmem devices

2016-10-14 Thread John Ferlan

[...]


>>> +int
>>> +qemuDomainDetachShmemDevice(virQEMUDriverPtr driver,
>>> +virDomainObjPtr vm,
>>> +virDomainDeviceDefPtr dev)
>>> +{
>>> +int ret = -1;
>>> +ssize_t idx = -1;
>>> +virErrorPtr orig_err = NULL;
>>> +virDomainShmemDefPtr shmem = NULL;
>>> +qemuDomainObjPrivatePtr priv = vm->privateData;
>>> +
>>> +if ((idx = virDomainShmemDefFind(vm->def, dev->data.shmem) < 0)) {
>>> +virReportError(VIR_ERR_OPERATION_INVALID, "%s",
>>> +   _("device not present in domain
>>> configuration"));
>>> +return -1;
>>> +}
>>> +
>>> +shmem = vm->def->shmems[idx];
>>> +
>>> +switch ((virDomainShmemModel)shmem->model) {
>>> +case VIR_DOMAIN_SHMEM_MODEL_IVSHMEM_PLAIN:
>>> +case VIR_DOMAIN_SHMEM_MODEL_IVSHMEM_DOORBELL:
>>> +break;
>>> +
>>> +case VIR_DOMAIN_SHMEM_MODEL_IVSHMEM:
>>> +virReportError(VIR_ERR_OPERATION_UNSUPPORTED,
>>> +   _("live detach of shmem model '%s' is not
>>> supported"),
>>> +   virDomainShmemModelTypeToString(shmem->model));
>>> +/* fall-through */
>>> +case VIR_DOMAIN_SHMEM_MODEL_LAST:
>>> +return -1;
>>> +}
>>> +
>>> +qemuDomainMarkDeviceForRemoval(vm, >info);
>>> +qemuDomainObjEnterMonitor(driver, vm);
>>> +
>>> +ret = qemuMonitorDelDevice(priv->mon, shmem->info.alias);
>>> +
>>> +if (ret < 0)
>>> +orig_err = virSaveLastError();
>>> +
>>> +if (qemuDomainObjExitMonitor(driver, vm) < 0)
>>> +ret = -1;
>>> +
>>> +if (ret == 0) {
>>> +if ((ret = qemuDomainWaitForDeviceRemoval(vm)) == 1) {
>>> +qemuDomainReleaseDeviceAddress(vm, >info, NULL);
>>> +ret = qemuDomainRemoveDevice(driver, vm, dev);
>>
>> Why not a direct qemuDomainRemoveShmemDevice(driver, vm, shmem);
>>
>> It's the pattern other code uses - just concern over the difference - it
>> does result in the same call eventually.
>>
> 
> What other code?  It doesn't necessarily result in the same call every
> time.  That's what qemuDomainWaitForDeviceRemoval() is for.  We
> shouldn't remove it from the definition if QEMU didn't actually remove
> it.
> 

Most callers to qemuDomainWaitForDeviceRemoval except
qemuDomainDetachChrDevice which throws in release device address, but
still calls its RemoveChrDevice directly rather than the generic
RemoveDevice call.

John

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list


Re: [libvirt] [PATCH v8 2/5] conf: Introduce {default|chardev}_tls_x509_secret_uuid

2016-10-14 Thread Pavel Hrdina
On Fri, Oct 07, 2016 at 07:00:27AM -0400, John Ferlan wrote:
> Add a new qemu.conf variables to store the UUID for the secret that could
> be used to present credentials to access the TLS chardev.  Since this will
> be a server level and it's possible to use some sort of default, introduce
> both the default and chardev logic at the same time making the setting of
> the chardev check for it's own value, then if not present checking whether
> the default value had been set.
> 
> The chardevTLSx509haveUUID bool will be used as the marker for whether
> the chardevTLSx509secretUUID was successfully read. In the future this
> is how it'd determined whether to add the secret object for a TLS object.
> 
> Signed-off-by: John Ferlan 
> ---
>  src/qemu/libvirtd_qemu.aug |  2 ++
>  src/qemu/qemu.conf | 24 
>  src/qemu/qemu_conf.c   | 22 ++
>  src/qemu/qemu_conf.h   |  3 +++
>  src/qemu/test_libvirtd_qemu.aug.in |  2 ++
>  5 files changed, 53 insertions(+)
> 
> diff --git a/src/qemu/libvirtd_qemu.aug b/src/qemu/libvirtd_qemu.aug
> index 988201e..73ebeda 100644
> --- a/src/qemu/libvirtd_qemu.aug
> +++ b/src/qemu/libvirtd_qemu.aug
> @@ -29,6 +29,7 @@ module Libvirtd_qemu =
> (* Config entry grouped by function - same order as example config *)
> let default_tls_entry = str_entry "default_tls_x509_cert_dir"
>   | bool_entry "default_tls_x509_verify"
> + | str_entry "default_tls_x509_secret_uuid"
>  
> let vnc_entry = str_entry "vnc_listen"
>   | bool_entry "vnc_auto_unix_socket"
> @@ -51,6 +52,7 @@ module Libvirtd_qemu =
> let chardev_entry = bool_entry "chardev_tls"
>   | str_entry "chardev_tls_x509_cert_dir"
>   | bool_entry "chardev_tls_x509_verify"
> + | str_entry "chardev_tls_x509_secret_uuid"
>  
> let nogfx_entry = bool_entry "nographics_allow_host_audio"
>  
> diff --git a/src/qemu/qemu.conf b/src/qemu/qemu.conf
> index e4c2aae..f136fa9 100644
> --- a/src/qemu/qemu.conf
> +++ b/src/qemu/qemu.conf
> @@ -28,6 +28,20 @@
>  #
>  #default_tls_x509_verify = 1
>  
> +#
> +# Libvirt assumes the server-key.pem file is unencrypted by default.
> +# To use an encrypted server-key.pem file, the password to decrypt the

s/ the//

> +# the PEM file is requird. This can be provided by creating a secret
> +# object in libvirt and then uncommenting this setting to set the UUID
> +# UUID of the secret.
> +#
> +# NB This default all-zeros UUID will not work. Replace it with the
> +# output from the UUID for the TLS secret from a 'virsh secret-list'
> +# command and then uncomment the entry
> +#
> +#default_tls_x509_secret_uuid = "----"
> +
> +
>  # VNC is configured to listen on 127.0.0.1 by default.
>  # To make it listen on all public interfaces, uncomment
>  # this next option.
> @@ -214,6 +228,16 @@
>  #chardev_tls_x509_verify = 1
>  
>  
> +# Uncomment and use the following option to override the default secret
> +# uuid provided in the default_tls_x509_secret_uuid parameter.
> +#
> +# NB This default all-zeros UUID will not work. Replace it with the
> +# output from the UUID for the TLS secret from a 'virsh secret-list'
> +# command and then uncomment the entry
> +#
> +#chardev_tls_x509_secret_uuid = "----"
> +
> +
>  # By default, if no graphical front end is configured, libvirt will disable
>  # QEMU audio output since directly talking to alsa/pulseaudio may not work
>  # with various security settings. If you know what you're doing, enable
> diff --git a/src/qemu/qemu_conf.c b/src/qemu/qemu_conf.c
> index 635fa27..c650961 100644
> --- a/src/qemu/qemu_conf.c
> +++ b/src/qemu/qemu_conf.c
> @@ -365,6 +365,7 @@ static void virQEMUDriverConfigDispose(void *obj)
>  VIR_FREE(cfg->nvramDir);
>  
>  VIR_FREE(cfg->defaultTLSx509certdir);
> +VIR_FREE(cfg->defaultTLSx509secretUUID);
>  
>  VIR_FREE(cfg->vncTLSx509certdir);
>  VIR_FREE(cfg->vncListen);
> @@ -377,6 +378,7 @@ static void virQEMUDriverConfigDispose(void *obj)
>  VIR_FREE(cfg->spiceSASLdir);
>  
>  VIR_FREE(cfg->chardevTLSx509certdir);
> +VIR_FREE(cfg->chardevTLSx509secretUUID);
>  
>  while (cfg->nhugetlbfs) {
>  cfg->nhugetlbfs--;
> @@ -424,6 +426,7 @@ int virQEMUDriverConfigLoadFile(virQEMUDriverConfigPtr 
> cfg,
>  int ret = -1;
>  int rv;
>  size_t i, j;
> +bool defaultTLSx509haveUUID;
>  char *stdioHandler = NULL;
>  char *user = NULL, *group = NULL;
>  char **controllers = NULL;
> @@ -446,6 +449,12 @@ int virQEMUDriverConfigLoadFile(virQEMUDriverConfigPtr 
> cfg,
>  goto cleanup;
>  if (virConfGetValueBool(conf, "default_tls_x509_verify", 
> >defaultTLSx509verify) < 0)
>  goto cleanup;
> +if ((rv = virConfGetValueString(conf, "default_tls_x509_secret_uuid",
> + 

Re: [libvirt] [PATCH 7/8] qemu: Support newer ivshmem device variants

2016-10-14 Thread Martin Kletzander

On Fri, Oct 14, 2016 at 10:19:58AM -0400, John Ferlan wrote:

[...]


+char *
+qemuBuildShmemDevStr(virDomainDefPtr def,
+ virDomainShmemDefPtr shmem,
+ virQEMUCapsPtr qemuCaps)
+{
+virBuffer buf = VIR_BUFFER_INITIALIZER;
+
+virBufferAsprintf(, "%s",
virDomainShmemModelTypeToString(shmem->model));
+virBufferAsprintf(, ",id=%s", shmem->info.alias);
+
+if (shmem->server.enabled)
+virBufferAsprintf(, ",chardev=char%s", shmem->info.alias);
+else
+virBufferAsprintf(, ",memdev=shmmem-%s",
shmem->info.alias);
+
+if (shmem->msi.vectors)
+virBufferAsprintf(, ",vectors=%u", shmem->msi.vectors);
+if (shmem->msi.ioeventfd) {
+virBufferAsprintf(, ",ioeventfd=%s",
+
virTristateSwitchTypeToString(shmem->msi.ioeventfd));
+}
+
+if (qemuBuildDeviceAddressStr(, def, >info, qemuCaps)
< 0) {
+virBufferFreeAndReset();
+return NULL;
+}
+
+if (virBufferCheckError() < 0)


Still would need to FreeAndReset - I'd be OK if it were an || to the
previous if, although I know that causes agita for others.



Well, not really.  The content gets free()'d whenever the buf->error is
set, so it is already cleared if there was an error.



That's not how I read/see other callers of virBufferCheckError and I see
no free in virBufferCheckErrorInternal



It's free()'d when it is *set*, see virBufferSetError (the only place in
virbuffer.c that sets the ->error member).



John

[...]


signature.asc
Description: Digital signature
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [PATCH rfc v2 0/8] fspool: backend directory

2016-10-14 Thread Olga Krishtal

On 14/10/16 16:15, John Ferlan wrote:

[...]


I have written this lines as a part of  GPLv2+ boilerplate:
https://www.redhat.com/archives/libvir-list/2016-August/msg01160.html,
which I took from
other libvirt parts. And I guess it was naturally to change name and
company, don't you?
And again, if you insist I can leave out the author/copyright as it
wasn't the aim of this series.

Indeed, storage pool is very similar to FS pool but their items are not
- volumes (block devices)
versus filesystems (directory trees). And intention here was to
introduce a *new API*, which is
also very different from storage pool one, effectivly introducing a new
driver. As driver
boundaries crossing isn't favored, the code was simply borrowed,
following earlier practice used
by libvirt to get new drivers implemented.

John, keeping all said above in mind, do you think it's worth trying to
reuse common code while
introducing a new API? It won't allow us to leave existing code
untouched and it will increase the
series even more.
  

Sorry - just haven't been able to keep up with my work and all the
activity on this list lately.

Here's my point - if you find yourself copying a function from one
driver to another for the express purpose that you cannot cross driver
boundaries, then perhaps your first thought should be - can the copied
code can go in an existing or a new src/util/vir*.c file and be used in
both places. I think there are synergies in the existing code...


Then, I guess, the first think that I should  do - src/util/vir*.c for
both drivers. I try to do it in the next version.


Another thought that occurs to me - I cannot recall if it's been
mentioned in this context or not (short term memory isn't what it used
to be!). IIUC the model is to use these trees more for containers, then
I would hope the security is "built in" very tightly rather than being
an added on after thought. One particularly thorny area is NFS storage
pools (and well directory trees) especially w/r/t root_squash or not. In
any case, I can only imagine that for container consumers - being "held"
to certain security rules will be very important.


Good point, thanks! I need some time to think it over.



One final thought, if the existing 'storage driver' is for BLOCK storage
and this new driver is a 'File System Storage Driver', then rather than
using 'fspool' (which is really confusing IMO) maybe the base driver is
"fs_storage". So that means we create a "src/fs_storage" and start from
there.  The 'fs' was just not descriptive enough.


I agree.


Since it's a File System Storage Driver that's essentially exposing
entire directories, is there really a need for a "pool" concept? Isn't
the driver providing that alone? IOW: The implementation is a pool.
What else other than a directory would something like this expose? Is
there something else that could be envisioned that would add to the
(from patch 1) virFSItemType?


For directory fspool item object may seem meaningless, however
for zfs and  virtuozzo storage, I think, it doesn't: pool can be 
mounted, can

have some restrictions and items is the object that is exposed to costumer.
I mean for zfs - we create pool, than create filesystems with different 
quotas, etc.
For Virtuozzo storage - the entity that is exposed - is cluster. The 
administrator
manipulations - is to mount cluster, and users are able to create items 
for their needs.





John

Oh and please let's not drop 12K lines of new code into one series -
please!  Rome wasn't built in a day and certainly it's very hard to
commit the time to review 12K lines of code in one series. A logical
progression to the finish line is fine.


I will split this series.




[...]



--
Best regards,
Olga

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list


Re: [libvirt] [PATCH] util: Alter return value of virReadFCHost and fix mem leak

2016-10-14 Thread Erik Skultety
> >> VIR_FREE() would have to be done at the top of the function; otherwise,
> >> how does the caller distinguish which error occurred when -1 gets
> >> returned and whether it should VIR_FREE itself?
> >>
> > 
> > Well, I have to admin that this^^ is a fair argument because there are 3
> > different spots where the function can fail, not that the caller could not
> > check result for NULL but the fact that a function touched caller's argument
> > and then failed would be just weird. So, yeah, good point.
> > 
> I actually thought this was the "more compelling" reason, but seeing as
> there's no other feedback - I'll make the simple patch for having the
> VIR_FREE() in virReadFCHost, adjust the comments, and move on.
> 
> John
> 

Hi John, I think I admitted that you had a very good point (the one on top) so
I thought you would actually push your original version, I'm sorry if I wasn't
clear enough with my statement.

Erik


signature.asc
Description: PGP signature
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [PATCH v3 15/18] qemu: auto-add pcie-root-port/dmi-to-pci-bridge controllers as needed

2016-10-14 Thread Laine Stump

On 10/14/2016 01:20 PM, Andrea Bolognani wrote:

On Thu, 2016-10-13 at 13:43 -0400, Laine Stump wrote:

+if (nbuses > 0 && !addrs->buses[0].model) {
+if (virDomainPCIAddressBusSetModel(>buses[0],
+   VIR_DOMAIN_CONTROLLER_MODEL_PCI_ROOT) 
< 0)
+goto error;
+}

Shouldn't we use either PCI_ROOT or PCIE_ROOT based on the

machine type here? And set hasPCIeRoot *after* doing so?

Sorry for the questions, I guess this is the point in the
patch where I got a bit lost :(
  
I'm afraid you missed this question :)
  
Sorry about the omission.  I've tried to limit the code that decides

whether or not there should be a pci-root or a pcie-root to the one
place when default controllers are being added (I forget the name of the
function right now),

I guess you mean qemuDomainDefAddDefaultDevices()?

That's the function where pci{,e}-root is added, if not
already present in the configuration.


and after that only decide based on whether a
pci-root or pcie-root really is there in the config. My subconscious
reasoning for this is that the extra calisthenics around supporting
aarch64/virt with PCI(e) vs with mmio has made me wonder if there might
be machinetypes in the future that could support one type of root bus or
another (or none) according to what is in the config, rather than having
a root bus just builtin to the machine. I don't know if that would ever
happen, but if it did, this code would work without change - only the
function adding the default controllers would need to be changed.
  
(Note that I used the same logic when deciding how to right

qemuDomainMachineHasPCI[e]Root())(still not sure about that name, but it
can always be changed later to remove the "Machine" if someone doesn't
like it)

That makes sense.

My point is that the code above, if I'm reading it correctly,
sets the model of bus 0 to PCI_ROOT if it's not already set.

But

   1) qemuDomainDefAddDefaultDevices() mentioned above should
  already have added pci{,e}-root to @def

   2) if that's not the case, we should use either PCI_ROOT
  or PCIE_ROOT based on what's appropriate for the machine
  type

Looking at the code in qemuDomainDefAddDefaultDevices() it
seems like we would never find ourselves in the situation
where pci{,e}-root is needed but not present in @def by the
time qemuDomainPCIAddressSetCreate() is called, so I think
that chunk of code should just be removed.


Truthfully the only reason it's there at all is because there was 
similar code originally (which also was surely never needed). Even so, 
I'm nervous about totally removing the check for unset model even though 
a visual inspection of the current code tells us it won't be needed. So 
instead, I'm going to turn it into an internal error condition.


--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list


Re: [libvirt] [PATCH v3 15/18] qemu: auto-add pcie-root-port/dmi-to-pci-bridge controllers as needed

2016-10-14 Thread Andrea Bolognani
On Thu, 2016-10-13 at 13:43 -0400, Laine Stump wrote:
> > > > > +if (nbuses > 0 && !addrs->buses[0].model) {
> > > > > +if
(virDomainPCIAddressBusSetModel(>buses[0],
> > > > > +   
> > > > > VIR_DOMAIN_CONTROLLER_MODEL_PCI_ROOT) < 0)
> > > > >
+goto error;
> > > > > +}
> > > >   
> > > > Shouldn't we use either PCI_ROOT or PCIE_ROOT based on the
> > > > machine type here? And set
hasPCIeRoot *after* doing so?
> > > >   
> > > > Sorry for the questions, I guess this is the point in the
> > > > patch where I got a bit lost :(
> > 
> > I'm
afraid you missed this question :)
> 
> Sorry about the omission.  I've tried to limit the code that decides 
> whether or not there should be a pci-root or a
pcie-root to the one 
> place when default controllers are being added (I forget the name of the 
> function right now),

I guess you mean qemuDomainDefAddDefaultDevices()?

That's the function where pci{,e}-root is added, if not
already present in the configuration.

> and after that only decide based on whether a 
> pci-root or pcie-root really is there in the config. My subconscious 
> reasoning for this is that the extra calisthenics around supporting 
> aarch64/virt with PCI(e) vs with mmio has made me wonder if there might 
> be machinetypes in the future that could support one type of root bus or 
> another (or none) according to what is in the config, rather than having 
> a root bus just builtin to the machine. I don't know if that would ever 
> happen, but if it did, this code would work without change - only the 
> function adding the default controllers would need to be changed.
> 
> (Note that I used the same logic when deciding how to right 
> qemuDomainMachineHasPCI[e]Root())(still not sure about that name, but it 
> can always be changed later to remove the "Machine" if someone doesn't 
> like it)

That makes sense.

My point is that the code above, if I'm reading it correctly,
sets the model of bus 0 to PCI_ROOT if it's not already set.

But

  1) qemuDomainDefAddDefaultDevices() mentioned above should
 already have added pci{,e}-root to @def

  2) if that's not the case, we should use either PCI_ROOT
 or PCIE_ROOT based on what's appropriate for the machine
 type

Looking at the code in qemuDomainDefAddDefaultDevices() it
seems like we would never find ourselves in the situation
where pci{,e}-root is needed but not present in @def by the
time qemuDomainPCIAddressSetCreate() is called, so I think
that chunk of code should just be removed.

> > > > A DMI-to-PCI bridge with index='1' has been added
> > > > automatically here...
> > > >   
> > > > ... but it's not being used by any of the devices. So why
> > > > would it be added in the first place?
> > > 
> > > That is a *very* good question!
> 
> > Can't wait to know the answer! ;)
> 
> Oh, now that I've looked in context of the patch ordering, I undestand: 
> it's because patch 16/18 hasn't been applied yet. I'd forgotten the 
> ordering...

Right you are :)

-- 
Andrea Bolognani / Red Hat / Virtualization

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [PATCH v3 19/18] [RFC] qemu: assure there are always at least 4 open pcie-root-ports for hotplug

2016-10-14 Thread Andrea Bolognani
On Thu, 2016-09-29 at 15:20 -0400, Laine Stump wrote:
> In the absense of anything configurable, we will need to pick a number
> though. I've done that here, and now we can argue about it (or not :-)

Ján raised an interesting point: whatever number we choose,
no matter how wrong doing so is, some user or application
will end up relying on us providing at least that many
hotpluggable ports, so there's no going back.

For that reason, I would recommend leaving just a single
empty hotpluggable port for now, and raise the number in
the future if we find out that one's definitely not enough.

-- 
Andrea Bolognani / Red Hat / Virtualization

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

[libvirt] [PATCH] libxl: fix leaking of allocated migration ports

2016-10-14 Thread Jim Fehlig
Although the migration port is immediately released in the
finish phase of migration, it was never set in the domain
private object when allocated in the prepare phase. So
libxlDomainMigrationFinish() always released a 0-initialized
migrationPort, leaking any allocated port. After enough
migrations to exhaust the migration port pool, migration would
fail with

error: internal error: Unable to find an unused port in range
   'migration' (49152-49216)

Fix it by setting libxlDomainObjPrivate->migrationPort to the
port allocated in the prepare phase. While at it, also fix
leaking an allocated port if the prepare phase fails.

Signed-off-by: Jim Fehlig 
---
 src/libxl/libxl_migration.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/src/libxl/libxl_migration.c b/src/libxl/libxl_migration.c
index 534abb8..a471d2a 100644
--- a/src/libxl/libxl_migration.c
+++ b/src/libxl/libxl_migration.c
@@ -594,6 +594,7 @@ libxlDomainMigrationPrepare(virConnectPtr dconn,
 if (virPortAllocatorAcquire(driver->migrationPorts, ) < 0)
 goto error;
 
+priv->migrationPort = port;
 if (virAsprintf(uri_out, "tcp://%s:%d", hostname, port) < 0)
 goto error;
 } else {
@@ -628,6 +629,7 @@ libxlDomainMigrationPrepare(virConnectPtr dconn,
 if (virPortAllocatorAcquire(driver->migrationPorts, ) < 0)
 goto error;
 
+priv->migrationPort = port;
 } else {
 port = uri->port;
 }
@@ -690,6 +692,8 @@ libxlDomainMigrationPrepare(virConnectPtr dconn,
 }
 VIR_FREE(socks);
 virObjectUnref(args);
+virPortAllocatorRelease(driver->migrationPorts, priv->migrationPort);
+priv->migrationPort = 0;
 
 /* Remove virDomainObj from domain list */
 if (vm) {
-- 
2.9.2

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list


Re: [libvirt] [PATCH] conf: Explain some code in more detail

2016-10-14 Thread Laine Stump

On 10/13/2016 11:44 AM, Andrea Bolognani wrote:

The code is entirely correct, but it still managed to trip me
up when I first ran into it because I did not realize right away
that VIR_PCI_CONNECT_TYPES_ENDPOINT was not a single flag, but
rather a mask including both VIR_PCI_CONNECT_TYPE_PCI_DEVICE and
VIR_PCI_CONNECT_TYPE_PCIE_DEVICE.

In order to save the next distracted traveler in PCI Address Land
some time, document this fact with a comment. Add a test case for
the behavior as well.


Yes. Thank you. ACK. etc.


---
  src/conf/domain_addr.c |  4 +-
  .../qemuxml2argv-q35-pci-force-address.args| 25 +++
  .../qemuxml2argv-q35-pci-force-address.xml | 32 +++
  tests/qemuxml2argvtest.c   |  7 
  .../qemuxml2xmlout-q35-pci-force-address.xml   | 48 ++
  tests/qemuxml2xmltest.c|  7 
  6 files changed, 122 insertions(+), 1 deletion(-)
  create mode 100644 
tests/qemuxml2argvdata/qemuxml2argv-q35-pci-force-address.args
  create mode 100644 
tests/qemuxml2argvdata/qemuxml2argv-q35-pci-force-address.xml
  create mode 100644 
tests/qemuxml2xmloutdata/qemuxml2xmlout-q35-pci-force-address.xml

diff --git a/src/conf/domain_addr.c b/src/conf/domain_addr.c
index 0406b50..bbeb611 100644
--- a/src/conf/domain_addr.c
+++ b/src/conf/domain_addr.c
@@ -100,7 +100,9 @@ virDomainPCIAddressFlagsCompatible(virPCIDeviceAddressPtr 
addr,
  if (fromConfig) {
  /* If the requested connection was manually specified in
   * config, allow a PCI device to connect to a PCIe slot, or
- * vice versa.
+ * vice versa. In order to do so, we add *both* the PCI_DEVICE
+ * and the PCIE_DEVICE flags to the bus if it already has either
+ * of them, using the ENDPOINT mask.
   */
  if (busFlags & VIR_PCI_CONNECT_TYPES_ENDPOINT)
  busFlags |= VIR_PCI_CONNECT_TYPES_ENDPOINT;
diff --git a/tests/qemuxml2argvdata/qemuxml2argv-q35-pci-force-address.args 
b/tests/qemuxml2argvdata/qemuxml2argv-q35-pci-force-address.args
new file mode 100644
index 000..9ca342b
--- /dev/null
+++ b/tests/qemuxml2argvdata/qemuxml2argv-q35-pci-force-address.args
@@ -0,0 +1,25 @@
+LC_ALL=C \
+PATH=/bin \
+HOME=/home/test \
+USER=test \
+LOGNAME=test \
+QEMU_AUDIO_DRV=none \
+/usr/libexec/qemu-kvm \
+-name q35-test \
+-S \
+-M q35 \
+-m 2048 \
+-smp 2,sockets=2,cores=1,threads=1 \
+-uuid 11dbdcdd-4c3b-482b-8903-9bdb8c0a2774 \
+-nographic \
+-nodefaults \
+-monitor unix:/tmp/lib/domain--1-q35-test/monitor.sock,server,nowait \
+-no-acpi \
+-boot c \
+-device i82801b11-bridge,id=pci.1,bus=pcie.0,addr=0x1e \
+-device pci-bridge,chassis_nr=2,id=pci.2,bus=pci.1,addr=0x0 \
+-device ioh3420,port=0x10,chassis=3,id=pci.3,bus=pcie.0,addr=0x2 \
+-device e1000e,vlan=0,id=net0,mac=52:54:00:aa:bf:ef,bus=pci.2,addr=0x1 \
+-net user,vlan=0,name=hostnet0 \
+-device intel-hda,id=sound0,bus=pci.3,addr=0x0 \
+-device hda-duplex,id=sound0-codec0,bus=sound0.0,cad=0
diff --git a/tests/qemuxml2argvdata/qemuxml2argv-q35-pci-force-address.xml 
b/tests/qemuxml2argvdata/qemuxml2argv-q35-pci-force-address.xml
new file mode 100644
index 000..34ec7c7
--- /dev/null
+++ b/tests/qemuxml2argvdata/qemuxml2argv-q35-pci-force-address.xml
@@ -0,0 +1,32 @@
+
+  q35-test
+  11dbdcdd-4c3b-482b-8903-9bdb8c0a2774
+  2097152
+  2097152
+  2
+  
+hvm
+
+  
+  
+  destroy
+  restart
+  destroy
+  
+/usr/libexec/qemu-kvm
+
+
+
+
+
+  
+
+
+  
+  
+  
+
+
+
+  
+
diff --git a/tests/qemuxml2argvtest.c b/tests/qemuxml2argvtest.c
index b996182..fc18317 100644
--- a/tests/qemuxml2argvtest.c
+++ b/tests/qemuxml2argvtest.c
@@ -1749,6 +1749,13 @@ mymain(void)
  QEMU_CAPS_ICH9_AHCI,
  QEMU_CAPS_PCI_MULTIFUNCTION, QEMU_CAPS_ICH9_USB_EHCI1,
  QEMU_CAPS_NEC_USB_XHCI);
+/* Make sure the user can always override libvirt's default device
+ * placement policy by providing an explicit PCI address */
+DO_TEST("q35-pci-force-address",
+QEMU_CAPS_DEVICE_PCI_BRIDGE,
+QEMU_CAPS_DEVICE_DMI_TO_PCI_BRIDGE,
+QEMU_CAPS_DEVICE_IOH3420,
+QEMU_CAPS_HDA_DUPLEX);
  
  DO_TEST_PARSE_ERROR("q35-wrong-root",

  QEMU_CAPS_DEVICE_PCI_BRIDGE,
diff --git a/tests/qemuxml2xmloutdata/qemuxml2xmlout-q35-pci-force-address.xml 
b/tests/qemuxml2xmloutdata/qemuxml2xmlout-q35-pci-force-address.xml
new file mode 100644
index 000..c0332d4
--- /dev/null
+++ b/tests/qemuxml2xmloutdata/qemuxml2xmlout-q35-pci-force-address.xml
@@ -0,0 +1,48 @@
+
+  q35-test
+  11dbdcdd-4c3b-482b-8903-9bdb8c0a2774
+  2097152
+  2097152
+  2
+  
+hvm
+
+  
+  
+  destroy
+  restart
+  destroy
+  
+/usr/libexec/qemu-kvm
+
+
+  
+  
+
+
+  
+  
+  
+
+
+  
+  
+  
+
+
+
+  
+
+
+  
+  
+   

Re: [libvirt] [PATCH v8 1/5] domain: Add optional 'tls' attribute for TCP chardev

2016-10-14 Thread John Ferlan


On 10/14/2016 11:30 AM, Pavel Hrdina wrote:
> On Fri, Oct 14, 2016 at 10:58:12AM -0400, John Ferlan wrote:
>> [...]

 UGH... mea culpa - in my mind the TLS hadn't been added to the chardev
 yet and that was the rest of this series...  Of course the rest of this
 series is adding the passphrase for the environment ().

 If I could have got that review earlier, then this situation wouldn't be
 a problem (see in my mind it wasn't).

 If a domain is already running, then encryption is occurring and this
 setting has no effect except for hotplug.

 If we were using encryption in 2.3.0... stopped our domain... installed
 2.4.0... started our domain, then yes, I see/agree  Frustrating
 since there's really no "simple" way to determine this.

>
> The correct solution is:
>
> - if chardev_tls is set to 1 and tls attribute is not configured in 
> the XML
> the default after starting the domain should be tls=yes

 So IOW:

 +if (cfg->chardevTLS &&
 +dev->data.tcp.haveTLS == VIR_TRISTATE_BOOL_YES) {

 changes to

 +if (cfg->chardevTLS &&
 +dev->data.tcp.haveTLS != VIR_TRISTATE_BOOL_NO) {

 or (haveTLS == YES || haveTLS == ABSENT)

 This of course is essentially the logic from v6 which said disableTLS on
 a case by case basis All we have now is the positive form...

 So for both qemuBuildChrChardevStr and qemuDomainAttachChrDevice I'd
 have a similar change.  Does that suffice and do you need to see the 
 change?
>>>
>>> I think that we should reflect the state in live XML if the attribute 
>>> exists.
>>>
>>> Add a code to qemuProcessPrepareDomain() that will set dev->data.tcp.haveTLS
>>> to config value if dev->data.tcp.haveTLS == VIR_TRISTATE_BOOL_ABSENT and in
>>> qemuBuildChrChardevStr() you can just check if
>>> dev->data.tcp.haveTLS == VIR_TRISTATE_BOOL_YES.  This will also ensure that
>>> the live XML contains the 'tls' attribute.  But make sure, that migration 
>>> works
>>> properly for all combinations.
>>>
>>
>> I don't see the advantage... Altering the running domain would involve
> 
> The advantage is in case when the chardevTLS is set but the offline XML 
> doesn't
> have 'tls' attribute configured.  If the domain is started than it's perfectly
> clear from the live XML that the tls is enabled or not.
> 

Maybe I didn't explain it well enough... I don't see the advantage of
modifying qemuProcessPrepareDomain or qemuProcessAttach to try and
determine whether we should "enable" this property. I see no need to
introspect to inspect a setting in order to then make some assumption
whether the property should be enabled or not. We'll get ourselves in
trouble doing so. Too much complexity, too much danger for making a bad
assumption or decision.


I went back to the v5 review and reconsidered Dan's review points:

1. "As default behaviour I think it is desirable that we can turn TLS on
for every VM at once - I tend to view it as a host network integration
task, rather than a VM configuration task. Same rationale that we use
for TLS wth VNC/SPICE."

2. "There's no reason we can't have a tri-state TLS flag against the
chardev in the XML too, to override the default behaviour of
cfg->chardevTLS"


>From which I generated a v6 to "Add an optional "disableTLS='yes'"
option"... For which Dan points out:

"Can we just call this "tls=yes|no" - negative attributes (disableFOO)
are kind of ugly IMHO, as they imply that the default status is
enabled, which is not really the case - the default is hypervisor
specific and undefined."

So, now there's a v7 which adds "tls='yes|no'", where the default is no
and OK quite rightfully in hindsight is not what was originally
requested.  That's left unchanged into this v8 until you call it out.

So where does that leave me - well the "tls='yes|no'" property still
should exist. What changes is that rather than "enforcing" that it gets
set to "yes" in order to make something work that worked before without
doing so, the default should be that whatever is in qemu.conf takes
priority unless someone adds "tls='no'" to the chardev entry.

That's what I'll change things to and document in a soon to be posted v9.



>> messing in qemuProcessAttach and setting the attribute for the domain if
>> chardevTLS is set *BUT* how do we know without a bit of introspection if
>> that domain was started with TLS and is using TLS? (IOW: looking at the
>> running domain for tls-creds-x509). Additionally, someone could have
> 
> Well, we do that introspection and we must do it to properly detect what has
> been used to start that domain.  The domain XML should reflect the current 
> state
> as closely as possible.
> 
>> changed the chardevTLS setting in qemu.conf after the domain was
>> initially started and thus it wouldn't have it, so setting it blindly
> 
> Yes, someone can change the