qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [RFC] ARM/ARM64: KVM: Implement KVM_FLUSH_DCACHE_GPA io


From: Christoffer Dall
Subject: Re: [Qemu-devel] [RFC] ARM/ARM64: KVM: Implement KVM_FLUSH_DCACHE_GPA ioctl
Date: Fri, 15 May 2015 08:12:35 -0700
User-agent: Mutt/1.5.21 (2010-09-15)

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                  <d>
> >>   TDT                  <d>
> >>   next_to_use          <d>
> >>   next_to_clean        <9>
> >> buffer_info[next_to_clean]
> >>   time_stamp           <ffff9311>
> >>   next_to_watch        <a>
> >>   jiffies              <ffff956a>
> >>   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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]