December 2016 - Devel - libvirt List Archives

[libvirt] [PATCH] apparmor: pass attach_disconnected
by Guido Günther 21 Dec '16

21 Dec '16

to cure + virsh lxc-enter-namespace --noseclabel <container> <cmd> libvirt: error : Expected at least one file descriptor error: internal error: Child process (2714) unexpected exit status 125 caused by apparmor="DENIED" operation="open" info="Failed name lookup - disconnected path" error=-13 profile="/usr/sbin/libvirtd" name="" pid=1422 comm="libvirtd" requested_mask="r" denied_mask="r" fsuid=0 ouid=0 --- Thanks to intrigeri for the suggestion! examples/apparmor/usr.sbin.libvirtd | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/examples/apparmor/usr.sbin.libvirtd b/examples/apparmor/usr.sbin.libvirtd index 48651b28f..b7e47f5c3 100644 --- a/examples/apparmor/usr.sbin.libvirtd +++ b/examples/apparmor/usr.sbin.libvirtd @@ -2,7 +2,7 @@ #include <tunables/global> @{LIBVIRT}="libvirt" -/usr/sbin/libvirtd { +/usr/sbin/libvirtd flags=(attach_disconnected) { #include <abstractions/base> #include <abstractions/dbus> -- 2.11.0

3 3

[libvirt] [PATCH v2] xen: add QED format test
by Cédric Bosdonnat 20 Dec '16

20 Dec '16

Follow up of commit 340bb6b7 to add unit tests for the QED format support. Also add missing QED case in xenFormatXLDisk() --- v2: * Separated the QED test files into another set ti make this test conditionnal * Removed useless #ifdef src/xenconfig/xen_xl.c | 3 +++ tests/xlconfigdata/test-disk-qed.cfg | 25 ++++++++++++++++++++ tests/xlconfigdata/test-disk-qed.xml | 45 ++++++++++++++++++++++++++++++++++++ tests/xlconfigtest.c | 3 +++ 4 files changed, 76 insertions(+) create mode 100644 tests/xlconfigdata/test-disk-qed.cfg create mode 100644 tests/xlconfigdata/test-disk-qed.xml diff --git a/src/xenconfig/xen_xl.c b/src/xenconfig/xen_xl.c index 048ecd579..18d9fe369 100644 --- a/src/xenconfig/xen_xl.c +++ b/src/xenconfig/xen_xl.c @@ -1050,6 +1050,9 @@ xenFormatXLDisk(virConfValuePtr list, virDomainDiskDefPtr disk) case VIR_STORAGE_FILE_QCOW2: virBufferAddLit(&buf, "qcow2"); break; + case VIR_STORAGE_FILE_QED: + virBufferAddLit(&buf, "qed"); + break; /* set default */ default: virBufferAddLit(&buf, "raw"); diff --git a/tests/xlconfigdata/test-disk-qed.cfg b/tests/xlconfigdata/test-disk-qed.cfg new file mode 100644 index 000000000..2a2c4fa84 --- /dev/null +++ b/tests/xlconfigdata/test-disk-qed.cfg @@ -0,0 +1,25 @@ +name = "XenGuest2" +uuid = "c7a5fdb2-cdaf-9455-926a-d65c16db1809" +maxmem = 579 +memory = 394 +vcpus = 1 +pae = 1 +acpi = 1 +apic = 1 +viridian = 0 +rtc_timeoffset = 0 +localtime = 0 +on_poweroff = "destroy" +on_reboot = "restart" +on_crash = "restart" +device_model = "/usr/lib/xen/bin/qemu-system-i386" +sdl = 0 +vnc = 1 +vncunused = 1 +vnclisten = "127.0.0.1" +vif = [ "mac=00:16:3e:66:92:9c,bridge=xenbr1,script=vif-bridge,model=e1000" ] +parallel = "none" +serial = "none" +builder = "hvm" +boot = "d" +disk = [ "/var/lib/libvirt/images/XenGuest2,qed,hda,rw", ] diff --git a/tests/xlconfigdata/test-disk-qed.xml b/tests/xlconfigdata/test-disk-qed.xml new file mode 100644 index 000000000..230382dd5 --- /dev/null +++ b/tests/xlconfigdata/test-disk-qed.xml @@ -0,0 +1,45 @@ +<domain type='xen'> + <name>XenGuest2</name> + <uuid>c7a5fdb2-cdaf-9455-926a-d65c16db1809</uuid> + <memory unit='KiB'>592896</memory> + <currentMemory unit='KiB'>403456</currentMemory> + <vcpu placement='static'>1</vcpu> + <os> + <type arch='x86_64' machine='xenfv'>hvm</type> + <loader type='rom'>/usr/lib/xen/boot/hvmloader</loader> + <boot dev='cdrom'/> + </os> + <features> + <acpi/> + <apic/> + <pae/> + </features> + <clock offset='variable' adjustment='0' basis='utc'/> + <on_poweroff>destroy</on_poweroff> + <on_reboot>restart</on_reboot> + <on_crash>restart</on_crash> + <devices> + <emulator>/usr/lib/xen/bin/qemu-system-i386</emulator> + <disk type='file' device='disk'> + <driver name='qemu' type='qed'/> + <source file='/var/lib/libvirt/images/XenGuest2'/> + <target dev='hda' bus='ide'/> + <address type='drive' controller='0' bus='0' target='0' unit='0'/> + </disk> + <controller type='ide' index='0'/> + <interface type='bridge'> + <mac address='00:16:3e:66:92:9c'/> + <source bridge='xenbr1'/> + <script path='vif-bridge'/> + <model type='e1000'/> + </interface> + <input type='mouse' bus='ps2'/> + <input type='keyboard' bus='ps2'/> + <graphics type='vnc' port='-1' autoport='yes' listen='127.0.0.1'> + <listen type='address' address='127.0.0.1'/> + </graphics> + <video> + <model type='cirrus' vram='8192' heads='1' primary='yes'/> + </video> + </devices> +</domain> diff --git a/tests/xlconfigtest.c b/tests/xlconfigtest.c index 31892da69..cab0c0d47 100644 --- a/tests/xlconfigtest.c +++ b/tests/xlconfigtest.c @@ -258,6 +258,9 @@ mymain(void) DO_TEST("new-disk"); DO_TEST_FORMAT("disk-positional-parms-full", false); DO_TEST_FORMAT("disk-positional-parms-partial", false); +#ifdef LIBXL_HAVE_QED + DO_TEST_FORMAT("disk-qed", false); +#endif DO_TEST("spice"); DO_TEST("spice-features"); DO_TEST("vif-rate"); -- 2.11.0

