Re: [libvirt] [PATCH v2] qemu: Assign device address before qemuDomainSupportsNicdev

ping. > qemuDomainSupportsNicdev will check the device address type on > aarch64. If it is invoked before device address assigned, hotadd > vhostuser interface with no address specified will get error. > Let qemuDomainEnsurePCIAddress run before qemuDomainSupportsNicdev. > > Signed-off-by: Wang

[libvirt] [PULL 03/44] hw/misc/ivshmem: Remove deprecated "ivshmem" legacy device

From: Thomas Huth It's been marked as deprecated in QEMU v2.6.0 already, so really nobody should use the legacy "ivshmem" device anymore (but use ivshmem-plain or ivshmem-doorbell instead). Time to remove the deprecated device now. Belatedly also update a mention of the deprecated "ivshmem" in

[libvirt] [PATCH 0/2] apparmor: support named profiles

Upstream apparmor is switching to named profiles. Many profiles have already made the switch. Patch 1 changes the libvirtd profile to account for dnsmasq's switch to a named profile. Patch 2 is optional and changes the libvirtd profile to a named profile. It will need a bit of coorindation with

[libvirt] [PATCH 2/2] apparmor: convert libvirtd profile to a named profile

Signed-off-by: Jim Fehlig --- Optional patch that may need a bit of coorindation with upstream apparmor since the dnsmasq profile currently has 'peer=/usr/sbin/libvirtd'. src/security/apparmor/usr.sbin.libvirtd | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git

[libvirt] [PATCH 1/2] apparmor: Add support for named profiles

