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

Re: [Xen-users] PCI Passthrough without VT-d



On Fri, Mar 05, 2010 at 02:01:28PM -0300, Sergio Charpinel Jr. wrote:
>    Hi,
>    I created a PV guest, and did a passthrough on my PCI USB Controller, to
>    use the webcam.
>    But, I'm receiving a kernel panic message on my domU afte boot.
>    I'm using CentOS 5.4 and Xen 3.4.2
>    Password: Fatal DMA error! Please use 'swiotlb=force'

Did you try that 'swiotlb=force' option for the guest kernel? 
Also, does the same problem happen if you run the official EL5 Xen (3.1.2)
instead of 3.4.2 ?

-- Pasi

>    ----------- [cut here ] --------- [please bite here ] ---------
>    Kernel BUG at arch/x86_64/kernel/../../i386/kernel/pci-dma-xen.c:394
>    invalid opcode: 0000 [1] SMPÃ
>    last sysfs file:
>    
> /devices/xen/pci-0/pci0000:00/0000:00:00.3/usb1/1-1/1-1:1.0/usbdev1.2_ep82/dev
>    CPU 0Ã
>    Modules linked in: autofs4 hidp rfcomm l2cap bluetooth lockd sunrpc
>    ip_conntrack_netbios_ns ipt_MASQUERADE xt_mark iptable_nat ip_nat xt_MARK
>    iptable_mangle ipt_REJECT xt_state ip_conntrack nfnetlink iptable_filter
>    ip_tables ip6t_REJECT xt_tcpudp ip6table_filter ip6_tables x_tables ipv6
>    xfrm_nalgo crypto_api dm_mirror dm_multipath scsi_dh scsi_mod parport_pc
>    lp parport stv680 compat_ioctl32 videodev v4l1_compat pcspkr v4l2_common
>    xennet dm_raid45 dm_message dm_region_hash dm_log dm_mod dm_mem_cache
>    xenblk ext3 jbd uhci_hcd ohci_hcd ehci_hcd
>    Pid: 1752, comm: zmc Not tainted 2.6.18-164.11.1.el5xen #1
>    RIP: e030:[<ffffffff8027217b>] Ã [<ffffffff8027217b>]
>    dma_map_single+0x12d/0x17d
>    RSP: e02b:ffff88000cfb1c78 Ã EFLAGS: 00010282
>    RAX: 000000000000002f RBX: ffff88000e860000 RCX: ffffffff804f3ba8
>    RDX: 0000000000000000 RSI: 0000000000000001 RDI: 0000000000000000
>    RBP: 0000000035032000 R08: ffffffff804f3ba8 R09: 0000000000000000
>    R10: 000000000000002d R11: ffff88001f4230c0 R12: 0000000000019610
>    R13: ffff88001fdef870 R14: ffff88001fb5f980 R15: ffff880010296ad4
>    FS: Ã 00002b8745423c10(0000) GS:ffffffff805ca000(0000)
>    knlGS:0000000000000000
>    CS: Ã e033 DS: 0000 ES: 0000
>    Process zmc (pid: 1752, threadinfo ffff88000cfb0000, task
>    ffff88000f4530c0)
>    Stack: Ã ffff88000f4530c0 Ã ffff880010296ac0 Ã 00000000ffffffff
>    Ã ffff880010296ac0Ã
>    Ã ffff88001ff7d400 Ã ffffffff803e4200 Ã 0000000000000000
>    Ã 000000d0802572b0Ã
>    à fffffffffff7ffff à ffffffff802c2e18Ã
>    Call Trace:
>    Ã [<ffffffff803e4200>] hcd_submit_urb+0x693/0x748
>    Ã [<ffffffff802c2e18>] mod_zone_page_state+0x27/0x3d
>    Ã [<ffffffff8020b242>] kmem_cache_alloc+0x62/0x6d
>    Ã [<ffffffff8025e6e3>] cache_alloc_refill+0x13c/0x4e5
>    Ã [<ffffffff802cfc34>] __kmalloc+0x8f/0x9f
>    Ã [<ffffffff881377e0>] :stv680:stv680_start_stream+0x18b/0x1c5
>    Ã [<ffffffff881397a0>] :stv680:stv680_do_ioctl+0x4e1/0x57b
>    Ã [<ffffffff8811ddda>] :videodev:video_usercopy+0x1a1/0x265
>    Ã [<ffffffff881392bf>] :stv680:stv680_do_ioctl+0x0/0x57b
>    Ã [<ffffffff8031a360>] inode_has_perm+0x56/0x63
>    Ã [<ffffffff80222789>] __up_read+0x19/0x7f
>    Ã [<ffffffff802676cd>] do_page_fault+0xfae/0x12e0
>    Ã [<ffffffff8026ef47>] monotonic_clock+0x35/0x7b
>    Ã [<ffffffff80243f5c>] do_ioctl+0x55/0x6b
>    Ã [<ffffffff802316b5>] vfs_ioctl+0x457/0x4b9
>    Ã [<ffffffff8024e68e>] sys_ioctl+0x59/0x78
>    Ã [<ffffffff802602f9>] tracesys+0xab/0xb6
>    Code: 0f 0b 68 3a 2b 49 80 c2 8a 01 4d 85 ed 74 11 49 8b 85 18 02Ã
>    RIP Ã [<ffffffff8027217b>] dma_map_single+0x12d/0x17d
>    Ã RSP <ffff88000cfb1c78>
>    Ã <0>Kernel panic - not syncing: Fatal exception
>    2010/3/2 Jan Ã*eÃÂÃ*ut <[1]Jan.Cescut@xxxxxx>
> 
>      Thanks for thorough explanation.
> 
>      Have a nice day,
>      Jan
>      -----Original Message-----
>      From: Pasi KÃârkkÃâinen [mailto:[2]pasik@xxxxxx]
>      Sent: 27. februar 2010 14:04
>      To: Jan Ã*eÃÂÃ*ut
>      Cc: [3]xen-users@xxxxxxxxxxxxxxxxxxx
>      Subject: Re: [Xen-users] PCI Passthrough without VT-d
> 
>      On Fri, Feb 26, 2010 at 11:29:22PM +0100, Jan ?eÃÂ?ut wrote:
>      > Ã  Ã As I read XEN supports assigning a pci device to an unprivileged
>      domain
>      > Ã  Ã without hardware supporting it. Has anyone already tried it? Are
>      there any
>      > Ã  Ã security risks? If I understand correctly how PCI passthrough
>      works the
>      > Ã  Ã performance should be the same as using the pci device in native
>      mode. Is
>      > Ã  Ã it so? I have a PCI video card which would like to use inside a
>      VM running
>      > Ã  Ã Windows XP.
>      >
> 
>      Xen supports PCI passthrough to _PV_ (paravirtual) guests without VT-d,
>      and has actually supported that for years. There are some potential
>      security
>      risks in this, since the PV guest gets full DMA control of the PCI
>      device
>      and could use it for malicious purposes.
> 
>      Xen PCI passthrough to HVM guests (=Windows) requires VT-d hardware
>      support.
> 
>      Also, PCI passthrough of a VGA/video card is not as simple as PCI
>      passthrough
>      of other cards (nic, disk controller, usb controller).
> 
>      VGA has lots of legacy stuff related to it, some memory ranges, IO
>      ports, VGA BIOS,
>      etc that have to be 'passed through' aswell, and emulated.
> 
>      Xen 4.0.0 will have PCI passthrough support of primary VGA adapters, but
>      it requires
>      VT-d support as stated already earlier.
> 
>      -- Pasi
> 
>      ps. There is actually a hack/patch available that allows PCI passthrough
>      to HVM guest
>      without VT-d, but that only works for the _first_ started HVM guest, and
>      it's experimental
>      and not supported in any way. iirc the patch is available in xen-devel
>      archives.
> 
>      _______________________________________________
>      Xen-users mailing list
>      [4]Xen-users@xxxxxxxxxxxxxxxxxxx
>      [5]http://lists.xensource.com/xen-users
> 
>    --
>    Sergio Roberto Charpinel Jr.
> 
> References
> 
>    Visible links
>    1. mailto:Jan.Cescut@xxxxxx
>    2. mailto:pasik@xxxxxx
>    3. mailto:xen-users@xxxxxxxxxxxxxxxxxxx
>    4. mailto:Xen-users@xxxxxxxxxxxxxxxxxxx
>    5. http://lists.xensource.com/xen-users

_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-users


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.