2 1

[libvirt] [PATCH 0/2] qemuDomainDiskChangeSupported: Add missing 'address' check
by Marc Hartmayer 20 Dec '16

20 Dec '16

Disk->info is not live updatable so add a check for this. Otherwise libvirt reports success even though no data was updated. Marc Hartmayer (2): conf: Make virDomainDeviceInfoAddressIsEqual() public qemu: qemuDomainDiskChangeSupported: Add missing 'address' check src/conf/domain_conf.c | 3 +-- src/conf/domain_conf.h | 5 +++++ src/libvirt_private.syms | 1 + src/qemu/qemu_domain.c | 13 +++++++++++++ 4 files changed, 20 insertions(+), 2 deletions(-) -- 2.5.5

3 6

Re: [libvirt] [Qemu-devel] [PATCH for-2.9 15/17] target-i386: Define static "base" CPU model
by Eduardo Habkost 20 Dec '16

20 Dec '16

On Mon, Dec 05, 2016 at 07:18:47PM +0100, David Hildenbrand wrote: > Am 02.12.2016 um 22:18 schrieb Eduardo Habkost: > > The query-cpu-model-expand QMP command needs at least one static > > model, to allow the "static" expansion mode to be implemented. > > Instead of defining static versions of every CPU model, define a > > "base" CPU model that has absolutely no feature flag enabled. > > > > Introducing separate ones makes feature lists presented to the user much > shorter (and therefore easier to maintain). But I don't know how libvirt > wants to deal with models on x86 in the future. I understand that having a larger set of static models would make expansions shorter. But I worry that by defining a complete set of static models on x86 would require extra maintenance work on the QEMU side with no visible benefit for libvirt. I would like to hear from libvirt developers what they think. I still don't know what they plan to use the type=static expansion results for. > > How long is the static expansion on a recent intel CPU? CPU model "Broadwell" returns 165 entries on return.model.props: (QEMU) query-cpu-model-expansion type=static model={"name":"Broadwell"} {"return": {"migration-safe": true, "model": {"name": "base", "props": {"pfthreshold": false, "pku": false, "rtm": true, "tsc-deadline": true, "xstore-en": false, "tsc-scale": false, "abm": true, "ia64": false, "kvm-mmu": false, "xsaveopt": true, "tce": false, "smep": true, "fpu": true, "xcrypt": false, "clflush": true, "flushbyasid": false, "kvm-steal-time": false, "lm": true, "tsc": true, "adx": true, "fxsr": true, "tm": false, "xgetbv1": false, "xstore": false, "vme": false, "vendor": "GenuineIntel", "arat": true, "de": true, "aes": true, "pse": true, "ds-cpl": false, "tbm": false, "sse": true, "phe-en": false, "f16c": true, "ds": false, "mpx": false, "tsc-adjust": false, "avx512f": false, "avx2": true, "pbe": false, "cx16": true, "avx512pf": false, "movbe": true, "perfctr-nb": false, "ospke": false, "avx512ifma": false, "stepping": 2, "sep": true, "sse4a": false, "avx512dq": false, "avx512-4vnniw": false, "xsave": true, "pmm": false, "hle": true, "est": false, "xop": false, "smx": false, "monitor": false, "avx512er": false, "apic": true, "sse4.1": true, "sse4.2": true, "pause-filter": false, "lahf-lm": true, "kvm-nopiodelay": false, "acpi": false, "mmx": true, "osxsave": false, "pcommit": false, "mtrr": true, "clwb": false, "dca": false, "pdcm": false, "xcrypt-en": false, "3dnow": false, "invtsc": false, "tm2": false, "hypervisor": true, "kvmclock-stable-bit": false, "fxsr-opt": false, "pcid": true, "lbrv": false, "avx512-4fmaps": false, "svm-lock": false, "popcnt": true, "nrip-save": false, "avx512vl": false, "x2apic": true, "kvmclock": false, "smap": true, "family": 6, "min-level": 13, "dtes64": false, "ace2": false, "fma4": false, "xtpr": false, "avx512bw": false, "nx": true, "lwp": false, "msr": true, "ace2-en": false, "decodeassists": false, "perfctr-core": false, "pge": true, "pn": false, "fma": true, "nodeid-msr": false, "cx8": true, "mce": true, "avx512cd": false, "cr8legacy": false, "mca": true, "pni": true, "rdseed": true, "osvw": false, "fsgsbase": true, "model-id": "Intel Core Processor (Broadwell)", "cmp-legacy": false, "kvm-pv-unhalt": false, "rdtscp": true, "mmxext": false, "cid": false, "vmx": false, "ssse3": true, "extapic": false, "pse36": true, "min-xlevel": 2147483656, "ibs": false, "avx": true, "syscall": true, "umip": false, "invpcid": true, "bmi1": true, "bmi2": true, "vmcb-clean": false, "erms": true, "cmov": true, "misalignsse": false, "clflushopt": false, "pat": true, "3dnowprefetch": true, "rdpid": false, "pae": true, "wdt": false, "skinit": false, "pmm-en": false, "phe": false, "3dnowext": false, "lmce": false, "ht": false, "pdpe1gb": false, "kvm-pv-eoi": false, "npt": false, "xsavec": false, "pclmulqdq": true, "svm": false, "sse2": true, "ss": false, "topoext": false, "rdrand": true, "avx512vbmi": false, "kvm-asyncpf": false, "xsaves": false, "model": 61}}, "static": true}} -- Eduardo

