Re: [RFCv2 05/16] x86/kvm: Make VirtIO use DMA API in KVM guest

From: kernel test robot <lkp@intel.com>
To: kbuild-all@lists.01.org
Subject: Re: [RFCv2 05/16] x86/kvm: Make VirtIO use DMA API in KVM guest
Date: Tue, 20 Oct 2020 17:18:40 +0800	[thread overview]
Message-ID: <202010201743.efaJt7hx-lkp@intel.com> (raw)
In-Reply-To: <20201020061859.18385-6-kirill.shutemov@linux.intel.com>

[-- Attachment #1: Type: text/plain, Size: 4115 bytes --]

Hi "Kirill,

[FYI, it's a private test report for your RFC patch.]
[auto build test ERROR on tip/x86/core]
[also build test ERROR on kvm/linux-next hnaz-linux-mm/master v5.9]
[cannot apply to next-20201016]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]

url:    https://github.com/0day-ci/linux/commits/Kirill-A-Shutemov/KVM-protected-memory-extension/20201020-142130
base:   https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git 238c91115cd05c71447ea071624a4c9fe661f970
config: xtensa-allyesconfig (attached as .config)
compiler: xtensa-linux-gcc (GCC) 9.3.0
reproduce (this is a W=1 build):
        wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
        chmod +x ~/bin/make.cross
        # https://github.com/0day-ci/linux/commit/e3df08a4af6c321d5942dcee585916ccf5e59ef6
        git remote add linux-review https://github.com/0day-ci/linux
        git fetch --no-tags linux-review Kirill-A-Shutemov/KVM-protected-memory-extension/20201020-142130
        git checkout e3df08a4af6c321d5942dcee585916ccf5e59ef6
        # save the attached .config to linux build tree
        COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross ARCH=xtensa 

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <lkp@intel.com>

All errors (new ones prefixed by >>):

   drivers/virtio/virtio_ring.c: In function 'vring_use_dma_api':
>> drivers/virtio/virtio_ring.c:259:6: error: implicit declaration of function 'kvm_mem_protected' [-Werror=implicit-function-declaration]
     259 |  if (kvm_mem_protected())
         |      ^~~~~~~~~~~~~~~~~
   cc1: some warnings being treated as errors

vim +/kvm_mem_protected +259 drivers/virtio/virtio_ring.c

   215	
   216	/*
   217	 * Modern virtio devices have feature bits to specify whether they need a
   218	 * quirk and bypass the IOMMU. If not there, just use the DMA API.
   219	 *
   220	 * If there, the interaction between virtio and DMA API is messy.
   221	 *
   222	 * On most systems with virtio, physical addresses match bus addresses,
   223	 * and it doesn't particularly matter whether we use the DMA API.
   224	 *
   225	 * On some systems, including Xen and any system with a physical device
   226	 * that speaks virtio behind a physical IOMMU, we must use the DMA API
   227	 * for virtio DMA to work at all.
   228	 *
   229	 * On other systems, including SPARC and PPC64, virtio-pci devices are
   230	 * enumerated as though they are behind an IOMMU, but the virtio host
   231	 * ignores the IOMMU, so we must either pretend that the IOMMU isn't
   232	 * there or somehow map everything as the identity.
   233	 *
   234	 * For the time being, we preserve historic behavior and bypass the DMA
   235	 * API.
   236	 *
   237	 * TODO: install a per-device DMA ops structure that does the right thing
   238	 * taking into account all the above quirks, and use the DMA API
   239	 * unconditionally on data path.
   240	 */
   241	
   242	static bool vring_use_dma_api(struct virtio_device *vdev)
   243	{
   244		if (!virtio_has_dma_quirk(vdev))
   245			return true;
   246	
   247		/* Otherwise, we are left to guess. */
   248		/*
   249		 * In theory, it's possible to have a buggy QEMU-supposed
   250		 * emulated Q35 IOMMU and Xen enabled at the same time.  On
   251		 * such a configuration, virtio has never worked and will
   252		 * not work without an even larger kludge.  Instead, enable
   253		 * the DMA API if we're a Xen guest, which at least allows
   254		 * all of the sensible Xen configurations to work correctly.
   255		 */
   256		if (xen_domain())
   257			return true;
   258	
 > 259		if (kvm_mem_protected())
   260			return true;
   261	
   262		return false;
   263	}
   264	

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all(a)lists.01.org

[-- Attachment #2: config.gz --]
[-- Type: application/gzip, Size: 65044 bytes --]