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

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-... 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/e3df08a4af6c321d5942dcee585916ccf... 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(a)intel.com&gt; All errors (new ones prefixed by >>): drivers/virtio/virtio_ring.c: In function 'vring_use_dma_api': 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 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@lists.01.org