3 4

[libvirt] [PATCH 0/3] Get the voldef target physical value
by John Ferlan 20 Dec '16

20 Dec '16

This effort started primarily to address some ideas/thoughts brought up in https://bugzilla.redhat.com/show_bug.cgi?id=1332019 although as things were updated, it seems that using storage volume definitions wouldn't be necessary since the same data can be obtained via the virDomainGetBlockInfo API. Still since code had been written - I figured I'd posted it and see what kind of feedback it got. The first patch just adds the <physical> element to the output XML and documents it thusly. The 2nd/3rd patch take a different approach adding virStorageVolInfoFlags which could take a single flag indicating that the caller would prefer to return the "physical" value instead of the "allocation" value. Yes, kind of a hack, but since we cannot extend _virStorageVolInfo to add a physical it's a mechanism to allow fetching the data using existing structures. Sure a virStorageVolStats API could be created as well, but I figured I'd see how this went first before thinking about that. John Ferlan (3): conf: Display <physical> in output of voldef storage: Introduce virStorageVolInfoFlags virsh: Allow display of the physical volume size daemon/remote.c | 38 +++++++++++++++++++++++++++++ docs/formatstorage.html.in | 5 ++++ include/libvirt/libvirt-storage.h | 11 +++++++++ src/conf/storage_conf.c | 6 +++++ src/driver-storage.h | 6 +++++ src/libvirt-storage.c | 51 +++++++++++++++++++++++++++++++++++++++ src/libvirt_public.syms | 5 ++++ src/remote/remote_driver.c | 37 ++++++++++++++++++++++++++++ src/remote/remote_protocol.x | 20 ++++++++++++++- src/remote_protocol-structs | 10 ++++++++ src/storage/storage_driver.c | 24 +++++++++++++++--- tools/virsh-volume.c | 37 +++++++++++++++++++++++++--- tools/virsh.pod | 8 ++++-- 13 files changed, 247 insertions(+), 11 deletions(-) -- 2.7.4

