November 2016 - Devel - libvirt List Archives

Re: [libvirt] [Qemu-ppc] [RFC PATCH qemu] spapr_pci: Create PCI-express root bus by default
by Andrea Bolognani 19 Dec '16

19 Dec '16

On Tue, 2016-11-01 at 13:46 +1100, David Gibson wrote: > On Mon, Oct 31, 2016 at 03:10:23PM +1100, Alexey Kardashevskiy wrote: > > > > On 31/10/16 13:53, David Gibson wrote: > > > > > > On Fri, Oct 28, 2016 at 12:07:12PM +0200, Greg Kurz wrote: > > > > > > > > On Fri, 28 Oct 2016 18:56:40 +1100 > > > > Alexey Kardashevskiy <aik(a)ozlabs.ru> wrote: > > > > > > > > > > > > > > At the moment sPAPR PHB creates a root buf of TYPE_PCI_BUS type. > > > > > This means that vfio-pci devices attached to it (and this is > > > > > a default behaviour) hide PCIe extended capabilities as > > > > > the bus does not pass a pci_bus_is_express(pdev->bus) check. > > > > > > > > > > This changes adds a default PCI bus type property to sPAPR PHB > > > > > and uses TYPE_PCIE_BUS if none passed; older machines get TYPE_PCI_BUS > > > > > for backward compatibility as a bus type is used in the bus name > > > > > so the root bus name becomes "pcie.0" instead of "pci.0". > > > > > > > > > > Signed-off-by: Alexey Kardashevskiy <aik(a)ozlabs.ru> > > > > > --- > > > > > > > > > > What can possibly go wrong with such change of a name? > > > > > From devices prospective, I cannot see any. > > > > > > > > > > libvirt might get upset as "pci.0" will not be available, > > > > > will it make sense to create pcie.0 as a root bus and always > > > > > add a PCIe->PCI bridge and name its bus "pci.0"? > > > > > > > > > > Or create root bus from TYPE_PCIE_BUS and force name to "pci.0"? > > > > > pci_register_bus() can do this. > > > > > > > > > > > > > > > --- > > > > > hw/ppc/spapr.c | 5 +++++ > > > > > hw/ppc/spapr_pci.c | 5 ++++- > > > > > include/hw/pci-host/spapr.h | 1 + > > > > > 3 files changed, 10 insertions(+), 1 deletion(-) > > > > > > > > > > diff --git a/hw/ppc/spapr.c b/hw/ppc/spapr.c > > > > > index 0b3820b..a268511 100644 > > > > > --- a/hw/ppc/spapr.c > > > > > +++ b/hw/ppc/spapr.c > > > > > @@ -2541,6 +2541,11 @@ DEFINE_SPAPR_MACHINE(2_8, "2.8", true); > > > > > .driver = TYPE_SPAPR_PCI_HOST_BRIDGE, \ > > > > > .property = "mem64_win_size", \ > > > > > .value = "0", \ > > > > > + }, \ > > > > > + { \ > > > > > + .driver = TYPE_SPAPR_PCI_HOST_BRIDGE, \ > > > > > + .property = "root_bus_type", \ > > > > > + .value = TYPE_PCI_BUS, \ > > > > > }, > > > > > > > > > > static void phb_placement_2_7(sPAPRMachineState *spapr, uint32_t index, > > > > > diff --git a/hw/ppc/spapr_pci.c b/hw/ppc/spapr_pci.c > > > > > index 7cde30e..2fa1f22 100644 > > > > > --- a/hw/ppc/spapr_pci.c > > > > > +++ b/hw/ppc/spapr_pci.c > > > > > @@ -1434,7 +1434,9 @@ static void spapr_phb_realize(DeviceState *dev, Error **errp) > > > > > bus = pci_register_bus(dev, NULL, > > > > > pci_spapr_set_irq, pci_spapr_map_irq, sphb, > > > > > &sphb->memspace, &sphb->iospace, > > > > > - PCI_DEVFN(0, 0), PCI_NUM_PINS, TYPE_PCI_BUS); > > > > > + PCI_DEVFN(0, 0), PCI_NUM_PINS, > > > > > + sphb->root_bus_type ? sphb->root_bus_type : > > > > > + TYPE_PCIE_BUS); > > > > > > > > Shouldn't we ensure that sphb->root_bus_type is either TYPE_PCIE_BUS or > > > > TYPE_PCI_BUS ? > > > > > > Yes, I think so. In fact, I think it would be better to make the > > > property a boolean that just selects PCI-E, rather than this which > > > exposes qemu (semi-)internal type names on the comamnd line. > > > > Sure, a "pcie-root" boolean property should do. > > > > However this is not my main concern, I rather wonder if we have to have > > pci.0 when we pick PCIe for the root. > > Right. > > I've added Andrea Bologna to the CC list to get a libvirt perspective. Thanks for doing so: changes such as this one can have quite an impact on the upper layers of the stack, so the earliest libvirt is involved in the discussion the better. I'm going to go a step further and cross-post to libvir-list in order to give other libvirt contributors a chance to chime in too. > Andrea, > > To summarise the issue here: > * As I've said before the PAPR spec kinda-sorta abstracts the > difference between vanilla PCI and PCI-E > * However, because within qemu we're declaring the bus as PCI that > means some PCI-E devices aren't working right > * In particular it means that PCI-E extended config space isn't > available > > The proposal is to change (on newer machine types) the spapr PHB code > to declare a PCI-E bus instead. AIUI this still won't make the root > complex guest visible (which it's not supposed to be under PAPR), and > the guest shouldn't see a difference in most cases - it will still see > the PAPR abstracted PCIish bus, but will now be able to get extended > config space. > > The possible problem from a libvirt perspective is that doing this in > the simplest way in qemu would change the name of the default bus from > pci.0 to pcie.0. We have two suggested ways to mitigate this: > 1) Automatically create a PCI-E to PCI bridge, so that new machine > types will have both a pcie.0 and pci.0 bus > 2) Force the name of the bus to be pci.0, even though it's treated > as PCI-E in other ways. > > We're trying to work out exactly what will and won't cause trouble for > libvirt. Option 2) is definitely a no-no, as we don't want to be piling up even more hacks and architecture-specific code: the PCI Express Root Bus should be called pcie.0, just as it is on q35 and mach-virt machine types. Option 1) doesn't look too bad, but devices that are added automatically by QEMU are an issue since we need to hardcode knowledge of them into libvirt if we want the rest of the PCI address allocation logic to handle them correctly. Moreover libvirt now has the ability of building a legacy PCI topology without user intervention, if needed to plug in legacy devices, on machines that have a PCI Express Root Bus, which makes the additional bridge fully redundant... ... or at least it would, if we actually had a proper PCIe-to-PCI bridge; AFAIK, though, the closest we have is the i82801b11-bridge that is Intel-specific despite having so far been abused as a generic PCIe-to-PCI bridge. I'm not even sure whether it would work at all on ppc64. Moving from legacy PCI to PCI Express would definitely be an improvement, in my opinion. As mentioned, that's already the case for at least two other architectures, so the more we can standardize on that, the better. That said, considering that a big part of the PCI address allocation logic is based off whether the specific machine type exposes a legay PCI Root Bus or a PCI Express Root Bus, libvirt will need a way to be able to tell which one is which. Version checks are pretty much out of the question, as they fail as soon as downstream releases enter the picture. A few ways we could deal with the situation: 1) switch to PCI Express on newer machine types, and expose some sort of capability through QMP so that libvirt can know about the switch 2) switch between legacy PCI and PCI Express based on a machine type option. libvirt would be able to find out whether the option is available or not, and default to either <controller type='pci' model='pci-root'/> or <controller type='pci' model='pcie-root'/> based on that. In order to support multiple PHBs properly, those would have to be switchable with an option as well 3) create an entirely new machine type, eg. pseries-pcie or whatever someone with the ability to come up with decent names can suggest :) That would make ppc64 similar to x86, where i440fx and q35 have different root buses. libvirt would learn about the new machine type, know that it has a PCI Express Root Bus, and behave accordingly Option 1) would break horribly with existing libvirt versions, and so would Option 2) if we default to using PCI Express. Option 2) with default to legacy PCI and option 3) would work just fine with existing libvirt versions AFAICT, but wouldn't of course expose the new capabilities. Option 3) is probably the one that will be less confusing to users; we might even decide to take the chance and fix other small annoyances with the current pseries machine type, if there's any. On the other hand, it might very well be considered to be too big a hammer for such a small nail. -- Andrea Bolognani / Red Hat / Virtualization

