- Devel - libvirt List Archives

[libvirt] RFC for support Intel RDT/CAT in libvirt
by Qiao, Liyong 09 Jan '17

09 Jan '17

Hi folks I would like to start a discussion about how to support a new cpu feature in libvirt. CAT support is not fully merged into linux kernel yet, the target release is 4.10, and all patches has been merged into linux tip branch. So there won’t be interface/design changes. ## Background Intel RDT is a toolkit to do resource Qos for cpu such as llc(l3) cache, memory bandwidth usage, these fine granularity resource control features are very useful in a cloud environment which will run logs of noisy instances. Currently, Libvirt has supported CAT/MBMT/MBML already, they are only for resource usage monitor, propose to supporting CAT to control VM’s l3 cache quota. ## CAT interface in kernel In kernel, a new resource interface has been introduced under /sys/fs/resctrl, it’s used for resource control, for more information, refer Intel_rdt_ui [ https://git.kernel.org/cgit/linux/kernel/git/tip/tip.git/tree/Documentation… ] Kernel requires to provide schemata for l3 cache before add a task to a new partition, these interface is too much detail for a virtual machine user, so propose to let Libvirt manage schemata on the host. ## What will libvirt do? ### Questions: To enable CAT support in libvirt, we need to think about follow questions 1. Only set CAT when an VM has CPU pin, which is to say, l3 cache is per cpu socket resources. On a host which has 2 cpu sockets, each cpu socket has it own cache, and can not be shared.. 2. What the cache allocation policy should be used, this will be looks like: a. VM has it’s own dedicated l3 cache and also can share other l3 cache. b. VM can only use the caches which allocated to it. c. Has some pre-defined policies and priority for a VM Like COB [1] 1. Should reserve some l3 cache for host’s system usage (related to 2) 2. What’s the unit for l3 cache allocation? (related to 2) ### Propose Changes XML domain user interface changes: Option 1: explicit specify cache allocation for a VM 1 work with numa node Some cloud orchestration software use numa + vcpu pin together, so we can enable cat supporting with numa infra. Expose how many l3 cache a VM want to reserved and we require that the l3 cache should be bind on some specify cpu socket, just like what we did for numa node. This is an domain xml example which is generated by OpenStack Nova for allocate llc(l3 cache) when booting a new VM <domain> … <cputune> <vcpupin vcpu='0' cpuset='19'/> <vcpupin vcpu='1' cpuset='63'/> <vcpupin vcpu='2' cpuset='83'/> <vcpupin vcpu='3' cpuset='39'/> <vcpupin vcpu='4' cpuset='40'/> <vcpupin vcpu='5' cpuset='84'/> <emulatorpin cpuset='19,39-40,63,83-84'/> </cputune> ... <cpu mode='host-model'> <model fallback='allow'/> <topology sockets='3' cores='1' threads='2'/> <numa> <cell id='0' cpus='0-1' memory='2097152' l3cache='1408' unit='KiB'/> <cell id='1' cpus='2-5' memory='4194304' l3cache='5632' unit='KiB'/> </numa> </cpu> ... </domain> Refer to [http://libvirt.org/formatdomain.html#elementsCPUTuning] So finally we can calculate on which CPU socket(cell) we need to allocate how may l3cache for a VM. 2. work with vcpu pin Forget numa part, CAT setting should have relationship with cpu core setting, we can apply CAT policy if VM has set cpu pin setting (only VM won’t be schedule to another CPU sockets) Cache allocation on which CPU socket can be calculate as just as 1. We may need to enable both 1 and 2. There are several policy for cache allocation: Let’ take some examples: For intel e5 v4 2699(Signal socket), there are 55M l3 cache on the chip , the default of L3 schemata is L3:0=ffffff , it represents to use 20 bit to control l3 cache, each bit will represent 2.75M, which will be the minimal unit on this host. The allocation policy could be 3 policies : 1. One priority VM: A priority import VM can be allocated a dedicated amount l3 cache (let’s say 2.75 * 4 = 11M) and it can also reach the left 44 M cache which will be shared with other process and VM on the same host. So that we need to create a new ‘Partition’ n-20371 root@s2600wt:/sys/fs/resctrl# ls cpus info n-20371 schemata tasks Inside of n-20371 directory: root@s2600wt:/sys/fs/resctrl# ls n-20371/ cpus schemata tasks The schemata content will be L3:0=fffff The tasks content will be the pids of that VM Along we need to change the default schemata of system: root@s2600wt:/sys/fs/resctrl# cat schemata L3:0=ffff # which can not use the highest 4 bits, only tasks in n-20371 can reach that. In this design , we can only get 1 priority VM. Let’s change it a bit to have 2 VMs The schemata of the 2 VMs could be: 1. L3:0=ffff0 # could not use the 4 low bits 11M l3 cache 2. L3:0=0ffff # could not use the 4 high bits 11M l3 cache Default schemata changes to L3:0=0fff0 # default system process could only use the middle 33M l3 cache 2. Isolated l3 cache dedicated allocation for each VM(if required) A VM can only use the cache allocated to it. For example VM 1 requires to allocate 11 M It’s schemata will be L3:0=f0000 # VM 2 requires to allocate 11M It’s schemata will be L3:0=f000 And default schemata will be L3:0=fff In this case, we can create multiple VMs which each of them can have dedicated l3 cache. The disadvantage is that we the allocated cache could be not be shared efficiently. 3. Isolated l3 cache shared allocation for each VM(if required by user) In this case, we will put some VMs (which consider as noisy neighbors) to a ‘Partition’, restrict them to use the only caches allocated to them, by do this, other much more priority VM can be ensure to have enough l3 cache Then we should decide how much cache the noisy group should have, and put all of their pids in that tasks file. Option 2: set cache priority and apply policies Don’t specify cache amount at all, only define cache usage priority when define a VM domain XML. Cache priority will decide how much the VM can use l3 cache on a host, it’s not a quantized. So user don’t need to think about how much cache it should have when define a domain XML. Libvirt will decide cache allocation by the priority of VM defined and policies using. Disadvantage is that caches ability on different host may be different. Same VM domain XML on different host may have vary caches allocation amount. # Support CAT in libvirt itself or leverage other software COB COB is Intel Cache Orchestrator Balancer (COB). please refer http://clrgitlab.intel.com/rdt/cob/tree/master COB supports some pre-defined policies, it will monitor cpu/cache/cache missing and do cache allocation based on policy using. If COB support monitor some specified process (VM process) and accept priority defined, it will be good to reuse. At last the question came out: * Support a fine-grained llc cache control , let user specify cache allocation * Support pre-defined policies and user specify llc allocation priority. Reference [1] COB http://clrgitlab.intel.com/rdt/cob/tree/master [2] CAT intro: https://software.intel.com/en-us/articles/software-enabling-for-cache-alloc… [3] kernel Intel_rdt_ui [ https://git.kernel.org/cgit/linux/kernel/git/tip/tip.git/tree/Documentation… ] Best Regards Eli Qiao(乔立勇）OpenStack Core team OTC Intel. --

2 1

[libvirt] [PATCH 0/6] Don't run whole sec driver in namespace
by Michal Privoznik 09 Jan '17

09 Jan '17