2 6

[libvirt] [PATCH 0/2] cgroup: unavailable controller prevents controller disabling
by Boris Fiuczynski 20 Dec '16

20 Dec '16

The problem description is covered in patch one. I added patch two as an optional enhancement removing some complexity and improving readability. If this finds common agreement it should simply be squashed into the first patch of this series. Boris Fiuczynski (2): cgroup: unavailable controller prevents controller disabling cgroup: reduce complexity of controller disabling src/util/vircgroup.c | 15 ++++++++++----- 1 file changed, 10 insertions(+), 5 deletions(-) -- 2.5.5

2 6

[libvirt] [PATCH] qemu: Adjust qemuDomainGetBlockInfo data for sparse backed files
by John Ferlan 20 Dec '16

20 Dec '16

According to commit id '0282ca45a' the 'physical' value should essentially be the last offset of the image or the host physical size in bytes of the image container. However, commit id '15fa84ac' refactored the GetBlockInfo to use the same returned data as the GetStatsBlock API for an active domain. For the 'entry->physical' that would end up being the "actual-size" as set through the qemuMonitorJSONBlockStatsUpdateCapacityOne (commit '7b11f5e5'). Digging deeper into QEMU code one finds that actual_size is filled in using the same algorithm as GetBlockInfo has used for setting the 'allocation' field when the domain is inactive. The difference in values is seen primarily in sparse raw files and other container type files (such as qcow2), which will return a smaller value via the stat API for 'st_blocks'. Additionally for container files, the 'capacity' field (populated via the QEMU "virtual-size" value) may be slightly different (smaller) in order to accomodate the overhead for the container. For sparse files, the state 'st_size' field is returned. This patch thus alters the allocation and physical values for sparse backed storage files to be more appropriate to the API contract. The result for GetBlockInfo is the following: capacity: logical size in bytes of the image (how much storage the guest will see) allocation: host storage in bytes occupied by the image (such as highest allocated extent if there are no holes, similar to 'du') physical: host physical size in bytes of the image container (last offset, similar to 'ls') NB: The GetStatsBlock API allows a different contract for the values: "block.<num>.allocation" - offset of the highest written sector as unsigned long long. "block.<num>.capacity" - logical size in bytes of the block device backing image as unsigned long long. "block.<num>.physical" - physical size in bytes of the container of the backing image as unsigned long long. Signed-off-by: John Ferlan <jferlan(a)redhat.com> --- Initially based on a question posed on libvirt-users: https://www.redhat.com/archives/libvirt-users/2016-November/msg00050.html related to determining whether the provided physical value for an inactive guest would be valid I found that virDomainGetBlockInfo was returning different results for capacity and physical when the domain was running. As I dug deeper I found Eric Blake's commit regarding how libvirt uses/describes the allocation, capacity, and physical and felt that the changes made to virDomainGetBlockInfo especially for sparse files and "container" files (such as qcow2) would essentially provide incorrect and perhaps unexpected results. If it's felt that the live/active domain should return/display the same as the virConnectGetAllDomainStats, then I can drop the patch. I guess I find it odd that the physical size could be 4K matching the allocation value for a sparse file. Likewise, for a fully preallocated file was showing an allocation value of 0 since wr_highest_offset hadn't yet been updated. I've been testing with a guest with different types of "file" and "block" storage backings where the 'block' storage is essentially iSCSI devices added to the guest. Logically the changes result in what I'd expect for results based upon reading the API docs. src/qemu/qemu_driver.c | 22 +++++++++++++++++++--- 1 file changed, 19 insertions(+), 3 deletions(-) diff --git a/src/qemu/qemu_driver.c b/src/qemu/qemu_driver.c index 88778d4..c537891 100644 --- a/src/qemu/qemu_driver.c +++ b/src/qemu/qemu_driver.c @@ -11808,13 +11808,29 @@ qemuDomainGetBlockInfo(virDomainPtr dom, info->allocation = entry->wr_highest_offset; } - if (entry->physical) { - info->physical = entry->physical; - } else { + /* Unlike GetStatsBlock, this API has defined the expected return values + * for allocation and physical slightly differently. + * + * Having a zero for either or if they're the same is an indication that + * there's a sparse file backing this device. In this case, we'll force + * the setting of physical based on the on disk file size. + * + * Additionally, if qemu hasn't written to the file yet, then set the + * allocation to whatever qemu returned for physical (e.g. the "actual- + * size" from the json query) as that will match the expected allocation + * value for this API. */ + if (entry->physical == 0 || info->allocation == 0 || + info->allocation == entry->physical) { + info->allocation = entry->physical; + if (info->allocation == 0) + info->allocation = entry->physical; + if (qemuDomainStorageUpdatePhysical(driver, cfg, vm, disk->src) < 0) goto endjob; info->physical = disk->src->physical; + } else { + info->physical = entry->physical; } info->capacity = entry->capacity; -- 2.7.4