9 32

[libvirt] [PATCH v2 00/10] admin: Introduce runtime logging APIs
by Erik Skultety 15 Dec '16

15 Dec '16

v1 here https://www.redhat.com/archives/libvir-list/2016-November/msg00009.html since v1: - incorporated notes raised during review - allowed passing of NULL via the public APIs * behaves the same way as an empty string, but lead to even more code reduction in 'daemonSetupLogging' for practically no extra code to enable such feature - added forgotten documentation - updated NEWS file Erik Skultety (10): virlog: Introduce virLog{Get,Set}DefaultOutput admin: Allow passing NULL to virLogSetFilters daemon: Hook up the virLog{Get,Set}DefaultOutput to the daemon's init routine admin: Introduce virAdmConnectGetLoggingOutputs admin: Introduce virAdmConnectGetLoggingFilters admin: Introduce virAdmConnectSetLoggingOutputs admin: Introduce virAdmConnectSetLoggingFilters virt-admin: Wire-up the logging APIs admin: Add an example demonstrating how to use the logging APIs admin: Update the news file to include the new logging features .gitignore | 1 + daemon/admin.c | 104 ++++++++++++++++++++++++++ daemon/libvirtd.c | 96 ++++-------------------- docs/news.html.in | 4 + examples/Makefile.am | 3 +- examples/admin/logging.c | 102 ++++++++++++++++++++++++++ include/libvirt/libvirt-admin.h | 16 ++++ src/admin/admin_protocol.x | 50 ++++++++++++- src/admin/admin_remote.c | 70 ++++++++++++++++++ src/admin_protocol-structs | 26 +++++++ src/libvirt-admin.c | 157 ++++++++++++++++++++++++++++++++++++++++ src/libvirt_admin_private.syms | 6 ++ src/libvirt_admin_public.syms | 8 ++ src/libvirt_private.syms | 2 + src/locking/lock_daemon.c | 90 ++++------------------- src/logging/log_daemon.c | 92 ++++------------------- src/util/virlog.c | 100 ++++++++++++++++++++++++- src/util/virlog.h | 4 +- tools/virt-admin.c | 120 ++++++++++++++++++++++++++++++ tools/virt-admin.pod | 90 +++++++++++++++++++++++ 20 files changed, 899 insertions(+), 242 deletions(-) create mode 100644 examples/admin/logging.c -- 2.5.5

