1. 09 12月, 2019 3 次提交
    • D
      conf: move virt type / os type / arch validation to post-parse · 2578d74a
      Daniel P. Berrangé 提交于
      The XML parser currently calls virCapabilitiesDomainDataLookup during
      parsing to find the domain capabilities matching the triple
      
        (virt type, os type, arch)
      
      This is, however, bogus with the QEMU driver as it assumes that there
      is an emulator known to the default driver capabilities that matches
      this triple. It is entirely possible for the driver to be parsing an
      XML file with a custom emulator path specified pointing to a binary
      that doesn't exist in the default driver capabilities.  This will,
      for example be the case on a RHEL host which only installs the host
      native emulator to /usr/bin. The user can have built a custom QEMU
      for non-native arches into $HOME and wish to use that.
      
      Aside from validation, this call is also used to fill in a machine type
      for the guest if not otherwise specified. Again, this data may be
      incorrect for the QEMU driver because it is not taking account of
      the emulator binary that is referenced.
      
      To start fixing this, move the validation to the post-parse callbacks
      where more intelligent driver specific logic can be applied.
      Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>
      Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>
      2578d74a
    • D
      conf: sanitize virDomainSaveStatus & virDomainSaveConfig APIs · 908701c6
      Daniel P. Berrangé 提交于
      Our normal practice is for the object type to be the name prefix, and
      the object instance be the first parameter passed in.
      
      Rename these to virDomainObjSave and virDomainDefSave moving their
      primary parameter to be the first one. Ensure that the xml options
      are passed into both functions in prep for future work.
      
      Finally enforce checking of the return type and mark all parameters
      as non-NULL.
      Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>
      Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>
      908701c6
    • J
      qemu: cold-unplug of sound · 863c0d8e
      Jidong Xia 提交于
      With this patch users can cold unplug some sound devices.
      use "virsh detach-device vm sound.xml --config" command.
      Reviewed-by: NCole Robinson <crobinso@redhat.com>
      Signed-off-by: NJidong Xia <xiajidong@cmss.chinamobile.com>
      863c0d8e
  2. 04 12月, 2019 1 次提交
  3. 26 11月, 2019 1 次提交
    • L
      conf: add hypervisor agnostic, domain start-time, validation function for NetDef · b03d9e95
      Laine Stump 提交于
      <interface> devices (virDomainNetDef) are a bit different from other
      types of devices in that their actual type may come from a network (in
      the form of a port connection), and that doesn't happen until the
      domain is started. This means that any validation of an <interface> at
      parse time needs to be a bit liberal in what it accepts - when
      type='network', you could think that something is/isn't allowed, but
      once the domain is started and a port is created by the configured
      network, the opposite might be true.
      
      To solve this problem hypervisor drivers need to do an extra
      validation step when the domain is being started. I recently (commit
      3cff23f7, libvirt 5.7.0) added a function to peform such validation
      for all interfaces to the QEMU driver -
      qemuDomainValidateActualNetDef() - but while that function is a good
      single point to call for the multiple places that need to "start" an
      interface (domain startup, device hotplug, device update), it can't be
      called by the other hypervisor drivers, since 1) it's in the QEMU
      driver, and 2) it contains some checks specific to QEMU. For
      validation that applies to network devices on *all* hypervisors, we
      need yet another interface validation function that can be called by
      any hypervisor driver (not just QEMU) right after its network port has
      been created during domain startup or hotplug. This patch adds that
      function - virDomainActualNetDefValidate(), in the conf directory,
      and calls it in appropriate places in the QEMU, lxc, and libxl
      drivers.
      
      This new function is the place to put all network device validation
      that 1) is hypervisor agnostic, and 2) can't be done until we know the
      "actual type" of an interface.
      
      There is no framework for validation at domain startup as there is for
      post-parse validation, but I don't want to create a whole elaborate
      system that will only be used by one type of device. For that reason,
      I just made a single function that should be called directly from the
      hypervisors, when they are initializing interfaces to start a domain,
      right after conditionally allocating the network port (and regardless
      of whether or not that was actually needed). In the case of the QEMU
      driver, qemuDomainValidateActualNetDef() is already called in all the
      appropriate places, so we can just call the new function from
      there. In the case of the other hypervisors, we search for
      virDomainNetAllocateActualDevice() (which is the hypervisor-agnostic
      function that calls virNetworkPortCreateXML()), and add the call to our
      new function right after that.
      
      The new function itself could be plunked down into many places in the
      code, but we already have 3 validation functions for network devices
      in 2 different places (not counting any basic validation done in
      virDomainNetDefParseXML() itself):
      
      1) post-parse hypervisor-agnostic
         (virDomainNetDefValidate() - domain_conf.c:6145)
      2) post-parse hypervisor-specific
         (qemuDomainDeviceDefValidateNetwork() - qemu_domain.c:5498)
      3) domain-start hypervisor-specific
         (qemuDomainValidateActualNetDef() - qemu_domain.c:5390)
      
      I placed (3) right next to (2) when I added it, specifically to avoid
      spreading validation all over the code. For the same reason, I decided
      to put this new function right next to (1) - this way if someone needs
      to add validation specific to qemu, they go to one location, and if
      they need to add validation applying to everyone, they go to the
      other. It looks a bit strange to have a public function in between a
      bunch of statics, but I think it's better than the alternative of
      further fragmentation. (I'm open to other ideas though, of course.)
      Signed-off-by: NLaine Stump <laine@redhat.com>
      Reviewed-by: NCole Robinson <crobinso@redhat.com>
      b03d9e95
  4. 22 11月, 2019 1 次提交
  5. 21 11月, 2019 2 次提交
  6. 15 11月, 2019 9 次提交
    • P
      vircgroup: introduce virCgroupV2DevicesGetKey · b18b0ce6
      Pavel Hrdina 提交于
      Device rules are stored in BPF map that is a hash type, this function
      will create a key based on major and minor id of device.
      Signed-off-by: NPavel Hrdina <phrdina@redhat.com>
      Reviewed-by: NJán Tomko <jtomko@redhat.com>
      b18b0ce6
    • P
      vircgroup: introduce virCgroupV2DeviceGetPerms · 63cfe7b8
      Pavel Hrdina 提交于
      Signed-off-by: NPavel Hrdina <phrdina@redhat.com>
      Reviewed-by: NJán Tomko <jtomko@redhat.com>
      63cfe7b8
    • P
      vircgroup: introduce virCgroupV2DevicesRemoveProg · 6a24bd75
      Pavel Hrdina 提交于
      We need to close our FD that we have for BPF program and map in order
      to let kernel remove all resources once the cgroup is removed as well.
      Signed-off-by: NPavel Hrdina <phrdina@redhat.com>
      Reviewed-by: NJán Tomko <jtomko@redhat.com>
      6a24bd75
    • P
      vircgroup: introduce virCgroupV2DevicesPrepareProg · ef747499
      Pavel Hrdina 提交于
      This function will be called for every virCgroup(Allow|Deny)* API in
      order to prepare BPF program for guest.  Since libvirtd can be restarted
      at any point we will first try to detect existing progam, if there is
      none we will create a new empty BPF program and lastly if we don't have
      any space left in the existing BPF map we will create a new copy of the
      BPF map with more space and attach a new program with that map into the
      guest cgroup.
      
      This solution allows us to start with reasonably small BPF map consuming
      only small amount of memory and if needed we can easily extend the BPF
      map if there is a lot of host devices used in guest or if user wants to
      hot-plug a lot of devices once the guest is running.
      
      Since there is no way how to reallocate existing BPF map we need to
      create a new copy if we run out of space in current BPF map.
      
      This overcomes all the limitations in BPF:
      
          - map used in program has to be created before the program is loaded
            into kernel
      
          - once map is created you cannot change its size
      
          - you cannot replace map in existing program
      
          - you cannot use an array of maps because it can store FD to maps
            of one specific size so we would not be able to use it to overcome
            the second issue
      Signed-off-by: NPavel Hrdina <phrdina@redhat.com>
      Reviewed-by: NJán Tomko <jtomko@redhat.com>
      ef747499
    • P
      vircgroup: introduce virCgroupV2DevicesCreateProg · afa27886
      Pavel Hrdina 提交于
      This function creates new BPF program with new empty BPF map with the
      default size and attaches it to the guest cgroup.
      Signed-off-by: NPavel Hrdina <phrdina@redhat.com>
      Reviewed-by: NJán Tomko <jtomko@redhat.com>
      afa27886
    • P
      vircgroup: introduce virCgroupV2DevicesDetectProg · ce11a5c5
      Pavel Hrdina 提交于
      This function will be called if libvirtd was restarted while some
      domains were running.  It will try to detect existing programs attached
      to the guest cgroup.
      Signed-off-by: NPavel Hrdina <phrdina@redhat.com>
      Reviewed-by: NJán Tomko <jtomko@redhat.com>
      ce11a5c5
    • P
      vircgroup: introduce virCgroupV2DevicesAttachProg · 48423a0b
      Pavel Hrdina 提交于
      This function loads the BPF prog with prepared map into kernel and
      attaches it into guest cgroup.  It can be also used to replace existing
      program in the cgroup if we need to resize BPF map to store more rules
      for devices. The old program will be closed and removed from kernel.
      
      There are two possible ways how to create BPF program:
      
          - One way is to write simple C-like code which can by compiled into
            BPF object file which can be loaded into kernel using elfutils.
      
          - The second way is to define macros which look like assembler
            instructions and can be used directly to create BPF program that
            can be directly loaded into kernel.
      
      Since the program is not too complex we can use the second option.
      
      If there is no program, all devices are allowed, if there is some
      program it is executed and based on the exit status the access is
      denied for 0 and allowed for 1.
      
      Our program will follow these rules:
      
          - first it will try to look for the specific key using major and
            minor to see if there is any rule for that specific device
      
          - if there is no specific rule it will try to look for any rule that
            matches only major of the device
      
          - if there is no match with major it will try the same but with
            minor of the device
      
          - as the last attempt it will try to look for rule for all devices
            and if there is no match it will return 0 to deny that access
      Signed-off-by: NPavel Hrdina <phrdina@redhat.com>
      Reviewed-by: NJán Tomko <jtomko@redhat.com>
      48423a0b
    • P
      vircgroup: introduce virCgroupV2DevicesAvailable · 30b6ddc4
      Pavel Hrdina 提交于
      There is no exact way how to figure out whether BPF devices support is
      compiled into kernel.  One way is to check kernel configure options but
      this is not reliable as it may not be available.  Let's try to do
      syscall to which will list BPF cgroup device programs.
      Signed-off-by: NPavel Hrdina <phrdina@redhat.com>
      Reviewed-by: NJán Tomko <jtomko@redhat.com>
      30b6ddc4
    • P
      util: introduce virbpf helpers · 07946d6e
      Pavel Hrdina 提交于
      In order to implement devices controller with cgroup v2 we need to
      add support for BPF programs, cgroup v2 doesn't have devices controller.
      
      This introduces required helpers wrapping linux syscalls.
      Signed-off-by: NPavel Hrdina <phrdina@redhat.com>
      Reviewed-by: NJán Tomko <jtomko@redhat.com>
      07946d6e
  7. 14 11月, 2019 2 次提交
  8. 13 11月, 2019 1 次提交
  9. 12 11月, 2019 3 次提交
  10. 25 10月, 2019 3 次提交
  11. 21 10月, 2019 7 次提交
  12. 19 10月, 2019 1 次提交
  13. 18 10月, 2019 1 次提交
  14. 16 10月, 2019 1 次提交
  15. 14 10月, 2019 1 次提交
  16. 12 10月, 2019 1 次提交
  17. 10 10月, 2019 1 次提交
  18. 08 10月, 2019 1 次提交
    • M
      driver: Introduce virDriverShouldAutostart() · ee16a195
      Michal Privoznik 提交于
      Some of objects we manage can be autostarted on libvirtd startup
      (e.g. domains, network, storage pools). The idea was that when
      the host is started up these objects are started too without need
      of user intervention. However, with the latest daemon split and
      switch to socket activated, short lived daemons (we put --timeout
      120 onto each daemon's command line) this doesn't do what we want
      it to. The problem is not new though, we already had the session
      daemon come and go and we circumvented this problem by
      documenting it (see v4.10.0-92-g61b4e8aa). But now that we meet
      the same problem at all fronts it's time to deal with it.
      
      The solution implemented in this commit is to have a file (one
      per each driver) that:
      
        1) if doesn't exist, is created and autostart is allowed for
           given driver,
      
        2) if it does exist, then autostart is suppressed for given
           driver.
      
      All the files live in a location that doesn't survive host
      reboots (/var/run/ for instance) and thus the file is
      automatically not there on fresh host boot.
      Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
      Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>
      ee16a195