In eadaa97548 I've tried to solve the issue of setting seclabels on private /dev/* entries. While my approach works, it has tiny flaw - anything that happens in the namespace stays in the namespace. I mean, if there's a internal state change occurring on relabel operation (it should not, and it doesn't nowadays, but it's no guarantee), this change is not reflected in the daemon. This is because when entering the namespace, the daemon forks, enters the namespace and then executes the RelabelAll() function. This imperfection is: a) very easy to forget b) very hard to debug Therefore, we may have transaction APIs as suggested here [1]. On transactionBegin() the sec driver will record [path. seclabel] somewhere instead of applying the label. Then on transactionCommit() new process is forked, enters the namespace and perform previously recorded changes. This way it is only the minimal code that runs in the namespace. Moreover, it runs over constant data thus there can be no internal state transition. 1: https://www.redhat.com/archives/libvir-list/2016-December/msg00254.html Michal Privoznik (6): security_selinux: s/virSecuritySELinuxSecurity/virSecuritySELinux/ security_dac: Resolve virSecurityDACSetOwnershipInternal const correctness security driver: Introduce transaction APIs security_dac: Implement transaction APIs security_selinux: Implement transaction APIs qemu: Use transactions from security driver src/libvirt_private.syms | 3 + src/qemu/qemu_driver.c | 28 +++-- src/qemu/qemu_security.c | 98 +++++---------- src/security/security_dac.c | 197 +++++++++++++++++++++++++++++- src/security/security_driver.h | 9 ++ src/security/security_manager.c | 38 ++++++ src/security/security_manager.h | 7 +- src/security/security_selinux.c | 219 +++++++++++++++++++++++++++++++--- src/security/security_stack.c | 49 ++++++++ src/storage/storage_backend.h | 2 +- src/storage/storage_backend_fs.c | 2 +- src/storage/storage_backend_gluster.c | 2 +- src/storage/storage_driver.c | 6 +- src/storage/storage_driver.h | 4 +- src/util/virstoragefile.c | 2 +- src/util/virstoragefile.h | 2 +- 16 files changed, 561 insertions(+), 107 deletions(-) -- 2.11.0

2 12

Re: [libvirt] libvirt support for mediated devices
by Laine Stump 09 Jan '17

09 Jan '17