2 29

[libvirt] [PATCH 0/2] qemu_cgroup: allow access to /dev/dri/render*
by Ján Tomko 14 Dec '16

14 Dec '16

Technically a v2, but v1 is already pushed. This version is based on the <gl enable> in <spice> instead of accel3d="yes" in <video><model type="virtio". It also only allows access to the render* devices, instead of all of them. https://bugzilla.redhat.com/show_bug.cgi?id=1337290 Ján Tomko (2): Revert "qemu_cgroup: allow access to /dev/dri for virtio-vga" qemu_cgroup: allow access to /dev/dri/render* src/qemu/qemu_cgroup.c | 71 ++++++++++++++++++++++++++++++++++++++++---------- 1 file changed, 57 insertions(+), 14 deletions(-) -- 2.7.3

6 17

[libvirt] [PATCH v5 0/2] List only online cpus for vcpupin/emulatorpin when vcpu placement static
by Nitesh Konkar 14 Dec '16

14 Dec '16

Currently when the vcpu placement is static and cpuset is not specified, CPU Affinity shows 0.. CPUMAX. This patchset will result in display of only online CPU's under CPU Affinity on linux. Fixes the following Bug: virsh dumpxml Fedora <domain type='kvm' id='4'> <name>Fedora</name> <uuid>aecf3e5e-6f9a-42a3-9d6a-223a75569a66</uuid> <maxMemory slots='32' unit='KiB'>3145728</maxMemory> <memory unit='KiB'>524288</memory> <currentMemory unit='KiB'>524288</currentMemory> <vcpu placement='static' current='8'>160</vcpu> <resource> <partition>/machine</partition> </resource> ..................... ....................... ......................... <memballoon model='virtio'> <alias name='balloon0'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x06' function='0x0'/> </memballoon> </devices> <seclabel type='dynamic' model='dac' relabel='yes'> <label>+0:+0</label> <imagelabel>+0:+0</imagelabel> </seclabel> </domain> lscpu Architecture: x86_64 CPU op-mode(s): 32-bit, 64-bit Byte Order: Little Endian CPU(s): 8 On-line CPU(s) list: 0-2,4-7 Off-line CPU(s) list: 3 Thread(s) per core: 1 Core(s) per socket: 7 Socket(s): 1 .......... .......... NUMA node0 CPU(s): 0-2,4-7 NUMA node1 CPU(s): cat /sys/devices/system/cpu/online 0-2,4-7 Before Patch virsh vcpupin Fedora VCPU: CPU Affinity ---------------------------------- 0: 0-7 1: 0-7 ... ... 158: 0-7 159: 0-7 virsh emulatorpin Fedora emulator: CPU Affinity ---------------------------------- *: 0-7 After Patch virsh vcpupin Fedora VCPU: CPU Affinity ---------------------------------- 0: 0-2,4-7 1: 0-2,4-7 ... ... 158: 0-2,4-7 159: 0-2,4-7 virsh emulatorpin Fedora emulator: CPU Affinity ---------------------------------- *: 0-2,4-7 Nitesh Konkar (2): conf: List only online cpus for virsh vcpupin conf: List only online cpus for virsh emulatorpin src/conf/domain_conf.c | 6 ++++++ src/qemu/qemu_driver.c | 5 +++++ 2 files changed, 11 insertions(+) -- 2.1.0

