All of lore.kernel.org
 help / color / mirror / Atom feed
From: Weidong Han <weidong.han@intel.com>
To: "Pasi Kärkkäinen" <pasik@iki.fi>
Cc: Sander Eikelenboom <linux@eikelenboom.it>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: RE: [pvops xen/next ][iommu] attenpt to	passthrough PCI-e usb controllor to PV domU: (XEN) traps.c:2309:d1	Domain attempted WRMSR 000000000000008b from 00000a07:00000000 to	00000000:00000000.
Date: Mon, 22 Mar 2010 17:25:55 +0800	[thread overview]
Message-ID: <4BA737A3.4090708@intel.com> (raw)
In-Reply-To: <20100322091917.GB1878@reaktio.net>

Pasi Kärkkäinen wrote:
> On Mon, Mar 22, 2010 at 05:13:33PM +0800, Weidong Han wrote:
>   
>> Pasi Kärkkäinen wrote:
>>     
>>> On Mon, Mar 22, 2010 at 04:04:09PM +0800, Han, Weidong wrote:
>>>   
>>>       
>>>> The faults were caused by that the DMA address was not mapped in VT-d page table.
>>>>
>>>> Could you have following two tries:
>>>> 	1) assign it to pv domU without VT-d
>>>>     
>>>>         
>>> Btw are there other methods of disabling VT-d PCI passhtru than having 
>>> iommu=off for xen.gz in grub.conf? ie. can you somehow select "use 
>>> normal PV passthru for this guest" and "but still use VT-d passthru for 
>>> this guest" ?
>>>
>>>   
>>>       
>> I'm not quite understand your point. do you mean use normal PV passthru  
>> for pv guest, but still can passthru device to hvm guest? if so, current  
>> xen VT-d already does like this.
>>
>>     
>
> Yeah, that's what I meant. Ok. 
>
> I thought it was also possible to use VT-d for a PV guest? no? 
>   
yes. you can use VT-d to assign device to pv guest. Sander was doing 
that and encountered below issue.

