From mboxrd@z Thu Jan 1 00:00:00 1970 From: Christoffer Dall Subject: Re: [RFC] ARM/ARM64: KVM: Implement KVM_FLUSH_DCACHE_GPA ioctl Date: Fri, 15 May 2015 08:12:35 -0700 Message-ID: <20150515151235.GD14144@lvm> References: <1430817191-6231-1-git-send-email-j.fanguede@virtualopensystems.com> <20150506141249.GA6796@cbox> <20150507112027.GC25885@cbox> <554B9A70.6020309@redhat.com> <5555DBFD.4080503@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE Return-path: Content-Disposition: inline In-Reply-To: <5555DBFD.4080503@redhat.com> Sender: kvm-owner@vger.kernel.org To: Laszlo Ersek Cc: Paolo Bonzini , =?iso-8859-1?B?Suly6W15IEZhbmd16GRl?= , 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" List-Id: kvmarm@lists.cs.columbia.edu On Fri, May 15, 2015 at 01:43:57PM +0200, Laszlo Ersek wrote: > On 05/07/15 19:01, Paolo Bonzini wrote: > >=20 > >=20 > > On 07/05/2015 18:56, J=E9r=E9my Fangu=E8de wrote: > >> USB devices fail with a timeout error, as if the communication bet= ween > >> 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 >=20 > This is consistent with what I saw in my earlier testing. >=20 > >> 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? >=20 > For USB, see "drivers/usb/core/hcd-pci.c", function usb_hcd_pci_probe= (): > it uses ioremap_nocache(). >=20 > On the "why", that ioremap_nocache() call can be tracked to >=20 > http://git.kernel.org/cgit/linux/kernel/git/tglx/history.git/commit/?= id=3Da914dd8b >=20 > (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. >=20 > And, from "arch/arm64/include/asm/io.h": >=20 > #define ioremap_nocache(addr, size) __ioremap((addr), (size), > __pgprot(PROT_DEVICE_nGnRE)) >=20 So this just means that these devices should be mapped as device memory (like the VGA case before) right? And therefore should work with Drew'= s patches (assuming they are actually correct and you add the right QEMU annotations to set the memory regions and non-cacheable), correct? Thanks, -Christoffer From mboxrd@z Thu Jan 1 00:00:00 1970 From: christoffer.dall@linaro.org (Christoffer Dall) Date: Fri, 15 May 2015 08:12:35 -0700 Subject: [RFC] ARM/ARM64: KVM: Implement KVM_FLUSH_DCACHE_GPA ioctl In-Reply-To: <5555DBFD.4080503@redhat.com> References: <1430817191-6231-1-git-send-email-j.fanguede@virtualopensystems.com> <20150506141249.GA6796@cbox> <20150507112027.GC25885@cbox> <554B9A70.6020309@redhat.com> <5555DBFD.4080503@redhat.com> Message-ID: <20150515151235.GD14144@lvm> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On Fri, May 15, 2015 at 01:43:57PM +0200, Laszlo Ersek wrote: > On 05/07/15 19:01, Paolo Bonzini wrote: > > > > > > On 07/05/2015 18:56, J?r?my Fangu?de 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> > > > > 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=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)) > So this just means that these devices should be mapped as device memory (like the VGA case before) right? And therefore should work with Drew's patches (assuming they are actually correct and you add the right QEMU annotations to set the memory regions and non-cacheable), correct? Thanks, -Christoffer From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:59262) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YtHI3-0005FD-Fh for qemu-devel@nongnu.org; Fri, 15 May 2015 11:12:44 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YtHI0-0008J3-7v for qemu-devel@nongnu.org; Fri, 15 May 2015 11:12:43 -0400 Received: from mail-la0-f46.google.com ([209.85.215.46]:33998) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YtHI0-0008Iq-0m for qemu-devel@nongnu.org; Fri, 15 May 2015 11:12:40 -0400 Received: by laat2 with SMTP id t2so123929466laa.1 for ; Fri, 15 May 2015 08:12:39 -0700 (PDT) Date: Fri, 15 May 2015 08:12:35 -0700 From: Christoffer Dall Message-ID: <20150515151235.GD14144@lvm> References: <1430817191-6231-1-git-send-email-j.fanguede@virtualopensystems.com> <20150506141249.GA6796@cbox> <20150507112027.GC25885@cbox> <554B9A70.6020309@redhat.com> <5555DBFD.4080503@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <5555DBFD.4080503@redhat.com> 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: Laszlo Ersek Cc: list@lists.cs.columbia.edu, Overall , QEMU Developers , open@lists.cs.columbia.edu, Paolo Bonzini , =?iso-8859-1?B?Suly6W15IEZhbmd16GRl?= , VirtualOpenSystems Technical Team , "kvmarm@lists.cs.columbia.edu" , "linux-arm-kernel@lists.infradead.org" On Fri, May 15, 2015 at 01:43:57PM +0200, Laszlo Ersek wrote: > On 05/07/15 19:01, Paolo Bonzini wrote: > > > > > > On 07/05/2015 18:56, Jérémy Fanguède 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> > > > > 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=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)) > So this just means that these devices should be mapped as device memory (like the VGA case before) right? And therefore should work with Drew's patches (assuming they are actually correct and you add the right QEMU annotations to set the memory regions and non-cacheable), correct? Thanks, -Christoffer