3 5

[libvirt] [PATCH V3 0/2] Allow hot plugged host CPUs
by Viktor Mihajlovski 14 Dec '16

14 Dec '16

This is a rework of the original patch allowing to use all host CPUs if the cpuset controller is not configured by libvirt. The major enhancement is that we won't try to retrieve the online host CPU map on platforms where this is not supported and just fall back to the old behavior. V3: - Added new function (in seperate patch) to find out whether the host CPU online map can be retrieved gracefully V2: - Avoid memory leak Viktor Mihajlovski (2): util: Allow to query the presence of host CPU bitmaps qemu: Allow use of hot plugged host CPUs if no affinity set src/libvirt_private.syms | 1 + src/qemu/qemu_process.c | 33 ++++++++++++++++++++++++--------- src/util/virhostcpu.c | 10 ++++++++++ src/util/virhostcpu.h | 1 + 4 files changed, 36 insertions(+), 9 deletions(-) -- 1.9.1

3 7

[libvirt] [PATCH 0/3] qemu: fix racy paths in agent related code
by Nikolay Shirokovskiy 12 Dec '16

12 Dec '16

Patch 1 is a nitpick I found when working on Patch 2. Patch 2 and 3 fix a couple of race conditions in code. A lot of changes is inherent refactorings in Patch 2 actually. Nikolay Shirokovskiy (3): qemu: agent: fix uninitialized var case in qemuAgentGetFSInfo qemu: don't use vmdef without domain lock qemu: agent: take monitor lock in qemuAgentNotifyEvent src/qemu/qemu_agent.c | 57 +++++++++++++-------- src/qemu/qemu_agent.h | 25 ++++++++- src/qemu/qemu_driver.c | 88 +++++++++++++++++++++++++++++++- tests/Makefile.am | 1 - tests/qemuagentdata/qemuagent-fsinfo.xml | 39 -------------- tests/qemuagenttest.c | 47 +++++++---------- 6 files changed, 164 insertions(+), 93 deletions(-) delete mode 100644 tests/qemuagentdata/qemuagent-fsinfo.xml -- 1.8.3.1

2 13

[libvirt] dpdk/vpp and cross-version migration for vhost
by Michael S. Tsirkin 09 Dec '16

09 Dec '16

Hi! So it looks like we face a problem with cross-version migration when using vhost. It's not new but became more acute with the advent of vhost user. For users to be able to migrate between different versions of the hypervisor the interface exposed to guests by hypervisor must stay unchanged. The problem is that a qemu device is connected to a backend in another process, so the interface exposed to guests depends on the capabilities of that process. Specifically, for vhost user interface based on virtio, this includes the "host features" bitmap that defines the interface, as well as more host values such as the max ring size. Adding new features/changing values to this interface is required to make progress, but on the other hand we need ability to get the old host features to be compatible. To solve this problem within qemu, qemu has a versioning system based on a machine type concept which fundamentally is a version string, by specifying that string one can get hardware compatible with a previous qemu version. QEMU also reports the latest version and list of versions supported so libvirt records the version at VM creation and then is careful to use this machine version whenever it migrates a VM. One might wonder how is this solved with a kernel vhost backend. The answer is that it mostly isn't - instead an assumption is made, that qemu versions are deployed together with the kernel - this is generally true for downstreams. Thus whenever qemu gains a new feature, it is already supported by the kernel as well. However, if one attempts migration with a new qemu from a system with a new to old kernel, one would get a failure. In the world where we have multiple userspace backends, with some of these supplied by ISVs, this seems non-realistic. IMO we need to support vhost backend versioning, ideally in a way that will also work for vhost kernel backends. So I'd like to get some input from both backend and management developers on what a good solution would look like. If we want to emulate the qemu solution, this involves adding the concept of interface versions to dpdk. For example, dpdk could supply a file (or utility printing?) with list of versions: latest and versions supported. libvirt could read that and - store latest version at vm creation - pass it around with the vm - pass it to qemu >From here, qemu could pass this over the vhost-user channel, thus making sure it's initialized with the correct compatible interface. As version here is an opaque string for libvirt and qemu, anything can be used - but I suggest either a list of values defining the interface, e.g. any_layout=on,max_ring=256 or a version including the name and vendor of the backend, e.g. "org.dpdk.v4.5.6". Note that typically the list of supported versions can only be extended, not shrunk. Also, if the host/guest interface does not change, don't change the current version as this just creates work for everyone. Thoughts? Would this work well for management? dpdk? vpp? Thanks! -- MST