VFIO's new mediated device interface "is used for allowing software-defined devices to be exposed through VFIO while the host driver manages access to the interface" (quoted from http://www.phoronix.com/scan.php?page=news_item&px=VFIO-Linux-4.10-Mediated ). Now that the support for mediated devices has been added to the upstream Linux kernel, there is a stable API that libvirt can use to support assigning mediated devices (e.g. virtual GPUs) to Qemu/KVM guests (or presumably any other hypervisor that support device assignment via VFIO. We've had a few private discussions about what should be added to libvirt, and now have enough rough ideas to start discussing it on the list. The major requirements we've come up with so far (in what I think is a reasonable order of implementation) are: 1) The ability to assign an already-created mediated device to a guest (think of "<hostdev ... managed='no'>" mode for assigning regular PCI devices). 2) reporting of the capabilities of a mediated device "parent" (including, for example, the supported types and maximum number of child devices that are supported, and the names of all existing child devices) and of existing child devices (via the node device APIs, e.g. virsh nodedev-list and virsh nodedev-dumpxml) 3) The ability to create and destroy mediated devices via the NodeDevice API. (similar in function to the "virsh detach-device and virsh attach-device commands - i.e. they make a device ready to be assigned to a guest using <hostdev>, but have no persistent config and no "auto-start" capability). 4) Support for "managed" mediated devices - libvirt will create a new child device as required, and destroy it when it's no longer needed (similar to the way that standard PCI hostdevs are (when managed="yes") detached from their host driver and attached to vfio-pci as needed) (I think this is less useful than item (5), but is simpler and may be a good way to test all the preceding additions (as well as being useful in some simpler configurations). 5) The ability to create and manage "pools" of mediated devices, with persistent config and an auto-start capability so that the device pools are automatically created when the host is booted (this will require either some form of persistent config and lifecycle management to be added to the nodedevice driver, or a new libvirt driver type with functionality similar to storage pools, but used to manage pools of mdev child devices). ========= Going back to the beginning, with slightly more detail: 1) "Unmanaged" mediated device assignment - assigning an existing device to a virtual machine This will assume that the desired child device has already been created, and can be found in /sys/bus/mdev/devices/$UUID. Here's a first attempt at what the XML would look like: <hostdev mode='subsystem' type='pci' /managed='no'>/ <source>  <mdev uuid='$uuid'/> </source> <address type='pci' blah blah blah/>  </hostdev> In the past, the "type" attribute of hostdev described the type on both the host and the guest. With mediated devices, the device isn't visible on the host as a PCI device, but just as a software device. So the type attribute in <hostdev> now gives the type of the device on the guest, and the device type on the host is determined from the contents of <source>. Erik had a different suggestion for this (which I think he's already working on patches for) - that the type attribute in <hostdev> should be the type of the device in the *host*, and the type in the guest would be that given in the <address>. Something like this I think: <hostdev mode='subsystem' type='mdev' /managed='no'/> <source> <mdev uuid='$uuid'/> </source> <address type='pci' blah blah blah/> </hostdev> (Is this correct, Erik?) (I arrived at my suggestion by the thinking that, in other places where there are similar attributes for the host and guest side, e.g. the IP addresses and routes that can be added on both the host and guest side of an <interface>, everything related to the host side is in the <source> subelement, while things related to the guest are directly under the toplevel of the device element. On the other hand, the "managed" attribute isn't something related to the guest, but to the host, and his idea has less redundancy, so maybe he's onto something...) (NB: a mediated device could be exposed to the guest as a PCI device, a CCW device, or anything else supported by vfio. The type of device that the guest will see can be determined from the contents of mdev_supported_types/<type-id>/device_api under the parent device's directory in sysfs (it will be, e.g., "vfio-pci" or "vfio-ccw"). But libvirt assigns guest-side addresses at the time a domain is defined, and it's possible that the mdev child device won't be created yet at define time (and therefore we won't know which parent device it's associated with, and so we won't be able to look at device_api). In such situations, it will be up to management to know something about the device it will be creating and assume a type. Fortunately this is a reasonably safe thing to do - on x86 platforms we can be fairly certain that the device will be a PCI device. (And, because this also makes a difference for some machinetypes, that it will be a PCI Express device). We will want to check device_api at runtime though, to validate that the guest-side device really is a PCI device. == 2) Reporting parent and child mediated devices and their capabilities in the node device API. There are 3 stages to this: a) add mediated child devices to the list of devices provided by "virsh nodedev-list". These will be called "mdev_$UUID", and will show up as descendents of their respective parent devices in "virsh nodedev-list --tree". The list of all these devices can easily be retrieved by enumerating the links in /sys/bus/mdev/devices/$UUID. b) report the capabilities of parent devices in their dumpxml output. This will included supported child device types and a list of current children. I don't have any experience with nodedev reporting for SCSI devices, but recently noticed that nodedev-list can report lists of devices with certain capabilities, e.g. "virsh nodedev-list --cap=scsi_host". Based on this, I guess it would be useful for the parent devices to show something like this (using the sample mtty driver as an example): <device> <name>pci_0000_02_00_0</name> <parent>pci_0000_00_04_0</parent> <driver> <name>mtty</name> </driver> <capability type='mdev_parent'> [list of supported types, each with number allowed] [list of current child devices (just giving uuid or device name ("mdev_$uuid"?)] [other info about parent/children?] </capability> ... Likewise, a nodedev-dumpxml of a child device should contain a pointer to the parent device. c) respond to dumpxml requests for mediated child devices. This should include at least the uuid/type of the child device, and a link back to the parent device (and I suppose somehow include <capability type='mdev_child'> so that it can be filtered with virsh modedev-list?) == (3), (4), and (5) need more thought that I haven't gotten to yet. TBD (if anyone else has thoughts on those, please share!)

2 1

[libvirt] [PATCH] conf: Parse virtio-crypto in the domain XML
by Longpeng(Mike) 09 Jan '17

09 Jan '17

As virtio-crypto has been supported in QEMU 2.9 and the frontend driver has been merged in linux 4.10, so it's necessary to support virtio-crypto in domain XML. This patch parse the domain XML with virtio-crypto support, the virtio-crypto XML looks like this: <crypto model='virtio'> <backend type='builtin' queues='2'/> </crypto> Signed-off-by: Longpeng(Mike) <longpeng2(a)huawei.com> --- src/conf/domain_conf.c | 212 +++++++++++++++++++++++++++++++++++++++++ src/conf/domain_conf.h | 32 +++++++ src/qemu/qemu_alias.c | 20 ++++ src/qemu/qemu_alias.h | 4 + src/qemu/qemu_capabilities.c | 4 + src/qemu/qemu_capabilities.h | 2 + src/qemu/qemu_command.c | 129 +++++++++++++++++++++++++ src/qemu/qemu_command.h | 4 + src/qemu/qemu_domain_address.c | 17 ++++ src/qemu/qemu_driver.c | 6 ++ src/qemu/qemu_hotplug.c | 1 + 11 files changed, 431 insertions(+) diff --git a/src/conf/domain_conf.c b/src/conf/domain_conf.c index 9f7b906..fcfccd5 100644 --- a/src/conf/domain_conf.c +++ b/src/conf/domain_conf.c @@ -237,6 +237,7 @@ VIR_ENUM_IMPL(virDomainDevice, VIR_DOMAIN_DEVICE_LAST, "memballoon", "nvram", "rng", + "crypto", "shmem", "tpm", "panic", @@ -797,6 +798,14 @@ VIR_ENUM_IMPL(virDomainRNGBackend, "random", "egd"); +VIR_ENUM_IMPL(virDomainCryptoModel, + VIR_DOMAIN_CRYPTO_MODEL_LAST, + "virtio"); + +VIR_ENUM_IMPL(virDomainCryptoBackend, + VIR_DOMAIN_CRYPTO_BACKEND_LAST, + "builtin"); + VIR_ENUM_IMPL(virDomainTPMModel, VIR_DOMAIN_TPM_MODEL_LAST, "tpm-tis") @@ -2337,6 +2346,9 @@ void virDomainDeviceDefFree(virDomainDeviceDefPtr def) case VIR_DOMAIN_DEVICE_RNG: virDomainRNGDefFree(def->data.rng); break; + case VIR_DOMAIN_DEVICE_CRYPTO: + virDomainCryptoDefFree(def->data.crypto); + break; case VIR_DOMAIN_DEVICE_CHR: virDomainChrDefFree(def->data.chr); break; @@ -2600,6 +2612,10 @@ void virDomainDefFree(virDomainDefPtr def) virDomainRNGDefFree(def->rngs[i]); VIR_FREE(def->rngs); + for (i = 0; i < def->ncryptos; i++) + virDomainCryptoDefFree(def->cryptos[i]); + VIR_FREE(def->cryptos); + for (i = 0; i < def->nmems; i++) virDomainMemoryDefFree(def->mems[i]); VIR_FREE(def->mems); @@ -3169,6 +3185,8 @@ virDomainDeviceGetInfo(virDomainDeviceDefPtr device) return &device->data.shmem->info; case VIR_DOMAIN_DEVICE_RNG: return &device->data.rng->info; + case VIR_DOMAIN_DEVICE_CRYPTO: + return &device->data.crypto->info; case VIR_DOMAIN_DEVICE_TPM: return &device->data.tpm->info; case VIR_DOMAIN_DEVICE_PANIC: @@ -3464,6 +3482,12 @@ virDomainDeviceInfoIterateInternal(virDomainDefPtr def, if (cb(def, &device, &def->rngs[i]->info, opaque) < 0) return -1; } + device.type = VIR_DOMAIN_DEVICE_CRYPTO; + for (i = 0; i < def->ncryptos; i++) { + device.data.crypto = def->cryptos[i]; + if (cb(def, &device, &def->cryptos[i]->info, opaque) < 0) + return -1; + } if (def->nvram) { device.type = VIR_DOMAIN_DEVICE_NVRAM; device.data.nvram = def->nvram; @@ -3541,6 +3565,7 @@ virDomainDeviceInfoIterateInternal(virDomainDefPtr def, case VIR_DOMAIN_DEVICE_PANIC: case VIR_DOMAIN_DEVICE_LAST: case VIR_DOMAIN_DEVICE_RNG: + case VIR_DOMAIN_DEVICE_CRYPTO: case VIR_DOMAIN_DEVICE_MEMORY: break; } @@ -4599,6 +4624,7 @@ virDomainDeviceDefValidateInternal(const virDomainDeviceDef *dev, case VIR_DOMAIN_DEVICE_MEMBALLOON: case VIR_DOMAIN_DEVICE_NVRAM: case VIR_DOMAIN_DEVICE_RNG: + case VIR_DOMAIN_DEVICE_CRYPTO: case VIR_DOMAIN_DEVICE_SHMEM: case VIR_DOMAIN_DEVICE_TPM: case VIR_DOMAIN_DEVICE_PANIC: @@ -12022,6 +12048,88 @@ virDomainRNGDefParseXML(xmlNodePtr node, } +static virDomainCryptoDefPtr +virDomainCryptoDefParseXML(xmlNodePtr node, + xmlXPathContextPtr ctxt, + unsigned int flags) +{ + char *model = NULL; + char *backend = NULL; + char *queues = NULL; + virDomainCryptoDefPtr def; + xmlNodePtr save = ctxt->node; + xmlNodePtr *backends = NULL; + int nbackends; + + if (VIR_ALLOC(def) < 0) + return NULL; + + if (!(model = virXMLPropString(node, "model"))) { + virReportError(VIR_ERR_XML_ERROR, "%s", + _("missing Crypto device model")); + goto error; + } + + if ((def->model = virDomainCryptoModelTypeFromString(model)) < 0) { + virReportError(VIR_ERR_CONFIG_UNSUPPORTED, + _("unknown Crypto model '%s'"), model); + goto error; + } + + ctxt->node = node; + + if ((nbackends = virXPathNodeSet("./backend", ctxt, &backends)) < 0) + goto error; + + if (nbackends != 1) { + virReportError(VIR_ERR_XML_ERROR, "%s", + _("only one Crypto backend is supported")); + goto error; + } + + if (!(backend = virXMLPropString(backends[0], "type"))) { + virReportError(VIR_ERR_XML_ERROR, "%s", + _("missing Crypto device backend type")); + goto error; + } + + if ((def->backend = virDomainCryptoBackendTypeFromString(backend)) < 0) { + virReportError(VIR_ERR_CONFIG_UNSUPPORTED, + _("unknown Crypto backend model '%s'"), backend); + goto error; + } + + switch ((virDomainCryptoBackend) def->backend) { + case VIR_DOMAIN_CRYPTO_BACKEND_BUILTIN: + queues = virXMLPropString(backends[0], "queues"); + if (queues && virStrToLong_ui(queues, NULL, 10, &def->queues) < 0) { + virReportError(VIR_ERR_XML_ERROR, + _("Malformed 'queues' value '%s'"), queues); + } + break; + + case VIR_DOMAIN_CRYPTO_BACKEND_LAST: + break; + } + + if (virDomainDeviceInfoParseXML(node, NULL, &def->info, flags) < 0) + goto error; + +cleanup: + VIR_FREE(model); + VIR_FREE(backend); + VIR_FREE(queues); + VIR_FREE(backends); + ctxt->node = save; + return def; + +error: + virDomainCryptoDefFree(def); + def = NULL; + goto cleanup; +} + + static virDomainMemballoonDefPtr virDomainMemballoonDefParseXML(xmlNodePtr node, xmlXPathContextPtr ctxt, @@ -13368,6 +13476,10 @@ virDomainDeviceDefParse(const char *xmlStr, if (!(dev->data.rng = virDomainRNGDefParseXML(node, ctxt, flags))) goto error; break; + case VIR_DOMAIN_DEVICE_CRYPTO: + if (!(dev->data.crypto = virDomainCryptoDefParseXML(node, ctxt, flags))) + goto error; + break; case VIR_DOMAIN_DEVICE_CHR: if (!(dev->data.chr = virDomainChrDefParseXML(ctxt, node, @@ -17073,6 +17185,22 @@ virDomainDefParseXML(xmlDocPtr xml, } VIR_FREE(nodes); + /* Parse the crypto devices */ + if ((n = virXPathNodeSet("./devices/crypto", ctxt, &nodes)) < 0) + goto error; + if (n && VIR_ALLOC_N(def->cryptos, n) < 0) + goto error; + for (i = 0; i < n; i++) { + virDomainCryptoDefPtr crypto = virDomainCryptoDefParseXML(nodes[i], + ctxt, + flags); + if (!crypto) + goto error; + + def->cryptos[def->ncryptos++] = crypto; + } + VIR_FREE(nodes); + /* Parse the TPM devices */ if ((n = virXPathNodeSet("./devices/tpm", ctxt, &nodes)) < 0) goto error; @@ -18199,6 +18327,25 @@ virDomainRNGDefCheckABIStability(virDomainRNGDefPtr src, static bool +virDomainCryptoDefCheckABIStability(virDomainCryptoDefPtr src, + virDomainCryptoDefPtr dst) +{ + if (src->model != dst->model) { + virReportError(VIR_ERR_CONFIG_UNSUPPORTED, + _("Target Crypto model '%s' does not match source '%s'"), + virDomainCryptoModelTypeToString(dst->model), + virDomainCryptoModelTypeToString(src->model)); + return false; + } + + if (!virDomainDeviceInfoCheckABIStability(&src->info, &dst->info)) + return false; + + return true; +} + + +static bool virDomainHubDefCheckABIStability(virDomainHubDefPtr src, virDomainHubDefPtr dst) { @@ -18933,6 +19080,17 @@ virDomainDefCheckABIStability(virDomainDefPtr src, if (!virDomainRNGDefCheckABIStability(src->rngs[i], dst->rngs[i])) goto error; + if (src->ncryptos != dst->ncryptos) { + virReportError(VIR_ERR_CONFIG_UNSUPPORTED, + _("Target domain crypto device count %zu " + "does not match source %zu"), dst->ncryptos, src->ncryptos); + goto error; + } + + for (i = 0; i < src->ncryptos; i++) + if (!virDomainCryptoDefCheckABIStability(src->cryptos[i], dst->cryptos[i])) + goto error; + if (src->npanics != dst->npanics) { virReportError(VIR_ERR_CONFIG_UNSUPPORTED, _("Target domain panic device count %zu " @@ -19007,6 +19165,7 @@ virDomainDefCheckABIStability(virDomainDefPtr src, case VIR_DOMAIN_DEVICE_NVRAM: case VIR_DOMAIN_DEVICE_LAST: case VIR_DOMAIN_DEVICE_RNG: + case VIR_DOMAIN_DEVICE_CRYPTO: case VIR_DOMAIN_DEVICE_TPM: case VIR_DOMAIN_DEVICE_PANIC: case VIR_DOMAIN_DEVICE_SHMEM: @@ -21590,6 +21749,51 @@ virDomainRNGDefFree(virDomainRNGDefPtr def) static int +virDomainCryptoDefFormat(virBufferPtr buf, + virDomainCryptoDefPtr def, + unsigned int flags) +{ + const char *model = virDomainCryptoModelTypeToString(def->model); + const char *backend = virDomainCryptoBackendTypeToString(def->backend); + + virBufferAsprintf(buf, "<crypto model='%s'>\n", model); + virBufferAdjustIndent(buf, 2); + virBufferAsprintf(buf, "<backend type='%s'", backend); + + switch ((virDomainCryptoBackend) def->backend) { + case VIR_DOMAIN_CRYPTO_BACKEND_BUILTIN: + if (def->queues) + virBufferAsprintf(buf, " queues='%u'", def->queues); + + virBufferAddLit(buf, "/>\n"); + break; + + case VIR_DOMAIN_CRYPTO_BACKEND_LAST: + break; + } + + if (virDomainDeviceInfoNeedsFormat(&def->info, flags)) { + if (virDomainDeviceInfoFormat(buf, &def->info, flags) < 0) + return -1; + } + + virBufferAdjustIndent(buf, -2); + virBufferAddLit(buf, "</crypto>\n"); + return 0; +} + +void +virDomainCryptoDefFree(virDomainCryptoDefPtr def) +{ + if (!def) + return; + + virDomainDeviceInfoClear(&def->info); + VIR_FREE(def); +} + + +static int virDomainMemorySourceDefFormat(virBufferPtr buf, virDomainMemoryDefPtr def) { @@ -23539,6 +23743,11 @@ virDomainDefFormatInternal(virDomainDefPtr def, goto error; } + for (n = 0; n < def->ncryptos; n++) { + if (virDomainCryptoDefFormat(buf, def->cryptos[n], flags)) + goto error; + } + if (def->nvram) virDomainNVRAMDefFormat(buf, def->nvram, flags); @@ -24657,6 +24866,9 @@ virDomainDeviceDefCopy(virDomainDeviceDefPtr src, case VIR_DOMAIN_DEVICE_RNG: rc = virDomainRNGDefFormat(&buf, src->data.rng, flags); break; + case VIR_DOMAIN_DEVICE_CRYPTO: + rc = virDomainCryptoDefFormat(&buf, src->data.crypto, flags); + break; case VIR_DOMAIN_DEVICE_CHR: rc = virDomainChrDefFormat(&buf, src->data.chr, flags); break; diff --git a/src/conf/domain_conf.h b/src/conf/domain_conf.h index ba0ad5f..995ce8f 100644 --- a/src/conf/domain_conf.h +++ b/src/conf/domain_conf.h @@ -127,6 +127,9 @@ typedef virDomainSnapshotObjList *virDomainSnapshotObjListPtr; typedef struct _virDomainRNGDef virDomainRNGDef; typedef virDomainRNGDef *virDomainRNGDefPtr; +typedef struct _virDomainCryptoDef virDomainCryptoDef; +typedef virDomainCryptoDef *virDomainCryptoDefPtr; + typedef struct _virDomainIdMapEntry virDomainIdMapEntry; typedef virDomainIdMapEntry *virDomainIdMapEntryPtr; @@ -172,6 +175,7 @@ typedef enum { VIR_DOMAIN_DEVICE_MEMBALLOON, VIR_DOMAIN_DEVICE_NVRAM, VIR_DOMAIN_DEVICE_RNG, + VIR_DOMAIN_DEVICE_CRYPTO, VIR_DOMAIN_DEVICE_SHMEM, VIR_DOMAIN_DEVICE_TPM, VIR_DOMAIN_DEVICE_PANIC, @@ -203,6 +207,7 @@ struct _virDomainDeviceDef { virDomainMemballoonDefPtr memballoon; virDomainNVRAMDefPtr nvram; virDomainRNGDefPtr rng; + virDomainCryptoDefPtr crypto; virDomainShmemDefPtr shmem; virDomainTPMDefPtr tpm; virDomainPanicDefPtr panic; @@ -1927,6 +1932,26 @@ struct _virDomainRNGDef { }; typedef enum { + VIR_DOMAIN_CRYPTO_MODEL_VIRTIO, + + VIR_DOMAIN_CRYPTO_MODEL_LAST +} virDomainCryptoModel; + +typedef enum { + VIR_DOMAIN_CRYPTO_BACKEND_BUILTIN, + + VIR_DOMAIN_CRYPTO_BACKEND_LAST +} virDomainCryptoBackend; + +struct _virDomainCryptoDef { + int model; + int backend; + unsigned int queues; /* Multiqueue virtio-crypto */ + + virDomainDeviceInfo info; +}; + +typedef enum { VIR_DOMAIN_MEMORY_MODEL_NONE, VIR_DOMAIN_MEMORY_MODEL_DIMM, /* dimm hotpluggable memory device */ @@ -2218,6 +2243,9 @@ struct _virDomainDef { size_t nrngs; virDomainRNGDefPtr *rngs; + size_t ncryptos; + virDomainCryptoDefPtr *cryptos; + size_t nshmems; virDomainShmemDefPtr *shmems; @@ -2696,6 +2724,8 @@ int virDomainDefCompatibleDevice(virDomainDefPtr def, void virDomainRNGDefFree(virDomainRNGDefPtr def); +void virDomainCryptoDefFree(virDomainCryptoDefPtr def); + int virDomainDiskIndexByAddress(virDomainDefPtr def, virPCIDeviceAddressPtr pci_controller, unsigned int bus, unsigned int target, @@ -2996,6 +3026,8 @@ VIR_ENUM_DECL(virDomainHyperv) VIR_ENUM_DECL(virDomainKVM) VIR_ENUM_DECL(virDomainRNGModel) VIR_ENUM_DECL(virDomainRNGBackend) +VIR_ENUM_DECL(virDomainCryptoModel) +VIR_ENUM_DECL(virDomainCryptoBackend) VIR_ENUM_DECL(virDomainTPMModel) VIR_ENUM_DECL(virDomainTPMBackend) VIR_ENUM_DECL(virDomainMemoryModel) diff --git a/src/qemu/qemu_alias.c b/src/qemu/qemu_alias.c index d624071..25b87d2 100644 --- a/src/qemu/qemu_alias.c +++ b/src/qemu/qemu_alias.c @@ -331,6 +331,26 @@ qemuAssignDeviceRNGAlias(virDomainDefPtr def, int +qemuAssignDeviceCryptoAlias(const virDomainDef *def, + virDomainCryptoDefPtr crypto) +{ + size_t i; + int maxidx = 0; + int idx; + + for (i = 0; i < def->ncryptos; i++) { + if ((idx = qemuDomainDeviceAliasIndex(&def->cryptos[i]->info, "crypto")) >= maxidx) + maxidx = idx + 1; + } + + if (virAsprintf(&crypto->info.alias, "crypto%d", maxidx) < 0) + return -1; + + return 0; +} + + +int qemuAssignDeviceMemoryAlias(virDomainDefPtr def, virDomainMemoryDefPtr mem) { diff --git a/src/qemu/qemu_alias.h b/src/qemu/qemu_alias.h index e328a9b..4ae1c92 100644 --- a/src/qemu/qemu_alias.h +++ b/src/qemu/qemu_alias.h @@ -57,6 +57,10 @@ int qemuAssignDeviceRedirdevAlias(virDomainDefPtr def, int qemuAssignDeviceRNGAlias(virDomainDefPtr def, virDomainRNGDefPtr rng); +int +qemuAssignDeviceCryptoAlias(const virDomainDef *def, + virDomainCryptoDefPtr crypto); + int qemuAssignDeviceMemoryAlias(virDomainDefPtr def, virDomainMemoryDefPtr mems); diff --git a/src/qemu/qemu_capabilities.c b/src/qemu/qemu_capabilities.c index 2c0b29d..b1b718b 100644 --- a/src/qemu/qemu_capabilities.c +++ b/src/qemu/qemu_capabilities.c @@ -337,6 +337,8 @@ VIR_ENUM_IMPL(virQEMUCaps, QEMU_CAPS_LAST, "drive-detect-zeroes", "tls-creds-x509", /* 230 */ + "cryptodev-backend-builtin", + "virtio-crypto", ); @@ -1565,6 +1567,8 @@ struct virQEMUCapsStringFlags virQEMUCapsObjectTypes[] = { { "pxb", QEMU_CAPS_DEVICE_PXB }, { "pxb-pcie", QEMU_CAPS_DEVICE_PXB_PCIE }, { "tls-creds-x509", QEMU_CAPS_OBJECT_TLS_CREDS_X509 }, + { "cryptodev-backend-builtin", QEMU_CAPS_OBJECT_CRYPTO_BUILTIN }, + { "virtio-crypto-device", QEMU_CAPS_DEVICE_VIRTIO_CRYPTO }, }; static struct virQEMUCapsStringFlags virQEMUCapsObjectPropsVirtioBalloon[] = { diff --git a/src/qemu/qemu_capabilities.h b/src/qemu/qemu_capabilities.h index affb639..98cb817 100644 --- a/src/qemu/qemu_capabilities.h +++ b/src/qemu/qemu_capabilities.h @@ -370,6 +370,8 @@ typedef enum { /* 230 */ QEMU_CAPS_OBJECT_TLS_CREDS_X509, /* -object tls-creds-x509 */ + QEMU_CAPS_OBJECT_CRYPTO_BUILTIN, + QEMU_CAPS_DEVICE_VIRTIO_CRYPTO, QEMU_CAPS_LAST /* this must always be the last item */ } virQEMUCapsFlags; diff --git a/src/qemu/qemu_command.c b/src/qemu/qemu_command.c index 3898ed7..8cf1258 100644 --- a/src/qemu/qemu_command.c +++ b/src/qemu/qemu_command.c @@ -5451,6 +5451,132 @@ qemuBuildRNGCommandLine(virLogManagerPtr logManager, } +static char * +qemuBuildCryptoBackendStr(virDomainCryptoDefPtr crypto, + virQEMUCapsPtr qemuCaps) +{ + const char *type = NULL; + char *alias = NULL; + char *queue = NULL; + char *ret = NULL; + virBuffer buf = VIR_BUFFER_INITIALIZER; + + if (virAsprintf(&alias, "obj%s", crypto->info.alias) < 0) + goto cleanup; + + if (crypto->queues > 1) { + if (virAsprintf(&queue, ",queues=%u", crypto->queues) < 0) + goto cleanup; + } + + switch ((virDomainCryptoBackend)crypto->backend) { + case VIR_DOMAIN_CRYPTO_BACKEND_BUILTIN: + if (!virQEMUCapsGet(qemuCaps, QEMU_CAPS_OBJECT_CRYPTO_BUILTIN)) { + virReportError(VIR_ERR_CONFIG_UNSUPPORTED, "%s", + _("this qemu doesn't support the crypto-backend" + "-builtin")); + goto cleanup; + } + + type = "cryptodev-backend-builtin"; + break; + + case VIR_DOMAIN_CRYPTO_BACKEND_LAST: + virReportError(VIR_ERR_CONFIG_UNSUPPORTED, "%s", + _("unknown crypto backend")); + goto cleanup; + } + + virBufferAsprintf(&buf, "%s,id=%s%s", type, alias, queue); + + ret = virBufferContentAndReset(&buf); + +cleanup: + VIR_FREE(alias); + return ret; +} + + +char * +qemuBuildCryptoDevStr(const virDomainDef *def, + virDomainCryptoDefPtr dev, + virQEMUCapsPtr qemuCaps) +{ + virBuffer buf = VIR_BUFFER_INITIALIZER; + + if (dev->model != VIR_DOMAIN_CRYPTO_MODEL_VIRTIO || + !virQEMUCapsGet(qemuCaps, QEMU_CAPS_DEVICE_VIRTIO_CRYPTO)) { + virReportError(VIR_ERR_CONFIG_UNSUPPORTED, + _("this qemu doesn't support crypto device model '%s'"), + virDomainRNGModelTypeToString(dev->model)); + goto error; + } + + if (dev->info.type != VIR_DOMAIN_DEVICE_ADDRESS_TYPE_PCI) { + virReportError(VIR_ERR_CONFIG_UNSUPPORTED, + _("this qemu only support crypto device PCI address type")); + goto error; + } + + virBufferAsprintf(&buf, "virtio-crypto-pci,cryptodev=obj%s,id=%s", + dev->info.alias, dev->info.alias); + + if (qemuBuildDeviceAddressStr(&buf, def, &dev->info, qemuCaps) < 0) + goto error; + + if (virBufferCheckError(&buf) < 0) + goto error; + + return virBufferContentAndReset(&buf); + +error: + virBufferFreeAndReset(&buf); + return NULL; +} + + +static int +qemuBuildCryptoCommandLine(virCommandPtr cmd, + const virDomainDef *def, + virQEMUCapsPtr qemuCaps) +{ + size_t i; + + for (i = 0; i < def->ncryptos; i++) { + virDomainCryptoDefPtr crypto = def->cryptos[i]; + char *tmp; + + if (qemuAssignDeviceCryptoAlias(def, crypto)) { + virReportError(VIR_ERR_INTERNAL_ERROR, "%s", + _("crypto device assign alias faile")); + return -1; + } + + if (!crypto->info.alias) { + virReportError(VIR_ERR_INTERNAL_ERROR, "%s", + _("crypto device is missing alias")); + return -1; + } + + /* add the Crypto backend */ + if (!(tmp = qemuBuildCryptoBackendStr(crypto, qemuCaps))) + return -1; + + virCommandAddArgList(cmd, "-object", tmp, NULL); + VIR_FREE(tmp); + + /* add the device */ + if (!(tmp = qemuBuildCryptoDevStr(def, crypto, qemuCaps))) + return -1; + + virCommandAddArgList(cmd, "-device", tmp, NULL); + VIR_FREE(tmp); + } + + return 0; +} + + static char *qemuBuildSmbiosBiosStr(virSysinfoBIOSDefPtr def) { virBuffer buf = VIR_BUFFER_INITIALIZER; @@ -9312,6 +9438,9 @@ qemuBuildCommandLine(virQEMUDriverPtr driver, if (qemuBuildRNGCommandLine(logManager, cmd, cfg, def, qemuCaps) < 0) goto error; + if (qemuBuildCryptoCommandLine(cmd, def, qemuCaps) < 0) + goto error; + if (qemuBuildNVRAMCommandLine(cmd, def, qemuCaps) < 0) goto error; diff --git a/src/qemu/qemu_command.h b/src/qemu/qemu_command.h index c4d0567..ec9b3ac 100644 --- a/src/qemu/qemu_command.h +++ b/src/qemu/qemu_command.h @@ -143,6 +143,10 @@ int qemuBuildRNGBackendProps(virDomainRNGDefPtr rng, const char **type, virJSONValuePtr *props); +char *qemuBuildCryptoDevStr(const virDomainDef *def, + virDomainCryptoDefPtr dev, + virQEMUCapsPtr qemuCaps); + char *qemuBuildShmemDevStr(virDomainDefPtr def, virDomainShmemDefPtr shmem, virQEMUCapsPtr qemuCaps); diff --git a/src/qemu/qemu_domain_address.c b/src/qemu/qemu_domain_address.c index ee44d45..26e6caa 100644 --- a/src/qemu/qemu_domain_address.c +++ b/src/qemu/qemu_domain_address.c @@ -328,6 +328,12 @@ qemuDomainPrimeVirtioDeviceAddresses(virDomainDefPtr def, def->rngs[i]->info.type = type; } + for (i = 0; i < def->ncryptos; i++) { + if (def->cryptos[i]->model == VIR_DOMAIN_CRYPTO_MODEL_VIRTIO && + def->cryptos[i]->info.type == VIR_DOMAIN_DEVICE_ADDRESS_TYPE_NONE) + def->cryptos[i]->info.type = type; + } + if (type == VIR_DOMAIN_DEVICE_ADDRESS_TYPE_CCW) { for (i = 0; i < def->nfss; i++) { if (def->fss[i]->info.type == VIR_DOMAIN_DEVICE_ADDRESS_TYPE_NONE) @@ -1236,6 +1242,17 @@ qemuDomainAssignDevicePCISlots(virDomainDefPtr def, goto error; } + /* VirtIO CRYPTO */ + for (i = 0; i < def->ncryptos; i++) { + if (def->cryptos[i]->model != VIR_DOMAIN_CRYPTO_MODEL_VIRTIO || + !virDeviceInfoPCIAddressWanted(&def->cryptos[i]->info)) + continue; + + if (virDomainPCIAddressReserveNextSlot(addrs, + &def->cryptos[i]->info, flags) < 0) + goto error; + } + /* A watchdog - check if it is a PCI device */ if (def->watchdog && def->watchdog->model == VIR_DOMAIN_WATCHDOG_MODEL_I6300ESB && diff --git a/src/qemu/qemu_driver.c b/src/qemu/qemu_driver.c index 2089359..a28a3c2 100644 --- a/src/qemu/qemu_driver.c +++ b/src/qemu/qemu_driver.c @@ -7431,6 +7431,7 @@ qemuDomainAttachDeviceLive(virDomainObjPtr vm, case VIR_DOMAIN_DEVICE_SHMEM: case VIR_DOMAIN_DEVICE_TPM: case VIR_DOMAIN_DEVICE_PANIC: + case VIR_DOMAIN_DEVICE_CRYPTO: case VIR_DOMAIN_DEVICE_LAST: virReportError(VIR_ERR_OPERATION_UNSUPPORTED, _("live attach of device '%s' is not supported"), @@ -7522,6 +7523,7 @@ qemuDomainDetachDeviceLive(virDomainObjPtr vm, case VIR_DOMAIN_DEVICE_NONE: case VIR_DOMAIN_DEVICE_TPM: case VIR_DOMAIN_DEVICE_PANIC: + case VIR_DOMAIN_DEVICE_CRYPTO: case VIR_DOMAIN_DEVICE_LAST: virReportError(VIR_ERR_OPERATION_UNSUPPORTED, _("live detach of device '%s' is not supported"), @@ -7637,6 +7639,7 @@ qemuDomainUpdateDeviceLive(virConnectPtr conn, case VIR_DOMAIN_DEVICE_NONE: case VIR_DOMAIN_DEVICE_TPM: case VIR_DOMAIN_DEVICE_PANIC: + case VIR_DOMAIN_DEVICE_CRYPTO: case VIR_DOMAIN_DEVICE_LAST: virReportError(VIR_ERR_CONFIG_UNSUPPORTED, _("live update of device '%s' is not supported"), @@ -7800,6 +7803,7 @@ qemuDomainAttachDeviceConfig(virDomainDefPtr vmdef, case VIR_DOMAIN_DEVICE_NONE: case VIR_DOMAIN_DEVICE_TPM: case VIR_DOMAIN_DEVICE_PANIC: + case VIR_DOMAIN_DEVICE_CRYPTO: case VIR_DOMAIN_DEVICE_LAST: virReportError(VIR_ERR_OPERATION_UNSUPPORTED, _("persistent attach of device '%s' is not supported"), @@ -7954,6 +7958,7 @@ qemuDomainDetachDeviceConfig(virDomainDefPtr vmdef, case VIR_DOMAIN_DEVICE_NONE: case VIR_DOMAIN_DEVICE_TPM: case VIR_DOMAIN_DEVICE_PANIC: + case VIR_DOMAIN_DEVICE_CRYPTO: case VIR_DOMAIN_DEVICE_LAST: virReportError(VIR_ERR_OPERATION_UNSUPPORTED, _("persistent detach of device '%s' is not supported"), @@ -8052,6 +8057,7 @@ qemuDomainUpdateDeviceConfig(virDomainDefPtr vmdef, case VIR_DOMAIN_DEVICE_NONE: case VIR_DOMAIN_DEVICE_TPM: case VIR_DOMAIN_DEVICE_PANIC: + case VIR_DOMAIN_DEVICE_CRYPTO: case VIR_DOMAIN_DEVICE_LAST: virReportError(VIR_ERR_OPERATION_UNSUPPORTED, _("persistent update of device '%s' is not supported"), diff --git a/src/qemu/qemu_hotplug.c b/src/qemu/qemu_hotplug.c index 093aaf9..c1cfb76 100644 --- a/src/qemu/qemu_hotplug.c +++ b/src/qemu/qemu_hotplug.c @@ -3301,6 +3301,7 @@ qemuDomainRemoveDevice(virQEMUDriverPtr driver, case VIR_DOMAIN_DEVICE_TPM: case VIR_DOMAIN_DEVICE_PANIC: case VIR_DOMAIN_DEVICE_LAST: + case VIR_DOMAIN_DEVICE_CRYPTO: virReportError(VIR_ERR_OPERATION_UNSUPPORTED, _("don't know how to remove a %s device"), virDomainDeviceTypeToString(dev->type)); -- 1.8.3.1

4 3

[libvirt] [PATCH] virutil: Provide non-linux impl for virGetFCHostNameByFabricWWN
by Michal Privoznik 09 Jan '17

09 Jan '17

Currently, there's only linux implementation for virGetFCHostNameByFabricWWN(). Since the symbol is exported in our private symbols we ought to have implementation for other platforms too. This also triggers compilation error on FreeBSD: ../src/.libs/libvirt_driver_storage_impl.a(libvirt_driver_storage_impl_la-storage_backend_scsi.o): In function `createVport': /usr/home/jenkins/libvirt-master/systems/libvirt-freebsd/build/src/../../src/storage/storage_backend_scsi.c:740: undefined reference to `virGetFCHostNameByFabricWWN' Signed-off-by: Michal Privoznik <mprivozn(a)redhat.com> --- Pushed under trivial and build-breaker rules. src/util/virutil.c | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/src/util/virutil.c b/src/util/virutil.c index da836b46d..aeaa7f98e 100644 --- a/src/util/virutil.c +++ b/src/util/virutil.c @@ -2480,6 +2480,14 @@ virGetFCHostNameByWWN(const char *sysfs_prefix ATTRIBUTE_UNUSED, return NULL; } +char * +virGetFCHostNameByFabricWWN(const char *sysfs_prefix ATTRIBUTE_UNUSED, + const char *fabric_wwn ATTRIBUTE_UNUSED) +{ + virReportSystemError(ENOSYS, "%s", _("Not supported on this platform")); + return NULL; +} + char * virFindFCHostCapableVport(const char *sysfs_prefix ATTRIBUTE_UNUSED) { -- 2.11.0

1 0

Re: [libvirt] [Qemu-devel] [PATCH 0/5] Use non-blacklisted family/model/stepping for Haswell CPU model
by Eduardo Habkost 08 Jan '17

08 Jan '17

Oops, there are 3 actual mistakes I missed among the false positives, below: On Sun, Jan 08, 2017 at 11:47:21AM -0800, no-reply(a)patchew.org wrote: [...] > === OUTPUT BEGIN === > Checking PATCH 1/5: i386: Add explicit array size to x86_cpu_vendor_words2str()... > ERROR: line over 90 characters > #27: FILE: target/i386/cpu.c:172: > +static void x86_cpu_vendor_words2str(char dst[static (CPUID_VENDOR_SZ + 1)], uint32_t vendor1, False positive. > > ERROR: space prohibited between function name and open parenthesis '(' > #27: FILE: target/i386/cpu.c:172: > +static void x86_cpu_vendor_words2str(char dst[static (CPUID_VENDOR_SZ + 1)], uint32_t vendor1, False positive. > > total: 2 errors, 0 warnings, 8 lines checked > > Your patch has style problems, please review. If any of these errors > are false positives report them to the maintainer, see > CHECKPATCH in MAINTAINERS. > > Checking PATCH 2/5: i386: host_vendor_fms() helper function... > ERROR: line over 90 characters > #20: FILE: target/i386/cpu.c:685: > +void host_vendor_fms(char vendor[static (CPUID_VENDOR_SZ + 1)], int *family, int *model, int *stepping) Oops, will fix it. > > ERROR: space prohibited between function name and open parenthesis '(' > #20: FILE: target/i386/cpu.c:685: > +void host_vendor_fms(char vendor[static (CPUID_VENDOR_SZ + 1)], int *family, int *model, int *stepping) False positive. > > ERROR: storage class should be at the beginning of the declaration > #20: FILE: target/i386/cpu.c:685: > +void host_vendor_fms(char vendor[static (CPUID_VENDOR_SZ + 1)], int *family, int *model, int *stepping) > False positive. > ERROR: line over 90 characters > #57: FILE: target/i386/cpu.c:1599: > + host_vendor_fms(host_cpudef.vendor, &host_cpudef.family, &host_cpudef.model, &host_cpudef.stepping); Will fix it. > > ERROR: line over 90 characters > #69: FILE: target/i386/cpu.h:1426: > +void host_vendor_fms(char vendor[static (CPUID_VENDOR_SZ + 1)], int *family, int *model, int *stepping); Will fix it. > > ERROR: space prohibited between function name and open parenthesis '(' > #69: FILE: target/i386/cpu.h:1426: > +void host_vendor_fms(char vendor[static (CPUID_VENDOR_SZ + 1)], int *family, int *model, int *stepping); False positive. > > ERROR: storage class should be at the beginning of the declaration > #69: FILE: target/i386/cpu.h:1426: > +void host_vendor_fms(char vendor[static (CPUID_VENDOR_SZ + 1)], int *family, int *model, int *stepping); False positive. > > total: 7 errors, 0 warnings, 50 lines checked > > Your patch has style problems, please review. If any of these errors > are false positives report them to the maintainer, see > CHECKPATCH in MAINTAINERS. > > Checking PATCH 3/5: i386/kvm: Blacklist TSX on known broken hosts... > Checking PATCH 4/5: pc: Add 2.9 machine-types... > Checking PATCH 5/5: i386: Change stepping of Haswell to non-blacklisted value... > === OUTPUT END === > > Test command exited with code: 1 > > > --- > Email generated automatically by Patchew [http://patchew.org/] > Please send your feedback to patchew-devel(a)freelists.org -- Eduardo

1 0

[libvirt] memory-ballooning side-channel attack
by bancfc＠openmailbox.org 08 Jan '17

08 Jan '17

Hello and Happy Holidays, In the past few years many serious attacks against the memory deduplication (KSM) feature of all hypervisors have been shown. [1] Even allowing attackers to modify/steal APT keys and source lists on the host. [2] Since its not enabled by default the fall out is relatively low and easily mitigated. New side-channel attacks against memory-ballon enabled VMs are beginning to surface. Please consider documenting this and disabling this feature for newly created VMs to have safe defaults. [1] https://staff.aist.go.jp/c.artho/papers/EuroSec2011-suzaki.pdf [2] https://www.usenix.org/system/files/conference/usenixsecurity16/sec16_paper… [3] http://ieeexplore.ieee.org/document/7562068/ *Hint: If you can't see the IEEE paper use sci-hub.

1 1

Re: [libvirt] [Qemu-devel] [PATCH v2 0/2] Allow migration with invtsc if TSC frequency is explicitly set
by Eduardo Habkost 08 Jan '17

08 Jan '17

On Sun, Jan 08, 2017 at 09:19:49AM -0800, no-reply(a)patchew.org wrote: > Hi, > > Your series failed automatic build test. Please find the testing commands and > their output below. If you have docker installed, you can probably reproduce it > locally. > > Type: series > Message-id: 20170108171330.11129-1-ehabkost(a)redhat.com > Subject: [Qemu-devel] [PATCH v2 0/2] Allow migration with invtsc if TSC frequency is explicitly set Ouch. I simply removed patches 3/4 and 4/4 from the series, and didn't notice there was a mistake in patch 1/2 corrected by patch 4/4 in v1. I will fix it and send v3, sorry for the noise. -- Eduardo

1 0

[libvirt] [PATCH v2 0/2] Allow migration with invtsc if TSC frequency is explicitly set
by Eduardo Habkost 08 Jan '17

08 Jan '17

This series makes QEMU accept migration if tsc-frequency is explicitly set on configuration. As management software is required to keep device configuration the same on migration source or destination, explicit tsc-frequency will ensure that either: * The destination host has a matching TSC frequency; or * The destination host has TSC scaling available. Changes series v1 -> v2 ======================= * v1 series subject was: * [PATCH 0/4] Allow migration with invtsc if there's no frequency mismatch * Removed patches 3/4 and 4/4, that allowed migration if no explicit tsc-frequency was set. Implementing the check on post_load or post_init is not enough to make migration abort, so we will need a more complex solution to implement that feature. Plans for future work ===================== 1) Querying host TSC frequency/scaling capability ------------------------------------------------- I plan to include TSC frequency/scaling information on query-cpu-model-expansion model="host" in a future series. Then management software will be able to automatically configure TSC frequency when invtsc is enabled, instead of requiring the user to configure it explicitly. While we don't implement that, invtsc migration will be possible only if the user configures TSC frequency manually. 2) invtsc migration with no explicit TSC frequency -------------------------------------------------- A future series can implement migration when TSC frequency is not specified explicitly. It will be a bit more complex because it requires either letting the destination abort the migration, or sending TSC frequency/scaling information from destination to source. --- Cc: Marcelo Tosatti <mtosatti(a)redhat.com> Cc: "Daniel P. Berrange" <berrange(a)redhat.com> Cc: Paolo Bonzini <pbonzini(a)redhat.com> Cc: kvm(a)vger.kernel.org Cc: Haozhong Zhang <haozhong.zhang(a)intel.com> Cc: "Michael S. Tsirkin" <mst(a)redhat.com> Cc: Igor Mammedov <imammedo(a)redhat.com> Cc: libvir-list(a)redhat.com Cc: Jiri Denemark <jdenemar(a)redhat.com> Eduardo Habkost (2): kvm: Simplify invtsc check kvm: Allow invtsc migration if tsc-khz is set explicitly target/i386/kvm.c | 19 ++++++++++--------- 1 file changed, 10 insertions(+), 9 deletions(-) -- 2.11.0.259.g40922b1

1 0

[libvirt] Regarding Migration Code
by Anubhav Guleria 08 Jan '17

08 Jan '17

Greetings, I was trying to understand the flow of Migration Code in libvirt and have few doubts: 1) libvirt talks to QEMU/KVM guests via QEMU API. So overall, in order to manage QEMU/KVM guests I can either use libvirt (or tools based on libvirt like virsh) or QEMU monitor. Is it so? 2) Since libvirt is Hypervisor neutral so actual migration algorithm(precopy or postcopy) is present in the hypervisor ,i.e. in case of QEMU it should be present in QEMU code base . I was going through the code starting from libvirt-domain api and not able to follow after virDomainMigrateVersion3Full(.....) . Kindly help. 3) I want to determine the Migration Time, Downtime and other resource usage. What is the correct way to determine the same? Should I use libvirt API or directly virsh or something else? Which is fast and efficient way for the same? Thanks in advance. And sorry if that was too basic

1 0