1. 12 9月, 2019 10 次提交
  2. 11 9月, 2019 6 次提交
  3. 10 9月, 2019 18 次提交
  4. 09 9月, 2019 6 次提交
    • S
      tests: Add a baseline test for multifunction pci device use case · 4ef4ba49
      Shivaprasad G Bhat 提交于
      There are already good number of test cases with hostdevices,
      few have multifunction devices but none having more than one
      than one multifunction cards.
      
      This patch adds a case where there are two multifunction cards
      and two Virtual functions part of the same XML.
      
      0001:01:00.X & 0005:09:00.X - are Multifunction PCI cards.
      0000:06:12.[5|6] - are SRIOV Virtual functions
      
      Future commits will improve on automatically detecting the
      multifunction cards and auto-assinging the addresses
      appropriately.
      Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>
      Signed-off-by: NShivaprasad G Bhat <sbhat@linux.vnet.ibm.com>
      Signed-off-by: NDaniel Henrique Barboza <danielhb413@gmail.com>
      4ef4ba49
    • D
      virpcimock.c: simplify getrealpath() usage · 2d9b8acf
      Daniel Henrique Barboza 提交于
      Previous patch had to add '/sys/kernel/' prefix in opendir() because
      the path, which is being mocked, wasn't being considered due to
      an 'if SYSFS_PCI_PREFIX' guarding the call to getrealpath().
      
      In fact, all current getrealpath() callers are guarding it with a
      conditional to ensure that the function will never be called with
      a non-mocked path. In this case, an extra non-NULL verification is
      needed for the 'newpath' string to use the variable - which is
      counterintuitive, given that getrealpath() will always write the
      'newpath' string in any non-error conditon.
      
      However, simply removing the guard of all getrealpath() instances
      causes an abort in init_env(). This happens because tests will
      execute access() to non-mocked paths even before the
      LIBVIRT_FAKE_ROOT_DIR variable is declared in the test files. We
      don't need 'fakerootdir' to be created at this point though.
      
      This patch does the following changes to simplify getrealpath()
      usage:
      
      - getrealpath() will now guard the init_env() call by checking if
      both fakeroot isn't created and the required path is being mocked.
      This ensures that we're not failing inside init_env() because
      we're too early and LIBVIRT_FAKE_ROOT_DIR wasn't defined yet;
      
      - remove all conditional guards to call getrealpath() from
      access(), virMockStatRedirect(), open(), open_2(), opendir()
      and virFileCanonicalizePath(). As a bonus, remove all ternary
      conditionals with 'newpath';
      
      - a new 'pathPrefixIsMocked()' helper to aggregate all the prefixes
      we're mocking, making it easier to add/remove them. If a prefix
      is added inside this function, we can be sure that all functions
      are mocking them.
      Signed-off-by: NDaniel Henrique Barboza <danielhb413@gmail.com>
      Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>
      2d9b8acf
    • S
      tests: Add test case for QEMU pci-hostdev hotplug · 944a35d7
      Shivaprasad G Bhat 提交于
      This patch adds hostdev test cases in qemuhotplugtest.c.
      
      Note: the small tweak inside virpcimock.c was needed because
      the new tests added a code path in which virHostHasIOMMU()
      (virutil.c) started being called, and the mocked '/sys/kernel/'
      prefix that is mocked in virpcimock.c wasn't being considered
      in the opendir() mock. An alternative to avoid these situations
      in virpcimock.c is implemented in the next patch.
      Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>
      Signed-off-by: NShivaprasad G Bhat <sbhat@linux.vnet.ibm.com>
      Signed-off-by: NDaniel Henrique Barboza <danielhb413@gmail.com>
      944a35d7
    • S
      virpcimock: Mock the SRIOV Virtual functions · 5a9dc4a5
      Shivaprasad G Bhat 提交于
      The softlink to physfn is the way to know if the device is
      VF or not. So, the patch softlinks 'physfn' to the parent function.
      The multifunction PCI devices dont have 'physfn' softlinks.
      
      The patch adds few Virtual functions to the mock environment and
      changes the existing VFIO test xmls using the VFs to use the newly
      added VFs for their use case.
      Signed-off-by: NShivaprasad G Bhat <sbhat@linux.vnet.ibm.com>
      Signed-off-by: NDaniel Henrique Barboza <danielhb413@gmail.com>
      Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>
      5a9dc4a5
    • D
      virpcimock.c: mock /dev/vfio · 16c98903
      Daniel Henrique Barboza 提交于
      This patch adds mock of the /dev/vfio path, needed for proper
      implementation of the support for multifunction/multiple devices
      per iommu groups.
      
      To do that, the existing bind and unbind operations were adapted
      to operate with the mocked filesystem as well.
      Signed-off-by: NDaniel Henrique Barboza <danielhb413@gmail.com>
      Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
      Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>
      16c98903
    • E
      qemu: Adjust max memlock on mdev hotplug · fe39e1b1
      Eric Farman 提交于
      When starting a domain, we use the presence of a vfio-pci or
      mdev hostdev to determine if the memlock maximum needs to be
      increased.  But if we hotplug either of these devices, only the
      vfio-pci path gets that love.  This means that attaching a, say,
      vfio-ccw device will appear to succeed but the device may be
      unusable as the guest may see I/O errors on long CCW chains.
      The host, meanwhile, would be flooded with these messages:
      
        vfio_pin_page_external: Task qemu-system-s39 (11584) RLIMIT_MEMLOCK (65536) exceeded
      
      Let's adjust the maximum memlock value in the mdev hotplug path,
      so that the domain has the same value as if it were started with
      one or more mdev devices in its configuration.
      Signed-off-by: NEric Farman <farman@linux.ibm.com>
      Reviewed-by: NDaniel Henrique Barboza <danielhb413@gmail.com>
      Reviewed-by: NPavel Hrdina <phrdina@redhat.com>
      fe39e1b1