{"push_id":754618437,"size":56,"distinct_size":1,"ref":"refs/heads/spec","head":"50b5774322738a1614d79b2cdd5ef7103e9f92e9","before":"12132ff187b86dfd3c167f789ca8b6715fc33233","commits":[{"sha":"f8fe8f03455783afcd62d79db7ce4120f514c629","author":{"email":"c23361c43fbf79fed83e8b76173707b083d6caf5@laine.org","name":"Laine Stump"},"message":"conf: more useful error message when pci function is out of range\n\nIf a pci address had a function number out of range, the error message\nwould be:\n\n  Insufficient specification for PCI address\n\nwhich is logged by virDevicePCIAddressParseXML() after\nvirDevicePCIAddressIsValid returns a failure.\n\nThis patch enhances virDevicePCIAddressIsValid() to optionally report\nthe error itself (since it is the place that decides which part of the\naddress is \"invalid\"), and uses that feature when calling from\nvirDevicePCIAddressParseXML(), so that the error will be more useful,\ne.g.:\n\n  Invalid PCI address function=0x8, must be <= 7\n\nPreviously, virDevicePCIAddressIsValid didn't check for the\ntheoretical limits of domain or bus, only for slot or function. While\nadding log messages, we also correct that ommission. (The RNG for PCI\naddresses already enforces this limit, which by the way means that we\ncan't add any negative tests for this - as far as I know our\ndomainschematest has no provisions for passing XML that is supposed to\nfail).\n\nNote that virDevicePCIAddressIsValid() can only check against the\nabsolute maximum attribute values for *any* possible PCI controller,\nnot for the actual maximums of the specific controller that this\ndevice is attaching to; fortunately there is later more specific\nvalidation for guest-side PCI addresses when building the set of\nassigned PCI addresses. For host-side PCI addresses (e.g. for\n<hostdev> and for network device pools), we rely on the error that\nwill be logged when it is found that the device doesn't actually\nexist.\n\nThis resolves:\n\n  https://bugzilla.redhat.com/show_bug.cgi?id=1004596","distinct":false,"url":"https://api.github.com/repos/zippy2/libvirt/commits/f8fe8f03455783afcd62d79db7ce4120f514c629"},{"sha":"bf20251048534022efe21785f98949c772ce7a71","author":{"email":"c23361c43fbf79fed83e8b76173707b083d6caf5@laine.org","name":"Laine Stump"},"message":"conf: add new <model> subelement with name attribute to <controller>\n\nThis new subelement is used in PCI controllers: the toplevel\n*attribute* \"model\" of a controller denotes what kind of PCI\ncontroller is being described, e.g. a \"dmi-to-pci-bridge\",\n\"pci-bridge\", or \"pci-root\". But in the future there will be different\nimplementations of some of those types of PCI controllers, which\nbehave similarly from libvirt's point of view (and so should have the\nsame model), but use a different device in qemu (and present\nthemselves as a different piece of hardware in the guest). In an ideal\nworld we (i.e. \"I\") would have thought of that back when the pci\ncontrollers were added, and used some sort of type/class/model\nnotation (where class was used in the way we are now using model, and\nmodel was used for the actual manufacturer's model number of a\nparticular family of PCI controller), but that opportunity is long\npast, so as an alternative, this patch allows selecting a particular\nimplementation of a pci controller with the \"name\" attribute of the\n<model> subelement, e.g.:\n\n  <controller type='pci' model='dmi-to-pci-bridge' index='1'>\n    <model name='i82801b11-bridge'/>\n  </controller>\n\nIn this case, \"dmi-to-pci-bridge\" is the kind of controller (one that\nhas a single PCIe port upstream, and 32 standard PCI ports downstream,\nwhich are not hotpluggable), and the qemu device to be used to\nimplement this kind of controller is named \"i82801b11-bridge\".\n\nImplementing the above now will allow us in the future to add a new\nkind of dmi-to-pci-bridge that doesn't use qemu's i82801b11-bridge\ndevice, but instead uses something else (which doesn't yet exist, but\nqemu people have been discussing it), all without breaking existing\nconfigs.\n\n(note that for the existing \"pci-bridge\" type of PCI controller, both\nthe model attribute and <model> name are 'pci-bridge'. This is just a\ncoincidence, since it turns out that in this case the device name in\nqemu really is a generic 'pci-bridge' rather than being the name of\nsome real-world chip)","distinct":false,"url":"https://api.github.com/repos/zippy2/libvirt/commits/bf20251048534022efe21785f98949c772ce7a71"},{"sha":"572ebdbce7c1d629706882f620d640fc611a9642","author":{"email":"c23361c43fbf79fed83e8b76173707b083d6caf5@laine.org","name":"Laine Stump"},"message":"qemu: implement <model> subelement to <controller>\n\nThis patch provides qemu support for the contents of <model> in\n<controller> for the two existing PCI controller types that need it\n(i.e. the two controller types that are backed by a device that must\nbe specified on the qemu commandline):\n\n1) pci-bridge - sets <model> name attribute default as \"pci-bridge\"\n\n2) dmi-to-pci-bridge - sets <model> name attribute default as\n   \"i82801b11-bridge\".\n\nThese both match current hardcoded practice.\n\nThe defaults are set at the end of qemuDomainAssignPCIAddresses().\nThis can't be done earlier because some of the options that will be\nautogenerated need full PCI address info for the controller, and\nbecause qemuDomainAssignPCIAddresses() might create extra controllers\nwhich would need default settings added, and that hasn't yet been done\nat the time the PostParse callbacks are being run.\nqemuDomainAssignPCIAddresses() is still called prior to the XML being\nwritten to disk, though, so the autogenerated defaults are persistent.\n\nqemu capabilities bits aren't checked when the domain is defined, but\nrather when the commandline is actually created (so the domain can\npossibly be defined on a host that doesn't yet have support for the\ngiven device, or a host different from the one where it will\neventually be run). When the commandline is being generated we compare\nthe modelName to known qemu device names implementing the given type\nof controller, and check the capabilities bit for that device.","distinct":false,"url":"https://api.github.com/repos/zippy2/libvirt/commits/572ebdbce7c1d629706882f620d640fc611a9642"},{"sha":"8dc88aeed612aeea1ae0d249ec760938cecce5aa","author":{"email":"c23361c43fbf79fed83e8b76173707b083d6caf5@laine.org","name":"Laine Stump"},"message":"conf: add new <target> subelement with chassisNr attribute to <controller>\n\nThere are some configuration options to some types of pci controllers\nthat are currently automatically derived from other parts of the\ncontroller's configuration. For example, in qemu a pci-bridge\ncontroller has an option that is called \"chassis_nr\"; up until now\nlibvirt has always set chassis_nr to the index of the pci-bridge. So\nthis:\n\n  <controller type='pci' model='pci-bridge' index='2'/>\n\nwill always result in:\n\n  -device pci-bridge,chassis_nr=2,...\n\non the qemu commandline. In the future we may decide there is a better\nway to derive that option, but even in that case we will need for\nexisting domains to retain the same chassis_nr they were using in the\npast - that is something that is visible to the guest so it is part of\nthe guest ABI and changing it would lead to problems for migrating\nguests (or just guests with very picky OSes).\n\nThe <target> subelement has been added as a place to put the new\n\"chassisNr\" attribute that will be filled in by libvirt when it\nauto-generates the chassisNr; it will be saved in the config, then\nreused any time the domain is started:\n\n  <controller type='pci' model='pci-bridge' index='2'>\n    <model type='pci-bridge'/>\n    <target chassisNr='2'/>\n  </controller>\n\nThe one oddity of all this is that if the controller configuration\nis changed (for example to change the index or the pci address\nwhere the controller is plugged in), the items in <target> will\n*not* be re-generated, which might lead to conflict. I can't\nreally see any way around this, but fortunately if there is a\nmaterial conflict qemu will let us know and we will pass that on\nto the user.","distinct":false,"url":"https://api.github.com/repos/zippy2/libvirt/commits/8dc88aeed612aeea1ae0d249ec760938cecce5aa"},{"sha":"18c104516e14ff53ca17760701e99334aae32d29","author":{"email":"c23361c43fbf79fed83e8b76173707b083d6caf5@laine.org","name":"Laine Stump"},"message":"qemu: implement <target chassisNr='n'/> subelement/attribute of <controller>\n\nThis uses the new subelement/attribute in two ways:\n\n1) If a \"pci-bridge\" pci controller has no chassisNr attribute, it\nwill automatically be set to the controller's index as soon as the\ncontroller's PCI address is known (during\nqemuDomainAssignPCIAddresses()).\n\n2) when creating the commandline for a pci-bridge device, chassisNr\nwill be used to set qemu's chassis_nr option (rather than the previous\npractice of hard-coding it to the controller's index).","distinct":false,"url":"https://api.github.com/repos/zippy2/libvirt/commits/18c104516e14ff53ca17760701e99334aae32d29"},{"sha":"408b100a06ce8289c01c352cb6ce64390a76eaf6","author":{"email":"c23361c43fbf79fed83e8b76173707b083d6caf5@laine.org","name":"Laine Stump"},"message":"qemu: add capabilities bit for device ioh3420\n\nThis is a PCIE \"root port\". It connects only to a port of the\nintegrated pcie.0 bus of a Q35 machine (can't be hotplugged), and\nprovides a single PCIe port that can have PCI or PCIe devices\nhotplugged into it.\n\nThis device will be used to implement the \"pcie-root-port\" model of\npci controller.","distinct":false,"url":"https://api.github.com/repos/zippy2/libvirt/commits/408b100a06ce8289c01c352cb6ce64390a76eaf6"},{"sha":"dce3b8beb30f0a0525cccb3ef39d6eedf323e7ab","author":{"email":"c23361c43fbf79fed83e8b76173707b083d6caf5@laine.org","name":"Laine Stump"},"message":"conf: new pci controller model \"pcie-root-port\"\n\nThis controller can be connected (at domain startup time only - not\nhotpluggable) only to a port on the pcie root complex (\"pcie-root\" in\nlibvirt config), hence the new connect type\nVIR_PCI_CONNECT_TYPE_PCIE_ROOT. It provides a hotpluggable port that\nwill accept any PCI or PCIe device.\n\nNew attributes must be added to the controller <target> subelement for\nthis - chassis and port are guest-visible option values that will be\nset by libvirt with values derived from the controller's index and pci\naddress information.","distinct":false,"url":"https://api.github.com/repos/zippy2/libvirt/commits/dce3b8beb30f0a0525cccb3ef39d6eedf323e7ab"},{"sha":"16328520f63280d5de2bc77d8e6874327871b454","author":{"email":"c23361c43fbf79fed83e8b76173707b083d6caf5@laine.org","name":"Laine Stump"},"message":"qemu: support new pci controller model \"pcie-root-port\"\n\nThis is backed by the qemu device ioh3420.\n\nchassis and port from the <target> subelement are used to store/set the\nrespective qemu device options for the ioh3420. Currently, chassis is\nset to be the index of the controller, and port is set to\n\"(slot << 3) + function\" (per suggestion from Alex Williamson).","distinct":false,"url":"https://api.github.com/repos/zippy2/libvirt/commits/16328520f63280d5de2bc77d8e6874327871b454"},{"sha":"4cde758808272ed0fb2fd5a56ed95b311fb87ccd","author":{"email":"c23361c43fbf79fed83e8b76173707b083d6caf5@laine.org","name":"Laine Stump"},"message":"qemu: add capabilities bit for device x3130-upstream\n\nThis is the upstream part of a PCIe switch. It connects to a PCIe port\n(but not PCI) on the upstream side, and can have up to 31\nxio3130-downstream controllers (but no other types of devices)\nconnected to its downstream side.\n\nThis device will be used to implement the \"pcie-switch-upstream-port\"\nmodel of pci controller.","distinct":false,"url":"https://api.github.com/repos/zippy2/libvirt/commits/4cde758808272ed0fb2fd5a56ed95b311fb87ccd"},{"sha":"38ea9515afad21fa71e0717aa3406d938bc225c0","author":{"email":"c23361c43fbf79fed83e8b76173707b083d6caf5@laine.org","name":"Laine Stump"},"message":"conf: new pci controller model \"pcie-switch-upstream-port\"\n\nThis controller can be connected only to a pcie-root-port or a\npcie-switch-downstream-port (which will be added in a later patch),\nwhich is the reason for the new connect type\nVIR_PCI_CONNECT_TYPE_PCIE_PORT. A pcie-switch-upstream-port provides\n32 ports (slot=0 to slot=31) on the downstream side, which can only\nhave pci controllers of model \"pcie-switch-downstream-port\" plugged\ninto them, which is the reason for the other new connect type\nVIR_PCI_CONNECT_TYPE_PCIE_SWITCH.","distinct":false,"url":"https://api.github.com/repos/zippy2/libvirt/commits/38ea9515afad21fa71e0717aa3406d938bc225c0"},{"sha":"cb99086d1b2661a733b5b6757560062e488242e2","author":{"email":"c23361c43fbf79fed83e8b76173707b083d6caf5@laine.org","name":"Laine Stump"},"message":"qemu: support new pci controller model \"pcie-switch-upstream-port\"\n\nthis is backed by the qemu device x3130-upstream. It can only plug\ninto a pcie-root-port or pcie-switch-downstream-port.","distinct":false,"url":"https://api.github.com/repos/zippy2/libvirt/commits/cb99086d1b2661a733b5b6757560062e488242e2"},{"sha":"ad1748a1aa47774f4e2b7bac31d162206fd4103b","author":{"email":"c23361c43fbf79fed83e8b76173707b083d6caf5@laine.org","name":"Laine Stump"},"message":"qemu: add capabilities bit for device xio3130-downstream\n\nThe downstream ports of an x3130-upstream switch can each have one of\nthese plugged into them (and that is the only place they can be\nconnected). Each xio3130-downstream provides a single PCIe port that\ncan have PCI or PCIe devices hotplugged into it. Apparently an entire\nset of x3130-upstream + several xio3130-downstreams can be hotplugged\nas a unit, but it's not clear to me yet how that would be done, since\nqemu only allows attaching a single device at a time.\n\nThis device will be used to implement the\n\"pcie-switch-downstream-port\" model of pci controller.","distinct":false,"url":"https://api.github.com/repos/zippy2/libvirt/commits/ad1748a1aa47774f4e2b7bac31d162206fd4103b"},{"sha":"76379a6ec15c2ffc1fa819766a9c1dcad57953f7","author":{"email":"c23361c43fbf79fed83e8b76173707b083d6caf5@laine.org","name":"Laine Stump"},"message":"conf: new pcie-controller model \"pcie-switch-downstream-port\"\n\nThis controller can be connected only to a port on a\npcie-switch-upstream-port. It provides a single hotpluggable port that\nwill accept any PCI or PCIe device, as well as any device requiring a\npcie-*-port (the only current example of such a device is the\npcie-switch-upstream-port).","distinct":false,"url":"https://api.github.com/repos/zippy2/libvirt/commits/76379a6ec15c2ffc1fa819766a9c1dcad57953f7"},{"sha":"7d69387cd6c49710d76d06f20f0cf9ef5a28aa55","author":{"email":"c23361c43fbf79fed83e8b76173707b083d6caf5@laine.org","name":"Laine Stump"},"message":"qemu: support new pci controller model \"pcie-switch-downstream-port\"\n\nThis is backed by the qemu device xio3130-downstream. It can only be\nconnected to a pcie-switch-upstream-port (x3130-upstream) on the\nupstream side.","distinct":false,"url":"https://api.github.com/repos/zippy2/libvirt/commits/7d69387cd6c49710d76d06f20f0cf9ef5a28aa55"},{"sha":"6a21bc119e37bafcbe5cfd13e57080d651296b43","author":{"email":"c23361c43fbf79fed83e8b76173707b083d6caf5@laine.org","name":"Laine Stump"},"message":"network: verify proper address family in updates to <host> and <range>\n\nBy specifying parentIndex in a call to virNetworkUpdate(), it was\npossible to direct libvirt to add a dhcp range or static host of a\nnon-matching address family to the <dhcp> element of an <ip>. For\nexample, given:\n\n <ip address='192.168.122.1' netmask='255.255.255.0'/>\n <ip family='ipv6' address='2001:db6:ca3:45::1' prefix='64'/>\n\nyou could provide a static host entry with an IPv4 address, and\nspecify that it be added to the 2nd <ip> element (index 1):\n\n  virsh net-update default add ip-dhcp-host --parent-index 1 \\\n  '<host mac=\"52:54:00:00:00:01\" ip=\"192.168.122.45\"/>'\n\nThis would be happily added with no error (and no concern of any\npossible future consequences).\n\nThis patch checks that any dhcp range or host element being added to a\nnetwork ip's <dhcp> subelement has addresses of the same family as the\nip element they are being added to.\n\nThis resolves:\n\n  https://bugzilla.redhat.com/show_bug.cgi?id=1184736","distinct":false,"url":"https://api.github.com/repos/zippy2/libvirt/commits/6a21bc119e37bafcbe5cfd13e57080d651296b43"},{"sha":"bc359f77f34b66c9ff85ff73bcac864ad325781b","author":{"email":"83d82aaba2eed257f4814b0c239c260c4caaadf0@redhat.com","name":"Michal Privoznik"},"message":"virDomainCoreDumpWithFormat: Mention enum for @dumpformat\n\nSo the API takes @dumpformat argument. This is what makes it special\nwhen compared to virDomainCoreDump. The argument is there so that\nusers can choose the format of resulting core dump file. And to ease\nthem the choosing process we even have an enum with supported values\nacross all the hypervisors. But we don't mention the enum in  the\nfunction description anywhere. Fix it!\n\nSigned-off-by: Michal Privoznik <mprivozn@redhat.com>","distinct":false,"url":"https://api.github.com/repos/zippy2/libvirt/commits/bc359f77f34b66c9ff85ff73bcac864ad325781b"},{"sha":"b1ad57ecd2df21a0bdae89a36e3d1daef6023618","author":{"email":"c5578ac32227d61001c24bf78fc872e2c1452ac3@cn.fujitsu.com","name":"Cao jin"},"message":"fix typo in comments\n\nSigned-off-by: Cao jin <caoj.fnst@cn.fujitsu.com>","distinct":false,"url":"https://api.github.com/repos/zippy2/libvirt/commits/b1ad57ecd2df21a0bdae89a36e3d1daef6023618"},{"sha":"a8743c39389b76897811f60dcd8485cd51d76f02","author":{"email":"e82f23e74d43760279ebcc505dac4ae70d5627d0@redhat.com","name":"Martin Kletzander"},"message":"rpc: Remove keepalive_required option\n\nSince its introduction in 2011 (particularly in commit f4324e329275),\nthe option doesn't work.  It just effectively disables all incoming\nconnections.  That's because the client private data that contain the\n'keepalive_supported' boolean, are initialized to zeroes so the bool is\nfalse and the only other place where the bool is used is when checking\nwhether the client supports keepalive.  Thus, according to the server,\nno client supports keepalive.\n\nRemoving this instead of fixing it is better because a) apparently\nnobody ever tried it since 2011 (4 years without one month) and b) we\ncannot know whether the client supports keepalive until we get a ping or\npong keepalive packet.  And that won't happen until after we dispatched\nthe ConnectOpen call.\n\nAnother two reasons would be c) the keepalive_required was tracked on\nthe server level, but keepalive_supported was in private data of the\nclient as well as the check that was made in the remote layer, thus\nmaking all other instances of virNetServer miss this feature unless they\nall implemented it for themselves and d) we can always add it back in\ncase there is a request and a use-case for it.\n\nSigned-off-by: Martin Kletzander <mkletzan@redhat.com>","distinct":false,"url":"https://api.github.com/repos/zippy2/libvirt/commits/a8743c39389b76897811f60dcd8485cd51d76f02"},{"sha":"17cba9fb511adf82118d49b1d1a62abce99796a8","author":{"email":"c5578ac32227d61001c24bf78fc872e2c1452ac3@cn.fujitsu.com","name":"Cao jin"},"message":"qemuMonitorOpenInternal: remove redundant code\n\nThere's no need to set mon->fd to a dummy value since\nit's initialized to proper value just a few lines below.\n\nSigned-off-by: Cao jin <caoj.fnst@cn.fujitsu.com>","distinct":false,"url":"https://api.github.com/repos/zippy2/libvirt/commits/17cba9fb511adf82118d49b1d1a62abce99796a8"},{"sha":"2a5d3f227df7be78449792103e0101a4b859c49b","author":{"email":"83d82aaba2eed257f4814b0c239c260c4caaadf0@redhat.com","name":"Michal Privoznik"},"message":"virNetDevBandwidthParseRate: Reject negative values\n\nhttps://bugzilla.redhat.com/show_bug.cgi?id=1022292\n\nThe following XML really does not make any sense:\n\n<inbound average=\"-1\" burst=\"-2\" peak=\"-3\" floor=\"-4\"/>\n\nThere can't be a negative packet rate. Well, so far we haven't\nassigned any meaning to it. So reject it unless users harm themselves,\nbecause otherwise we turn the negative numbers into really big values.\n\nSigned-off-by: Michal Privoznik <mprivozn@redhat.com>","distinct":false,"url":"https://api.github.com/repos/zippy2/libvirt/commits/2a5d3f227df7be78449792103e0101a4b859c49b"}]}