2 1

[libvirt] [PATCH] examples: Resolve sign-compare warnings
by Michal Privoznik 20 Dec '16

20 Dec '16

For instance: hellolibvirt/hellolibvirt.c: In function 'showDomains': hellolibvirt/hellolibvirt.c:100:19: warning: comparison between signed and unsigned integer expressions [-Wsign-compare] for (i = 0; i < numNames; i++) { ^ Signed-off-by: Michal Privoznik <mprivozn(a)redhat.com> Signed-off-by: Michal Privoznik <mprivozn(a)redhat.com> --- examples/admin/client_info.c | 2 +- examples/admin/client_limits.c | 2 +- examples/admin/list_clients.c | 2 +- examples/admin/list_servers.c | 2 +- examples/admin/threadpool_params.c | 2 +- examples/domsuspend/suspend.c | 2 +- examples/domtop/domtop.c | 7 +++---- examples/hellolibvirt/hellolibvirt.c | 2 +- examples/openauth/openauth.c | 2 +- 9 files changed, 11 insertions(+), 12 deletions(-) diff --git a/examples/admin/client_info.c b/examples/admin/client_info.c index 314a0902b..57e9cd71e 100644 --- a/examples/admin/client_info.c +++ b/examples/admin/client_info.c @@ -102,7 +102,7 @@ int main(int argc, char **argv) virAdmClientPtr clnt = NULL; /* which client get identity for */ virTypedParameterPtr params = NULL; /* where to store identity info */ int nparams = 0; - size_t i = 0; + ssize_t i = 0; char *timestr = NULL; if (argc != 3) { diff --git a/examples/admin/client_limits.c b/examples/admin/client_limits.c index 2d5b75489..2a1d6314c 100644 --- a/examples/admin/client_limits.c +++ b/examples/admin/client_limits.c @@ -9,7 +9,7 @@ int main(int argc, char **argv) virAdmServerPtr srv = NULL; /* which server to work with */ virTypedParameterPtr params = NULL; int nparams = 0; - size_t i; + ssize_t i; if (argc != 2) { fprintf(stderr, "One argument specifying the server which to work " diff --git a/examples/admin/list_clients.c b/examples/admin/list_clients.c index 3b4496e30..21ea4d818 100644 --- a/examples/admin/list_clients.c +++ b/examples/admin/list_clients.c @@ -50,7 +50,7 @@ int main(int argc, char **argv) virAdmConnectPtr conn = NULL; virAdmServerPtr srv = NULL; /* which server list the clients from */ virAdmClientPtr *clients = NULL; /* where to store the servers */ - size_t i = 0; + ssize_t i = 0; int count = 0; if (argc != 2) { diff --git a/examples/admin/list_servers.c b/examples/admin/list_servers.c index 1f6f4c6cf..420fd5fb7 100644 --- a/examples/admin/list_servers.c +++ b/examples/admin/list_servers.c @@ -8,7 +8,7 @@ int main(void) virAdmConnectPtr conn = NULL; virAdmServerPtr *servers = NULL; /* where to store the servers */ virAdmServerPtr *tmp = NULL; - size_t i = 0; + ssize_t i = 0; int count = 0; /* first, open a connection to the daemon */ diff --git a/examples/admin/threadpool_params.c b/examples/admin/threadpool_params.c index ee9ce83c1..43c71184a 100644 --- a/examples/admin/threadpool_params.c +++ b/examples/admin/threadpool_params.c @@ -9,7 +9,7 @@ int main(int argc, char **argv) virAdmServerPtr srv = NULL; /* which server to work with */ virTypedParameterPtr params = NULL; int nparams = 0; - size_t i; + ssize_t i; if (argc != 2) { fprintf(stderr, "One argument specifying the server which to work " diff --git a/examples/domsuspend/suspend.c b/examples/domsuspend/suspend.c index 3e3f70e23..493a4b7b2 100644 --- a/examples/domsuspend/suspend.c +++ b/examples/domsuspend/suspend.c @@ -156,7 +156,7 @@ fetch_domains(virConnectPtr conn) { int num_domains, ret = -1; virDomainPtr *domains = NULL; - size_t i; + ssize_t i; const int list_flags = VIR_CONNECT_LIST_DOMAINS_ACTIVE; DEBUG("Fetching list of running domains"); diff --git a/examples/domtop/domtop.c b/examples/domtop/domtop.c index 22839947d..5a798154a 100644 --- a/examples/domtop/domtop.c +++ b/examples/domtop/domtop.c @@ -161,7 +161,7 @@ fetch_domains(virConnectPtr conn) { int num_domains, ret = -1; virDomainPtr *domains = NULL; - size_t i; + ssize_t i; const int list_flags = VIR_CONNECT_LIST_DOMAINS_ACTIVE; DEBUG("Fetching list of running domains"); @@ -189,8 +189,7 @@ fetch_domains(virConnectPtr conn) } static void -print_cpu_usage(const char *dom_name, - size_t cpu, +print_cpu_usage(size_t cpu, size_t ncpus, unsigned long long then, virTypedParameterPtr then_params, @@ -334,7 +333,7 @@ do_top(virConnectPtr conn, goto cleanup; } - print_cpu_usage(dom_name, 0, max_id, + print_cpu_usage(0, max_id, then.tv_sec * 1000000 + then.tv_usec, then_params, then_nparams, now.tv_sec * 1000000 + now.tv_usec, diff --git a/examples/hellolibvirt/hellolibvirt.c b/examples/hellolibvirt/hellolibvirt.c index c64fa9658..02c440198 100644 --- a/examples/hellolibvirt/hellolibvirt.c +++ b/examples/hellolibvirt/hellolibvirt.c @@ -55,7 +55,7 @@ static int showDomains(virConnectPtr conn) { int ret = 0, numNames, numInactiveDomains, numActiveDomains; - size_t i; + ssize_t i; int flags = VIR_CONNECT_LIST_DOMAINS_ACTIVE | VIR_CONNECT_LIST_DOMAINS_INACTIVE; virDomainPtr *nameList = NULL; diff --git a/examples/openauth/openauth.c b/examples/openauth/openauth.c index 0be977ef8..7a8254bb1 100644 --- a/examples/openauth/openauth.c +++ b/examples/openauth/openauth.c @@ -91,7 +91,7 @@ static int showDomains(virConnectPtr conn) { int ret = 0, numNames, numInactiveDomains, numActiveDomains; - size_t i; + ssize_t i; char **nameList = NULL; numActiveDomains = virConnectNumOfDomains(conn); -- 2.11.0

2 1

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] Point to the new libvirt-go bindings
by Daniel P. Berrange 19 Dec '16

19 Dec '16

The github.com/rgbkrk/libvirt-go bindings were the most complete bindings historically, but their API coverage stops at 1.2.4, with exception of a couple of newer APIs. The new bindings at http://libvirt.org/git/?p=libvirt-go.git;a=log how have (almost[1]) 100% API coverage all the way to 2.5.0. They also expose the APIs in a way that allows for much stronger go type checking by the compiler, and expose typed parameters as explicit structs. Finally the bindings are able to conditionally compile against any libvirt version 1.2.0 -> 2.5.0 without use of go build tags. Change the docs to point to these new bindings, since they'll be a better bet for users long term. [1] virEvent & virStream callbacks are still TODO to be fixed real soon. Signed-off-by: Daniel P. Berrange <berrange(a)redhat.com> --- docs/bindings.html.in | 4 ++-- docs/docs.html.in | 2 +- docs/downloads.html.in | 15 +++++++++++++++ 3 files changed, 18 insertions(+), 3 deletions(-) diff --git a/docs/bindings.html.in b/docs/bindings.html.in index 7fe26df..dc15576 100644 --- a/docs/bindings.html.in +++ b/docs/bindings.html.in @@ -15,8 +15,8 @@ <a href="csharp.html">C# bindings</a>. </li> <li> - <strong>Go</strong>: Kyle Kelley et al. are developing - <a href="https://github.com/rgbkrk/libvirt-go">Go bindings</a>. + <strong>Go</strong>: Daniel Berrange develops + <a href="https://godoc.org/github.com/libvirt/libvirt-go">Go bindings</a>. </li> <li> <strong>Java</strong>: Daniel Veillard develops diff --git a/docs/docs.html.in b/docs/docs.html.in index b0d200b..60489a0 100644 --- a/docs/docs.html.in +++ b/docs/docs.html.in @@ -57,7 +57,7 @@ <dt><a href="bindings.html">Language bindings</a></dt> <dd>Bindings of the libvirt API for <a href="csharp.html">c#</a>, - <a href="https://github.com/rgbkrk/libvirt-go">go</a>, + <a href="https://godoc.org/github.com/libvirt/libvirt-go">go</a>, <a href="java.html">java</a>, <a href="http://libvirt.org/ocaml/">ocaml</a>. <a href="http://search.cpan.org/dist/Sys-Virt/">perl</a>, diff --git a/docs/downloads.html.in b/docs/downloads.html.in index dd96409..3a6ea91 100644 --- a/docs/downloads.html.in +++ b/docs/downloads.html.in @@ -57,6 +57,21 @@ </td> </tr> <tr> + <td>Go</td> + <td> + <a href="ftp://libvirt.org/libvirt/go/">ftp</a> + <a href="http://libvirt.org/sources/go/">http</a> + <a href="https://libvirt.org/sources/go/">https</a> + </td> + <td> + <a href="http://libvirt.org/git/?p=libvirt-go.git;a=summary">libvirt</a> + </td> + <td> + <a href="https://gitlab.com/libvirt/libvirt-go">gitlab</a> + <a href="https://github.com/libvirt/libvirt-go">github</a> + </td> + </tr> + <tr> <td>Java</td> <td> <a href="ftp://libvirt.org/libvirt/java/">ftp</a> -- 2.9.3

2 1