Upstream apparmor is switching to named profiles. In short, /usr/sbin/dnsmasq { becomes profile dnsmasq /usr/sbin/dnsmasq { Consequently, any profiles that reference profiles in a peer= condition need to be updated if the referenced profile switches to a named profile. Apparmor commit 9ab45d81

Re: [libvirt] [PATCH for 5.0.0] qemu: Temporary disable owner remembering

On Mon, Jan 14, 2019 at 06:01:24PM +0100, Peter Krempa wrote: > On Mon, Jan 14, 2019 at 17:57:39 +0100, Michal Privoznik wrote: > > Turns out, that there are few bugs that are not that trivial to > > fix (e.g. around block jobs). Instead of rushing in not > > thoroughly tested fixes disable the

Re: [libvirt] [PATCH for 5.0.0] qemu: Temporary disable owner remembering

On Mon, Jan 14, 2019 at 17:57:39 +0100, Michal Privoznik wrote: > Turns out, that there are few bugs that are not that trivial to > fix (e.g. around block jobs). Instead of rushing in not > thoroughly tested fixes disable the feature temporarily for the > release. > > Signed-off-by: Michal

[libvirt] [PATCH for 5.0.0] qemu: Temporary disable owner remembering

Turns out, that there are few bugs that are not that trivial to fix (e.g. around block jobs). Instead of rushing in not thoroughly tested fixes disable the feature temporarily for the release. Signed-off-by: Michal Privoznik --- docs/news.xml | 13 -

[libvirt] [PATCH] news: Update for 5.0.0 release

Signed-off-by: Andrea Bolognani --- docs/news.xml | 38 ++ 1 file changed, 38 insertions(+) diff --git a/docs/news.xml b/docs/news.xml index 90b7e8891e..324b267656 100644 --- a/docs/news.xml +++ b/docs/news.xml @@ -45,6 +45,16 @@ trunking

Re: [libvirt] [PATCH v2 03/17] vircgroup: introduce virCgroupV2DevicesAttachProg

On Mon, Jan 14, 2019 at 04:47:37PM +0100, Pavel Hrdina wrote: > This function loads the BPF prog with prepared map into kernel and > attaches it into guest cgroup. It can be also used to replace existing > program in the cgroup if we need to resize BPF map to store more rules > for devices. The

[libvirt] [PATCH v2 13/17] vircgroup: introduce virCgroupV2DenyAllDevices

If we want to deny all devices we just need to replace any existing program with new program with empty map. Signed-off-by: Pavel Hrdina --- src/util/vircgroupv2.c | 11 +++ 1 file changed, 11 insertions(+) diff --git a/src/util/vircgroupv2.c b/src/util/vircgroupv2.c index

[libvirt] [PATCH v2 11/17] vircgroup: introduce virCgroupV2DenyDevice

In order to deny device we need to check if there is any entry in BPF map and we need to load the current value from map if there is already entry for that device. If both values are same we can remove that entry but if they are different we need to update the entry because we don't have to deny

[libvirt] [PATCH v2 09/17] vircgroup: introduce virCgroupV2DevicesGetKey

Device rules are stored in BPF map that is a hash type, this function will create a key based on major and minor id of device. Signed-off-by: Pavel Hrdina --- src/libvirt_private.syms | 1 + src/util/vircgroupv2devices.c | 8 src/util/vircgroupv2devices.h | 4 3 files

[libvirt] [PATCH v2 03/17] vircgroup: introduce virCgroupV2DevicesAttachProg

This function loads the BPF prog with prepared map into kernel and attaches it into guest cgroup. It can be also used to replace existing program in the cgroup if we need to resize BPF map to store more rules for devices. The old program will be closed and removed from kernel. There are two

[libvirt] [PATCH v2 14/17] vircgroup: workaround devices in hybrid mode

So the issue here is that you can end up with configuration where you have cgroup v1 and v2 enabled at the same time and the devices controllers is enabled for cgroup v1. In cgroup v2 there is no devices controller, the device access is controlled using BPF and since it is not a cgroup controller

[libvirt] [PATCH v2 10/17] vircgroup: introduce virCgroupV2AllowDevice

In order to allow device we need to create key and value which will be used to update BPF map. virBPFUpdateElem() can override existing entries in BPF map so we need to check if that entry exists in order to track number of entries in our map. This can add rule for specific device but major and

[libvirt] [PATCH v2 17/17] vircgroupmock: mock virCgroupV2DevicesAvailable

We need to mock virCgroupV2DevicesAvailable() in order to remove any dependency on kernel as BPF devices might not be available. Signed-off-by: Pavel Hrdina --- src/util/vircgroupv2devices.h | 5 - tests/vircgroupdata/hybrid.parsed | 2 +- tests/vircgroupmock.c | 7 +++

[libvirt] [PATCH v2 16/17] vircgroupv2: use dummy process to workaround kernel bug with systemd

If some program is attached to cgroup and that cgroup is removed before detaching the program it might not be freed and will remain in the system until it's rebooted. This would not be that big deal to workaround if we wouldn't use machined to track our guests. Systemd tries to be the nice guy

[libvirt] [PATCH v2 12/17] vircgroup: introduce virCgroupV2AllowAllDevices

If we want to allow all devices with all permissions we need to replace any existing program that has any rule configured, otherwise we just need to add new rule which will for example allow read access to all devices. Signed-off-by: Pavel Hrdina --- src/util/vircgroupv2.c | 18

[libvirt] [PATCH v2 15/17] vircgroupv2: detech BPF program before removing cgroup

This function simply removes program from guest cgroup before we remove the cgroup. This is required step because there is a bug [1] in kernel where the program might not be properly freed if you remove cgroup with attached program. [1]

[libvirt] [PATCH v2 08/17] vircgroup: introduce virCgroupV2DeviceGetPerms

Signed-off-by: Pavel Hrdina --- src/libvirt_private.syms | 1 + src/util/vircgroupv2devices.c | 34 ++ src/util/vircgroupv2devices.h | 6 ++ 3 files changed, 41 insertions(+) diff --git a/src/libvirt_private.syms b/src/libvirt_private.syms index

[libvirt] [PATCH v2 01/17] util: introduce virbpf helpers

In order to implement devices controller with cgroup v2 we need to add support for BPF programs, cgroup v2 doesn't have devices controller. This introduces required helpers wrapping linux syscalls. Signed-off-by: Pavel Hrdina --- configure.ac| 5 + include/libvirt/virterror.h

[libvirt] [PATCH v2 02/17] vircgroup: introduce virCgroupV2DevicesAvailable

There is no exact way how to figure out whether BPF devices support is compiled into kernel. One way is to check kernel configure options but this is not reliable as it may not be available. Let's try to do syscall to which will list BPF cgroup device programs. Signed-off-by: Pavel Hrdina ---

[libvirt] [PATCH v2 06/17] vircgroup: introduce virCgroupV2DevicesPrepareProg

This function will be called for every virCgroup(Allow|Deny)* API in order to prepare BPF program for guest. Since libvirtd can be restarted at any point we will first try to detect existing progam, if there is none we will create a new empty BPF program and lastly if we don't have any space left

[libvirt] [PATCH v2 07/17] vircgroup: introduce virCgroupV2DevicesRemoveProg

We need to close our FD that we have for BPF program and map in order to let kernel remove all resources once the cgroup is removed as well. Signed-off-by: Pavel Hrdina --- src/libvirt_private.syms | 1 + src/util/vircgroupv2.c| 3 +++ src/util/vircgroupv2devices.c | 26

[libvirt] [PATCH v2 05/17] vircgroup: introduce virCgroupV2DevicesCreateProg

This function creates new BPF program with new empty BPF map with the default size and attaches it to the guest cgroup. Signed-off-by: Pavel Hrdina --- src/libvirt_private.syms | 1 + src/util/vircgroupv2devices.c | 53 +++ src/util/vircgroupv2devices.h |

[libvirt] [PATCH v2 04/17] vircgroup: introduce virCgroupV2DevicesDetectProg

This function will be called if libvirtd was restarted while some domains were running. It will try to detect existing programs attached to the guest cgroup. Signed-off-by: Pavel Hrdina --- src/libvirt_private.syms | 1 + src/util/vircgroupv2devices.c | 117

[libvirt] [PATCH v2 00/17] implement cgroups v2 devices support

In cgroups v2 there is no devices controller, BPF should be used instead. Changes in v2: - fixed build on bsd and older kernels without cgroup BPF - cgroup bpf devices code moved to separate file Documentation for eBPF:

Re: [libvirt] [PATCH] news: Move entry for libvirt picking DRI devices

On Mon, Jan 14, 2019 at 02:43:42PM +0100, Andrea Bolognani wrote: > The entry, introduced by commit 3934beb8579c, ended up > inside a comment instead of the XML document proper, and > as such didn't show up in the generated files. > > Signed-off-by: Andrea Bolognani > --- > Pushed as trivial.

Re: [libvirt] [PATCH] report invalid x86 cpu map error

On Mon, Jan 14, 2019 at 04:15:01PM +0100, Jiri Denemark wrote: > On Mon, Jan 14, 2019 at 15:03:26 +, Daniel P. Berrangé wrote: > > On Mon, Jan 14, 2019 at 03:36:38PM +0100, Jiri Denemark wrote: > > > On Mon, Jan 14, 2019 at 14:21:42 +, Daniel P. Berrangé wrote: > > > > On Mon, Jan 14, 2019

Re: [libvirt] [PATCH] report invalid x86 cpu map error

On Mon, Jan 14, 2019 at 15:03:26 +, Daniel P. Berrangé wrote: > On Mon, Jan 14, 2019 at 03:36:38PM +0100, Jiri Denemark wrote: > > On Mon, Jan 14, 2019 at 14:21:42 +, Daniel P. Berrangé wrote: > > > On Mon, Jan 14, 2019 at 02:56:43PM +0100, Jiri Denemark wrote: > > > > On Mon, Jan 14, 2019

Re: [libvirt] [PATCH] report invalid x86 cpu map error

On Mon, Jan 14, 2019 at 03:36:38PM +0100, Jiri Denemark wrote: > On Mon, Jan 14, 2019 at 14:21:42 +, Daniel P. Berrangé wrote: > > On Mon, Jan 14, 2019 at 02:56:43PM +0100, Jiri Denemark wrote: > > > On Mon, Jan 14, 2019 at 20:07:34 +0800, zhenwei pi wrote: > > > > Let libvirtd handle invalid

Re: [libvirt] [PATCH] report invalid x86 cpu map error

On Mon, Jan 14, 2019 at 14:21:42 +, Daniel P. Berrangé wrote: > On Mon, Jan 14, 2019 at 02:56:43PM +0100, Jiri Denemark wrote: > > On Mon, Jan 14, 2019 at 20:07:34 +0800, zhenwei pi wrote: > > > Let libvirtd handle invalid x86 cpu map error, and report the real reason. > > > > > > This issue

Re: [libvirt] [PATCH] report invalid x86 cpu map error

On Mon, Jan 14, 2019 at 02:56:43PM +0100, Jiri Denemark wrote: > On Mon, Jan 14, 2019 at 20:07:34 +0800, zhenwei pi wrote: > > Let libvirtd handle invalid x86 cpu map error, and report the real reason. > > > > This issue can be reproduced : > > 1, rm -rf /share/libvirt/cpu_map > > 2, start

Re: [libvirt] [PATCH] report invalid x86 cpu map error

On Mon, Jan 14, 2019 at 20:07:34 +0800, zhenwei pi wrote: > Let libvirtd handle invalid x86 cpu map error, and report the real reason. > > This issue can be reproduced : > 1, rm -rf /share/libvirt/cpu_map > 2, start libvirtd > 3, virsh create INSTANCE.xml > > Libvirtd reports error : > error:

[libvirt] [PATCH] news: Move entry for libvirt picking DRI devices

The entry, introduced by commit 3934beb8579c, ended up inside a comment instead of the XML document proper, and as such didn't show up in the generated files. Signed-off-by: Andrea Bolognani --- Pushed as trivial. docs/news.xml | 26 +- 1 file changed, 13 insertions(+),

Re: [libvirt] [PATCH] report invalid x86 cpu map error

Hi, This series was run against 'syntax-check' test by patchew.org, which failed, please find the details below: Type: series Subject: [libvirt] [PATCH] report invalid x86 cpu map error Message-id: 1547467654-7093-1-git-send-email-pizhen...@bytedance.com === TEST SCRIPT BEGIN === #!/bin/bash #

[libvirt] [PATCH] report invalid x86 cpu map error

Let libvirtd handle invalid x86 cpu map error, and report the real reason. This issue can be reproduced : 1, rm -rf /share/libvirt/cpu_map 2, start libvirtd 3, virsh create INSTANCE.xml Libvirtd reports error : error: invalid argument: Failed to parse group 'tss' In face, libvirtd gets invalid

Re: [libvirt] [PATCH] util: make forgotten changes suggested during review of commit d40b820c

On Sun, Jan 13, 2019 at 12:42:20AM -0500, Laine Stump wrote: I had intended to make these changes to commit d40b820c before pushing, but forgot about it during the day between the initial review and ACK. Neither change is significant - just returning immediately when virNetDevGetName() faills