Regards,
Weidong
> -- Pasi
>
>   
>> Regards,
>> Weidong
>>     
>>> ps. I'm just writing a xen wiki page for PCI passthru and adding these things and the common failure scenarios there.
>>>
>>> -- Pasi
>>>
>>>   
>>>       
>>>> 	2) assign it to a hvm guest
>>>>
>>>> Regards,
>>>> Weidong
>>>>
>>>> -----Original Message-----
>>>> From: Sander Eikelenboom [mailto:linux@eikelenboom.it] Sent: Monday, 
>>>> March 22, 2010 5:20 AM
>>>> To: Konrad Rzeszutek Wilk
>>>> Cc: Han, Weidong; xen-devel@lists.xensource.com
>>>> Subject: [pvops xen/next ][iommu] attenpt to passthrough PCI-e usb controllor to PV domU: (XEN) traps.c:2309:d1 Domain attempted WRMSR 000000000000008b from 00000a07:00000000 to 00000000:00000000.
>>>>
>>>> Hi Han/Konrad,
>>>>
>>>> In my setup i'm trying to passthrough an USB 3.0 pci-e controller  to a PV domU.
>>>> - xen: 4.0.0-rc6
>>>> - dom0: kernel xen/next
>>>> - domU: kernel 2.6.33 from git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
>>>>         ( to have pci-front together with most recent usb3.0 xhci drivers.
>>>>
>>>>
>>>> - USB 3.0 xhci drivers work fine on the baremetal with the 2.6.33 kernel.
>>>>
>>>> This is on a intel Q45 chipset with IOMMU.
>>>>
>>>> This is my boot config:
>>>> title           xen-4.0.0-rc6.gz / Debian GNU/Linux,  kernel 2.6.32
>>>> root            (hd0,0)
>>>> kernel          /boot/xen-4.0.0-rc6.gz dom0_mem=768M loglvl=all loglvl_guest=all  iommu=pv iommu_inclusive_mapping=1
>>>> module          /boot/vmlinuz-2.6.32 root=/dev/sda1 ro earlyprintk=xen max_loop=255 xen-pciback.hide=(03:00.0)
>>>> module          /boot/initrd.img-2.6.32
>>>>
>>>> When booting the domU xm dmesg gets filled with the following when the usb controller tries to initialize/:
>>>>
>>>> (XEN) traps.c:2309:d1 Domain attempted WRMSR 000000000000008b from 00000a07:00000000 to 00000000:00000000.
>>>> (XEN) [VT-D]iommu.c:821: iommu_fault_status: Primary Pending Fault
>>>> (XEN) [VT-D]iommu.c:796: DMAR:[DMA Read] Request device [03:00.0] fault addr 1ff94000, iommu reg = ffff82c3fff54000
>>>> (XEN) DMAR:[fault reason 06h] PTE Read access is not set
>>>> (XEN) print_vtd_entries: iommu = ffff83007c866970 bdf = 3:0.0 gmfn = 1ff94
>>>> (XEN)     root_entry = ffff83007c872000
>>>> (XEN)     root_entry[3] = 78f56001
>>>> (XEN)     context = ffff830078f56000
>>>> (XEN)     context[0] = 101_2f0e1001
>>>> (XEN)     l3 = ffff83002f0e1000
>>>> (XEN)     l3_index = 0
>>>> (XEN)     l3[0] = 2f0e0003
>>>> (XEN)     l2 = ffff83002f0e0000
>>>> (XEN)     l2_index = ff
>>>> (XEN)     l2[ff] = 0
>>>> (XEN)     l2[ff] not present
>>>>
>>>>
>>>>
>>>> Anyone any tips on what i could try ?, is this something caused by xen, or something by the usb driver not adhering to kernel DMA-api ?
>>>>
>>>> Attached:
>>>>
>>>> - xm-info.txt
>>>> - xm-dmesg.txt
>>>> - xend.log
>>>>
>>>> - dom0-dmesg.txt
>>>> - dom0-lspci-tree.txt
>>>> - dom0-lspci.txt
>>>>
>>>> - domU-lspci.txt
>>>> - domU-dmesg.txt
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Xen-devel mailing list
>>>> Xen-devel@lists.xensource.com
>>>> http://lists.xensource.com/xen-devel
>>>>     
>>>>         

  parent reply	other threads:[~2010-03-22  9:25 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-03-21 21:19 [pvops xen/next ][iommu] attenpt to passthrough PCI-e usb controllor to PV domU: (XEN) traps.c:2309:d1 Domain attempted WRMSR 000000000000008b from 00000a07:00000000 to 00000000:00000000 Sander Eikelenboom
2010-03-22  8:04 ` Han, Weidong
2010-03-22  9:04   ` Pasi Kärkkäinen
2010-03-22  9:13     ` Weidong Han
2010-03-22  9:19       ` Pasi Kärkkäinen
2010-03-22  9:22         ` Christian Tramnitz
2010-03-22  9:55           ` Pasi Kärkkäinen
2010-03-22  9:25         ` Weidong Han [this message]
2010-03-22  9:29           ` Pasi Kärkkäinen
2010-03-22  9:32             ` Weidong Han
2010-03-22  9:30           ` Sander Eikelenboom
2010-03-22 10:15   ` Sander Eikelenboom
2010-03-22 10:58     ` Jan Beulich
2010-03-22 13:14       ` Re: [pvops xen/next ] attenpt to passthrough PCI-e usb controllor to PV domU Sander Eikelenboom
2010-03-22 19:12     ` [pvops xen/next ][iommu] attenpt to passthrough PCI-e usb controllor to PV domU: (XEN) traps.c:2309:d1 Domain attempted WRMSR 000000000000008b from 00000a07:00000000 to 00000000:00000000 Konrad Rzeszutek Wilk
2010-03-22 20:35       ` [pvops xen/next ][iommu] attenpt to passthrough PCI-e usb controllor to PV domU SUCCESS :-) Sander Eikelenboom
2010-03-22 20:30         ` Konrad Rzeszutek Wilk
2010-03-22 20:49         ` Pasi Kärkkäinen
2010-03-22 21:23           ` Sander Eikelenboom
2010-03-22 21:26             ` Pasi Kärkkäinen
2010-03-22 21:12               ` Konrad Rzeszutek Wilk
2010-03-23  7:05                 ` Pasi Kärkkäinen
2010-03-23 10:16                 ` Jan Beulich
2010-03-23 10:23                   ` Sander Eikelenboom
2010-03-23 11:23                     ` Jan Beulich
2010-03-23 11:24                       ` Pasi Kärkkäinen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4BA737A3.4090708@intel.com \
    --to=weidong.han@intel.com \
    --cc=konrad.wilk@oracle.com \
    --cc=linux@eikelenboom.it \
    --cc=pasik@iki.fi \
    --cc=xen-devel@lists.xensource.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.