From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:60753) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YtE2D-0004ZU-3h for qemu-devel@nongnu.org; Fri, 15 May 2015 07:44:10 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YtE29-0000a5-HU for qemu-devel@nongnu.org; Fri, 15 May 2015 07:44:08 -0400 Received: from mx1.redhat.com ([209.132.183.28]:33969) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YtE29-0000Zx-C2 for qemu-devel@nongnu.org; Fri, 15 May 2015 07:44:05 -0400 Message-ID: <5555DBFD.4080503@redhat.com> Date: Fri, 15 May 2015 13:43:57 +0200 From: Laszlo Ersek MIME-Version: 1.0 References: <1430817191-6231-1-git-send-email-j.fanguede@virtualopensystems.com> <20150506141249.GA6796@cbox> <20150507112027.GC25885@cbox> <554B9A70.6020309@redhat.com> In-Reply-To: <554B9A70.6020309@redhat.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [RFC] ARM/ARM64: KVM: Implement KVM_FLUSH_DCACHE_GPA ioctl List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini , =?UTF-8?B?SsOpcsOpbXkgRmFuZ3XDqGQ=?= =?UTF-8?B?ZQ==?= , Christoffer Dall Cc: list@lists.cs.columbia.edu, Overall , QEMU Developers , open@lists.cs.columbia.edu, VirtualOpenSystems Technical Team , "kvmarm@lists.cs.columbia.edu" , "linux-arm-kernel@lists.infradead.org" On 05/07/15 19:01, Paolo Bonzini wrote: >=20 >=20 > On 07/05/2015 18:56, J=C3=A9r=C3=A9my Fangu=C3=A8de wrote: >> USB devices fail with a timeout error, as if the communication between >> the kernel and the devices fail at a certain point: >> usb 1-1: device not accepting address 5, error -110 >> usb usb1-port1: unable to enumerate USB device This is consistent with what I saw in my earlier testing. >> e1000 fails when the userspace tries to use it, with these type of >> kernel messages: >> e1000 0000:00:02.0 eth0: Detected Tx Unit Hang >> Tx Queue <0> >> TDH >> TDT >> next_to_use >> next_to_clean <9> >> buffer_info[next_to_clean] >> time_stamp >> next_to_watch >> jiffies >> next_to_watch.status <0> >=20 > Can you find out what memory attributes the guest is using for the > memory---and if it's uncached, why? For USB, see "drivers/usb/core/hcd-pci.c", function usb_hcd_pci_probe(): it uses ioremap_nocache(). On the "why", that ioremap_nocache() call can be tracked to http://git.kernel.org/cgit/linux/kernel/git/tglx/history.git/commit/?id=3D= a914dd8b (Feb 2002), which predates the kernel's move to git. I guess ioremap_nocache() is used simply because USB host controllers are supposed to programmed like that. And, from "arch/arm64/include/asm/io.h": #define ioremap_nocache(addr, size) __ioremap((addr), (size), __pgprot(PROT_DEVICE_nGnRE)) Thanks Laszlo