8 21

[libvirt] [PATCH 0/3] qemu: bugfixes for websocket port in graphics
by Nikolay Shirokovskiy 09 Dec '16

09 Dec '16

Patch 1 is a preparation for patch 2. Patch 3 particularly fixes next 2 cases: == A. Can not restore domain with autoconfigured websocket. domain 1 and 2 have autoconfigured websocket. 1. domain 1 is started then, saved 2. domain 2 is started 3. domain 1 restoration is failed: error: internal error: qemu unexpectedly closed the monitor: 2016-11-21T10:23:11.356687Z qemu-kvm: -vnc 0.0.0.0:2,websocket=5700: Failed to start VNC server on `(null)': Failed to bind socket: Address already in use == B. Can not migrate domain with autoconfigured websocket. domain 1 on host A, domain 2 on host B, both have autoconfigured websocket 1. domain 1 started, domain 2 started 2. domain 1 migration to host B is failed with the above error. Nikolay Shirokovskiy (3): qemu: refactor: use switch for enum in qemuProcessGraphicsReservePorts qemu: mark user defined websocket as used qemu: fix xml dump of autogenerated websocket src/conf/domain_conf.c | 5 ++++- src/conf/domain_conf.h | 1 + src/qemu/qemu_process.c | 45 ++++++++++++++++++++++++++++++++++++--------- 3 files changed, 41 insertions(+), 10 deletions(-) -- 1.8.3.1

2 14

[libvirt] RFC: add recreate option to domain events conf
by Nikolay Shirokovskiy 09 Dec '16

09 Dec '16

Hi, all. Does it make sense to anybody else that rebooting and resetting a persistent domain from outside or from inside should bring upon pending configuration changes? For this purpose we can add another option to on_reboot and other events, say 'recreate'. From technical POV qemu has enough capabilities, namely -no-reboot option. Nikolay

1 1

[libvirt] [PATCH v3 0/4] Gathering network interface statistics with openvswitch
by Mehdi Abaakouk 09 Dec '16

09 Dec '16

This new version removes the virstat.c from locale configuration. It also adds a new commit to autodected the ifname of the ovs vhostuser. Mehdi Abaakouk (4): Gathering vhostuser interface stats with ovs virstat: fix signature of virstat helper Move virstat.c code to virnetdevtap.c domain_conf: autodetect vhostuser ifname po/POTFILES.in | 1 - src/Makefile.am | 1 - src/conf/domain_conf.c | 10 +++ src/libvirt_private.syms | 5 +- src/libxl/libxl_driver.c | 4 +- src/lxc/lxc_driver.c | 3 +- src/openvz/openvz_driver.c | 4 +- src/qemu/qemu_driver.c | 31 +++++-- src/uml/uml_driver.c | 1 - src/util/virnetdevopenvswitch.c | 106 ++++++++++++++++++++++++ src/util/virnetdevopenvswitch.h | 4 + src/util/virnetdevtap.c | 143 ++++++++++++++++++++++++++++++++ src/util/virnetdevtap.h | 3 + src/util/virstats.c | 178 ---------------------------------------- src/util/virstats.h | 31 ------- src/xen/xen_hypervisor.c | 4 +- 16 files changed, 298 insertions(+), 231 deletions(-) delete mode 100644 src/util/virstats.c delete mode 100644 src/util/virstats.h -- 2.10.2

2 14