1. 27 6月, 2020 1 次提交
    • S
      conf: fix zPCI address auto-generation on s390 · 07659100
      Shalini Chellathurai Saroja 提交于
      Let us fix the issues with zPCI address validation and auto-generation
      on s390.
      
      Currently, there are two issues with handling the ZPCI address
      extension. Firstly, when the uid is to be auto-generated with a
      specified fid, .i.e.:
      
          ...
          <address type='pci'>
              <zpci fid='0x0000001f'/>
          </address>
          ...
      
      we expect uid='0x0001' (or the next available uid for the domain).
      However, we get a parsing error:
      
          $ virsh define zpci.xml
          error: XML error: Invalid PCI address uid='0x0000', must be > 0x0000
          and <= 0xffff
      
      Secondly, when the uid is specified explicitly with the invalid
      numerical value '0x0000', we actually expect the parsing error above.
      However, the domain is being defined and the uid value is silently
      changed to a valid value.
      
      The first issue is a bug and the second one is undesired behaviour, and
      both issues are related to how we (in-band) signal invalid values for
      uid and fid. So let's fix the XML parsing to do validation based on what
      is actually specified in the XML.
      
      The first issue is also related to the current code behaviour, which
      is, if either uid or fid is specified by the user, it is incorrectly
      assumed that both uid and fid are specified. This bug is fixed by
      identifying when the user specified ZPCI address is incomplete and
      auto-generating the missing ZPCI address.
      Signed-off-by: NBjoern Walk <bwalk@linux.ibm.com>
      Signed-off-by: NBoris Fiuczynski <fiuczy@linux.ibm.com>
      Signed-off-by: NShalini Chellathurai Saroja <shalini@linux.ibm.com>
      Reviewed-by: NAndrea Bolognani <abologna@redhat.com>
      07659100
  2. 26 6月, 2020 2 次提交
    • J
      tests: ensure failure if input file doesn't exist · bac096ff
      Jonathon Jongsma 提交于
      When using the DO_TEST_PARSE_ERROR() macro, a failure to parse the input
      file is considered a successful test. However, if the input file is
      totally missing, that should be distinguished from a parsing error and
      not be treated as a test success.
      
      The function virDomainDefParseFile() simply returns NULL for any parse
      failure, including a missing file. So we need to explicitly check
      whether the file exists first, and fail the test if it is missing.
      Signed-off-by: NJonathon Jongsma <jjongsma@redhat.com>
      bac096ff
    • J
      qemu: ramfb video device doesn't support PCI address · 6c560b2d
      Jonathon Jongsma 提交于
      Although a ramfb video device is not a PCI device, we don't currently
      report an error for ramfb device definitions containing a PCI address.
      However, a guest configured with such a device will fail to start:
      
          # virsh start test1
          error: Failed to start domain test1
          error: internal error: qemu unexpectedly closed the monitor: 2020-06-16T05:23:02.759221Z qemu-kvm: -device ramfb,id=video0,bus=pcie.0,addr=0x1: Device 'ramfb' can't go on PCIE bus
      
      A better approach is to reject any device definitions that contain PCI
      addresses.  While this is a change in behavior, any existing
      configurations were non-functional.
      
      https://bugzilla.redhat.com/show_bug.cgi?id=1847259Signed-off-by: NJonathon Jongsma <jjongsma@redhat.com>
      6c560b2d
  3. 23 6月, 2020 16 次提交
  4. 16 6月, 2020 1 次提交
  5. 10 6月, 2020 1 次提交
  6. 22 5月, 2020 1 次提交
    • M
      testCompareXMLToArgvValidateSchema: Construct @vm from scratch · 69daa2ea
      Michal Privoznik 提交于
      Currently, the @vm is passed in as an argument and
      testCompareXMLToArgvCreateArgs() is called over it which means
      under the hood qemuProcessPrepareDomain() is called. But at the
      point where ValidateSchema() is called, the domain object is
      already 'prepared', i.e. all device aliases are assigned and so
      on. But our code is not prepared to 'prepare' a domain twice - it
      simply overwrites all the pointers leading to a memory leak.
      
      Fortunately, this is only the problem of this test.
      
      Resolve this by constructing the domain object from scratch.
      Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
      Reviewed-by: NPeter Krempa <pkrempa@redhat.com>
      69daa2ea
  7. 20 5月, 2020 3 次提交
  8. 13 5月, 2020 1 次提交
  9. 12 5月, 2020 4 次提交
  10. 08 5月, 2020 2 次提交
  11. 05 5月, 2020 1 次提交
  12. 27 4月, 2020 6 次提交
  13. 24 4月, 2020 1 次提交