thr3ads.net - Xen users - [Xen-users] PCI Passthrough without VT-d [Feb 2010]

If this information is useful, please help other people find it:
Share via:

Jan Češčut

2010-Feb-26 22:29 UTC

[Xen-users] PCI Passthrough without VT-d

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.

Thanks and have a nice day,
Jan


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

chris

2010-Feb-26 22:35 UTC

head link

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

vt-d is required for passthrough of pci devices to a hvm domain
(windows). support for passthrough of video devices is high
experimental and only in recent versions.

- chris

2010/2/26 Jan Češčut <Jan.Cescut@kgs.si>:> 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.
>
>
>
> Thanks and have a nice day,
>
> Jan
>
> _______________________________________________
> Xen-users mailing list
> Xen-users@lists.xensource.com
> http://lists.xensource.com/xen-users
>
_______________________________________________
Xen-users mailing list
Xen-users@lists.xensource.com
http://lists.xensource.com/xen-users

Pasi Kärkkäinen

2010-Feb-27 13:03 UTC

head link

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
Xen-users@lists.xensource.com
http://lists.xensource.com/xen-users

Jan Češčut

2010-Mar-02 13:42 UTC

head link

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

Thanks for thorough explanation.

Have a nice day,
Jan

-----Original Message-----
From: Pasi Kärkkäinen [mailto:pasik@iki.fi]
Sent: 27. februar 2010 14:04
To: Jan Češčut
Cc: xen-users@lists.xensource.com
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
Xen-users@lists.xensource.com
http://lists.xensource.com/xen-users

Sergio Charpinel Jr.

2010-Mar-05 17:01 UTC

head link

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

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''
----------- [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 <Jan.Cescut@kgs.si>
> Thanks for thorough explanation.
>
> Have a nice day,
> Jan
>
> -----Original Message-----
> From: Pasi Kärkkäinen [mailto:pasik@iki.fi]
> Sent: 27. februar 2010 14:04
> To: Jan Češčut
> Cc: xen-users@lists.xensource.com
> 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
> Xen-users@lists.xensource.com
> http://lists.xensource.com/xen-users
>


-- 
Sergio Roberto Charpinel Jr.


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

Pasi Kärkkäinen

2010-Mar-05 17:40 UTC

head link

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@kgs.si>
> 
>      Thanks for thorough explanation.
> 
>      Have a nice day,
>      Jan
>      -----Original Message-----
>      From: Pasi KÃ€rkkÃ€inen [mailto:[2]pasik@iki.fi]
>      Sent: 27. februar 2010 14:04
>      To: Jan Ä*eÅ¡Ä*ut
>      Cc: [3]xen-users@lists.xensource.com
>      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@lists.xensource.com
>      [5]http://lists.xensource.com/xen-users
> 
>    --
>    Sergio Roberto Charpinel Jr.
> 
> References
> 
>    Visible links
>    1. mailto:Jan.Cescut@kgs.si
>    2. mailto:pasik@iki.fi
>    3. mailto:xen-users@lists.xensource.com
>    4. mailto:Xen-users@lists.xensource.com
>    5. http://lists.xensource.com/xen-users
_______________________________________________
Xen-users mailing list
Xen-users@lists.xensource.com
http://lists.xensource.com/xen-users

Sergio Charpinel Jr.

2010-Mar-08 14:23 UTC

head link

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

Thanks Pasi,

Tried with Xen from CentOS 5.4 repo, and got the same error.
Also with extra = ''swiotlb=force'' in DomU conf file.

DomU boots, but when I start zoneminder (a software that access the webcam),
the kernel panic occurs.

I will test another application.

2010/3/5 Pasi Kärkkäinen <pasik@iki.fi>
> 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@kgs.si>
> >
> >      Thanks for thorough explanation.
> >
> >      Have a nice day,
> >      Jan
> >      -----Original Message-----
> >      From: Pasi KÃ€rkkÃ€inen [mailto:[2]pasik@iki.fi]
> >      Sent: 27. februar 2010 14:04
> >      To: Jan Ä*eÅ¡Ä*ut
> >      Cc: [3]xen-users@lists.xensource.com
> >      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@lists.xensource.com
> >      [5]http://lists.xensource.com/xen-users
> >
> >    --
> >    Sergio Roberto Charpinel Jr.
> >
> > References
> >
> >    Visible links
> >    1. mailto:Jan.Cescut@kgs.si
> >    2. mailto:pasik@iki.fi
> >    3. mailto:xen-users@lists.xensource.com
> >    4. mailto:Xen-users@lists.xensource.com
> >    5. http://lists.xensource.com/xen-users
>


-- 
Sergio Roberto Charpinel Jr.


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

Pasi Kärkkäinen

2010-Mar-08 14:25 UTC

head link

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

On Mon, Mar 08, 2010 at 11:23:44AM -0300, Sergio Charpinel Jr.
wrote:>    Thanks Pasi,
>    Tried with Xen from CentOS 5.4 repo, and got the same error.
>    Also with extra = ''swiotlb=force'' in DomU conf file.
>    DomU boots, but when I start zoneminder (a software that access the
>    webcam), the kernel panic occurs.
>    I will test another application.
> 
Is the PCI device you passthrough using a shared interrupt (IRQ)? 
If yes, that can (and will) cause problems.

-- Pasi
>    2010/3/5 Pasi Kärkkäinen <[1]pasik@iki.fi>
> 
>      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][2]Jan.Cescut@kgs.si>
>      >
>      >      Thanks for thorough explanation.
>      >
>      >      Have a nice day,
>      >      Jan
>      >      -----Original Message-----
>      >      From: Pasi KÃ*rkkÃ*inen [mailto:[2][3]pasik@iki.fi]
>      >      Sent: 27. februar 2010 14:04
>      >      To: Jan Ä*eÅ¡Ä*ut
>      >      Cc: [3][4]xen-users@lists.xensource.com
>      >      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][5]Xen-users@lists.xensource.com
>      >      [5][6]http://lists.xensource.com/xen-users
>      >
>      >    --
>      >    Sergio Roberto Charpinel Jr.
>      >

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

Sergio Charpinel Jr.

2010-Mar-08 15:04 UTC

head link

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

Pasi,

I dont know if I unbind the device correctly. I''m using this script:
modprobe pciback
BDF=0000:00:1d.3
# Unbind a PCI function from its driver as necessary
[ ! -e /sys/bus/pci/devices/$BDF/driver/unbind ] || \
        echo -n $BDF > /sys/bus/pci/devices/$BDF/driver/unbind
# Add a new slot to the PCI Backend''s list
echo -n $BDF > /sys/bus/pci/drivers/pciback/new_slot
# Now that the backend is watching for the slot, bind to it
echo -n $BDF > /sys/bus/pci/drivers/pciback/bind

And I got this in dmesg after running it:
uhci_hcd 0000:00:1d.3: remove, state 1
usb usb5: USB disconnect, address 1
usb 5-1: USB disconnect, address 2
drivers/media/video/stv680.c: [usb_stv680_remove_disconnected:1451] STV(i):
STV0680 disconnected
uhci_hcd 0000:00:1d.3: USB bus 5 deregistered
ACPI: PCI interrupt for device 0000:00:1d.3 disabled
pciback 0000:00:1d.3: seizing device
PCI: Enabling device 0000:00:1d.3 (0000 -> 0001)
ACPI: PCI Interrupt 0000:00:1d.3[D] -> GSI 22 (level, low) -> IRQ 21
ACPI: PCI interrupt for device 0000:00:1d.3 disabled
tap tap-1-51712: 2 getting info
pciback: vpci: 0000:00:1d.3: assign to virtual slot 0
ACPI: PCI interrupt for device 0000:00:1d.3 disabled
tap tap-2-51712: 2 getting info
pciback: vpci: 0000:00:1d.3: assign to virtual slot 0
device vif2.0 entered promiscuous mode
ADDRCONF(NETDEV_UP): vif2.0: link is not ready
PCI: Enabling device 0000:00:1d.3 (0000 -> 0001)
ACPI: PCI Interrupt 0000:00:1d.3[D] -> GSI 22 (level, low) -> IRQ 21
ACPI: PCI Interrupt 0000:00:1d.3[D] -> GSI 22 (level, low) -> IRQ 21
PCI: Setting latency timer of device 0000:00:1d.3 to 64
pciback 0000:00:1d.3: Driver tried to write to a read-only configuration
space field at offset 0xc0, size 2. This may be harmless, but if you have
problems with your device:
1) see permissive attribute in sysfs
2) report problems to the xen-devel mailing list along with details of your
device obtained from lspci.
blktap: ring-ref 9, event-channel 7, protocol 1 (x86_64-abi)


Also, here is the output of cat /proc/interrupts in dom0:

cat /proc/interrupts
           CPU0              CPU1              CPU2              CPU3

 ..
 20:         65          0          0          0        Phys-irq
 ehci_hcd:usb1, uhci_hcd:usb2, uhci_hcd:usb4
 21:         26          0          0          0        Phys-irq
 uhci_hcd:usb3
245:     127288          0          0         26        Phys-irq  peth0
...

and in domU:

cat /proc/interrupts
           CPU0
 21:          0        Phys-irq  uhci_hcd:usb1


As you see, I got an warning message in dmesg.

Do you know what could be?

2010/3/8 Pasi Kärkkäinen <pasik@iki.fi>
> On Mon, Mar 08, 2010 at 11:28:41AM -0300, Sergio Charpinel Jr. wrote:
> >    Not sure, how can I confirm?
> >
>
> Check /proc/interrupts and "lspci -vvv" in dom0.
> Also read dom0 "dmesg" output for the devices in question.
>
> -- Pasi
>
> >    2010/3/8 Pasi Kärkkäinen <[1]pasik@iki.fi>
> >
> >      On Mon, Mar 08, 2010 at 11:23:44AM -0300, Sergio Charpinel Jr.
> wrote:
> >      >    Thanks Pasi,
> >      >    Tried with Xen from CentOS 5.4 repo, and got the same
error.
> >      >    Also with extra = ''swiotlb=force'' in
DomU conf file.
> >      >    DomU boots, but when I start zoneminder (a software that
access
> the
> >      >    webcam), the kernel panic occurs.
> >      >    I will test another application.
> >      >
> >
> >      Is the PCI device you passthrough using a shared interrupt (IRQ)?
> >      If yes, that can (and will) cause problems.
> >
> >      -- Pasi
> >
> >      >    2010/3/5 Pasi Kärkkäinen <[1][2]pasik@iki.fi>
> >      >
> >      >      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][2][3]Jan.Cescut@kgs.si>
> >      >      >
> >      >      >      Thanks for thorough explanation.
> >      >      >
> >      >      >      Have a nice day,
> >      >      >      Jan
> >      >      >      -----Original Message-----
> >      >      >      From: Pasi KÃ*rkkÃ*inen
[mailto:[2][3][4]pasik@iki.fi
> ]
> >      >      >      Sent: 27. februar 2010 14:04
> >      >      >      To: Jan Ä*eÅ¡Ä*ut
> >      >      >      Cc: [3][4][5]xen-users@lists.xensource.com
> >      >      >      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][5][6]Xen-users@lists.xensource.com
> >      >      >      [5][6][7]http://lists.xensource.com/xen-users
> >      >      >
> >      >      >    --
> >      >      >    Sergio Roberto Charpinel Jr.
> >      >      >
> >
> >    --
> >    Sergio Roberto Charpinel Jr.
> >
> > References
> >
> >    Visible links
> >    1. mailto:pasik@iki.fi
> >    2. mailto:pasik@iki.fi
> >    3. mailto:Jan.Cescut@kgs.si
> >    4. mailto:pasik@iki.fi
> >    5. mailto:xen-users@lists.xensource.com
> >    6. mailto:Xen-users@lists.xensource.com
> >    7. http://lists.xensource.com/xen-users
>


-- 
Sergio Roberto Charpinel Jr.


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

Sergio Charpinel Jr.

2010-Mar-09 12:16 UTC

head link

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

Tried to access webcam with another application (xawtv) and got the same
error.

2010/3/8 Sergio Charpinel Jr. <sergiocharpinel@gmail.com>
> Pasi,
>
> I dont know if I unbind the device correctly. I''m using this
script:
> modprobe pciback
> BDF=0000:00:1d.3
> # Unbind a PCI function from its driver as necessary
> [ ! -e /sys/bus/pci/devices/$BDF/driver/unbind ] || \
>         echo -n $BDF > /sys/bus/pci/devices/$BDF/driver/unbind
> # Add a new slot to the PCI Backend''s list
> echo -n $BDF > /sys/bus/pci/drivers/pciback/new_slot
> # Now that the backend is watching for the slot, bind to it
> echo -n $BDF > /sys/bus/pci/drivers/pciback/bind
>
> And I got this in dmesg after running it:
> uhci_hcd 0000:00:1d.3: remove, state 1
> usb usb5: USB disconnect, address 1
> usb 5-1: USB disconnect, address 2
> drivers/media/video/stv680.c: [usb_stv680_remove_disconnected:1451] STV(i):
> STV0680 disconnected
> uhci_hcd 0000:00:1d.3: USB bus 5 deregistered
> ACPI: PCI interrupt for device 0000:00:1d.3 disabled
> pciback 0000:00:1d.3: seizing device
> PCI: Enabling device 0000:00:1d.3 (0000 -> 0001)
> ACPI: PCI Interrupt 0000:00:1d.3[D] -> GSI 22 (level, low) -> IRQ 21
> ACPI: PCI interrupt for device 0000:00:1d.3 disabled
> tap tap-1-51712: 2 getting info
> pciback: vpci: 0000:00:1d.3: assign to virtual slot 0
> ACPI: PCI interrupt for device 0000:00:1d.3 disabled
> tap tap-2-51712: 2 getting info
> pciback: vpci: 0000:00:1d.3: assign to virtual slot 0
> device vif2.0 entered promiscuous mode
> ADDRCONF(NETDEV_UP): vif2.0: link is not ready
> PCI: Enabling device 0000:00:1d.3 (0000 -> 0001)
> ACPI: PCI Interrupt 0000:00:1d.3[D] -> GSI 22 (level, low) -> IRQ 21
> ACPI: PCI Interrupt 0000:00:1d.3[D] -> GSI 22 (level, low) -> IRQ 21
> PCI: Setting latency timer of device 0000:00:1d.3 to 64
> pciback 0000:00:1d.3: Driver tried to write to a read-only configuration
> space field at offset 0xc0, size 2. This may be harmless, but if you have
> problems with your device:
> 1) see permissive attribute in sysfs
> 2) report problems to the xen-devel mailing list along with details of your
> device obtained from lspci.
> blktap: ring-ref 9, event-channel 7, protocol 1 (x86_64-abi)
>
>
> Also, here is the output of cat /proc/interrupts in dom0:
>
> cat /proc/interrupts
>            CPU0              CPU1              CPU2              CPU3
>
>  ..
>  20:         65          0          0          0        Phys-irq
>  ehci_hcd:usb1, uhci_hcd:usb2, uhci_hcd:usb4
>  21:         26          0          0          0        Phys-irq
>  uhci_hcd:usb3
> 245:     127288          0          0         26        Phys-irq  peth0
> ...
>
> and in domU:
>
> cat /proc/interrupts
>            CPU0
>  21:          0        Phys-irq  uhci_hcd:usb1
>
>
> As you see, I got an warning message in dmesg.
>
> Do you know what could be?
>
> 2010/3/8 Pasi Kärkkäinen <pasik@iki.fi>
>
> On Mon, Mar 08, 2010 at 11:28:41AM -0300, Sergio Charpinel Jr. wrote:
>> >    Not sure, how can I confirm?
>> >
>>
>> Check /proc/interrupts and "lspci -vvv" in dom0.
>> Also read dom0 "dmesg" output for the devices in question.
>>
>> -- Pasi
>>
>> >    2010/3/8 Pasi Kärkkäinen <[1]pasik@iki.fi>
>> >
>> >      On Mon, Mar 08, 2010 at 11:23:44AM -0300, Sergio Charpinel
Jr.
>> wrote:
>> >      >    Thanks Pasi,
>> >      >    Tried with Xen from CentOS 5.4 repo, and got the same
error.
>> >      >    Also with extra = ''swiotlb=force''
in DomU conf file.
>> >      >    DomU boots, but when I start zoneminder (a software
that
>> access the
>> >      >    webcam), the kernel panic occurs.
>> >      >    I will test another application.
>> >      >
>> >
>> >      Is the PCI device you passthrough using a shared interrupt
(IRQ)?
>> >      If yes, that can (and will) cause problems.
>> >
>> >      -- Pasi
>> >
>> >      >    2010/3/5 Pasi Kärkkäinen <[1][2]pasik@iki.fi>
>> >      >
>> >      >      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][2][3]Jan.Cescut@kgs.si>
>> >      >      >
>> >      >      >      Thanks for thorough explanation.
>> >      >      >
>> >      >      >      Have a nice day,
>> >      >      >      Jan
>> >      >      >      -----Original Message-----
>> >      >      >      From: Pasi KÃ*rkkÃ*inen [mailto:[2][3][4]
>> pasik@iki.fi]
>> >      >      >      Sent: 27. februar 2010 14:04
>> >      >      >      To: Jan Ä*eÅ¡Ä*ut
>> >      >      >      Cc:
[3][4][5]xen-users@lists.xensource.com
>> >      >      >      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][5][6]Xen-users@lists.xensource.com
>> >      >      >     
[5][6][7]http://lists.xensource.com/xen-users
>> >      >      >
>> >      >      >    --
>> >      >      >    Sergio Roberto Charpinel Jr.
>> >      >      >
>> >
>> >    --
>> >    Sergio Roberto Charpinel Jr.
>> >
>> > References
>> >
>> >    Visible links
>> >    1. mailto:pasik@iki.fi
>> >    2. mailto:pasik@iki.fi
>> >    3. mailto:Jan.Cescut@kgs.si
>> >    4. mailto:pasik@iki.fi
>> >    5. mailto:xen-users@lists.xensource.com
>> >    6. mailto:Xen-users@lists.xensource.com
>> >    7. http://lists.xensource.com/xen-users
>>
>
>
>
> --
> Sergio Roberto Charpinel Jr.
>


-- 
Sergio Roberto Charpinel Jr.


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

Pasi Kärkkäinen

2010-Mar-09 12:46 UTC

head link

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

On Tue, Mar 09, 2010 at 09:16:12AM -0300, Sergio Charpinel Jr.
wrote:>    Tried to access webcam with another application (xawtv) and got the same
>    error.
> 
Ok. The irq-related pastes are very unreadable below..

If you _don''t_ hide the USB controller from dom0, does it share IRQ
with some other device?
Ie. do you see the same IRQ (that the usb controller has) also for some other
device?

-- Pasi
>    2010/3/8 Sergio Charpinel Jr. <[1]sergiocharpinel@gmail.com>
> 
>      Pasi,
>      I dont know if I unbind the device correctly. I''m using this
script:
>      modprobe pciback
>      BDF=0000:00:1d.3
>      # Unbind a PCI function from its driver as necessary
>      [ ! -e /sys/bus/pci/devices/$BDF/driver/unbind ] || \
>              echo -n $BDF > /sys/bus/pci/devices/$BDF/driver/unbind
>      # Add a new slot to the PCI Backend''s list
>      echo -n $BDF > /sys/bus/pci/drivers/pciback/new_slot
>      # Now that the backend is watching for the slot, bind to it
>      echo -n $BDF > /sys/bus/pci/drivers/pciback/bind
>      And I got this in dmesg after running it:
>      uhci_hcd 0000:00:1d.3: remove, state 1
>      usb usb5: USB disconnect, address 1
>      usb 5-1: USB disconnect, address 2
>      drivers/media/video/stv680.c: [usb_stv680_remove_disconnected:1451]
>      STV(i): STV0680 disconnected
>      uhci_hcd 0000:00:1d.3: USB bus 5 deregistered
>      ACPI: PCI interrupt for device 0000:00:1d.3 disabled
>      pciback 0000:00:1d.3: seizing device
>      PCI: Enabling device 0000:00:1d.3 (0000 -> 0001)
>      ACPI: PCI Interrupt 0000:00:1d.3[D] -> GSI 22 (level, low) ->
IRQ 21
>      ACPI: PCI interrupt for device 0000:00:1d.3 disabled
>      tap tap-1-51712: 2 getting info
>      pciback: vpci: 0000:00:1d.3: assign to virtual slot 0
>      ACPI: PCI interrupt for device 0000:00:1d.3 disabled
>      tap tap-2-51712: 2 getting info
>      pciback: vpci: 0000:00:1d.3: assign to virtual slot 0
>      device vif2.0 entered promiscuous mode
>      ADDRCONF(NETDEV_UP): vif2.0: link is not ready
>      PCI: Enabling device 0000:00:1d.3 (0000 -> 0001)
>      ACPI: PCI Interrupt 0000:00:1d.3[D] -> GSI 22 (level, low) ->
IRQ 21
>      ACPI: PCI Interrupt 0000:00:1d.3[D] -> GSI 22 (level, low) ->
IRQ 21
>      PCI: Setting latency timer of device 0000:00:1d.3 to 64
>      pciback 0000:00:1d.3: Driver tried to write to a read-only
configuration
>      space field at offset 0xc0, size 2. This may be harmless, but if you
>      have problems with your device:
>      1) see permissive attribute in sysfs
>      2) report problems to the xen-devel mailing list along with details of
>      your device obtained from lspci.
>      blktap: ring-ref 9, event-channel 7, protocol 1 (x86_64-abi)
>      Also, here is the output of cat /proc/interrupts in dom0:
>      cat /proc/interrupts
>                 CPU0              CPU1              CPU2              CPU3
> 
>       ..
>       20:         65          0          0          0        Phys-irq
>       ehci_hcd:usb1, uhci_hcd:usb2, uhci_hcd:usb4
>       21:         26          0          0          0        Phys-irq
>       uhci_hcd:usb3
>      245:     127288          0          0         26        Phys-irq 
peth0
>      ...
>      and in domU:
> 
>      cat /proc/interrupts
>                 CPU0
>       21:          0        Phys-irq  uhci_hcd:usb1
>      As you see, I got an warning message in dmesg.
>      Do you know what could be?
>      2010/3/8 Pasi Kärkkäinen <[2]pasik@iki.fi>
> 
>        On Mon, Mar 08, 2010 at 11:28:41AM -0300, Sergio Charpinel Jr.
wrote:
>        >    Not sure, how can I confirm?
>        >
> 
>        Check /proc/interrupts and "lspci -vvv" in dom0.
>        Also read dom0 "dmesg" output for the devices in question.
> 
>        -- Pasi
> 
>        >    2010/3/8 Pasi Kärkkäinen <[1][3]pasik@iki.fi>
>        >
>        >      On Mon, Mar 08, 2010 at 11:23:44AM -0300, Sergio Charpinel
Jr.
>        wrote:
>        >      >    Thanks Pasi,
>        >      >    Tried with Xen from CentOS 5.4 repo, and got the
same
>        error.
>        >      >    Also with extra =
''swiotlb=force'' in DomU conf file.
>        >      >    DomU boots, but when I start zoneminder (a
software that
>        access the
>        >      >    webcam), the kernel panic occurs.
>        >      >    I will test another application.
>        >      >
>        >
>        >      Is the PCI device you passthrough using a shared interrupt
>        (IRQ)?
>        >      If yes, that can (and will) cause problems.
>        >
>        >      -- Pasi
>        >
>        >      >    2010/3/5 Pasi Kärkkäinen
<[1][2][4]pasik@iki.fi>
>        >      >
>        >      >      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][2][3][5]Jan.Cescut@kgs.si>
>        >      >      >
>        >      >      >      Thanks for thorough explanation.
>        >      >      >
>        >      >      >      Have a nice day,
>        >      >      >      Jan
>        >      >      >      -----Original Message-----
>        >      >      >      From: Pasi KÃ*rkkÃ*inen
>        [mailto:[2][3][4][6]pasik@iki.fi]
>        >      >      >      Sent: 27. februar 2010 14:04
>        >      >      >      To: Jan Ä*eÅ¡Ä*ut
>        >      >      >      Cc:
[3][4][5][7]xen-users@lists.xensource.com
>        >      >      >      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][5][6][8]Xen-users@lists.xensource.com
>        >      >      >     
[5][6][7][9]http://lists.xensource.com/xen-users
>        >      >      >
>        >      >      >    --
>        >      >      >    Sergio Roberto Charpinel Jr.
>        >      >      >
>        >
>        >    --
>        >    Sergio Roberto Charpinel Jr.
>        >
>        > References
>        >
>        >    Visible links
>        >    1. mailto:[10]pasik@iki.fi
>        >    2. mailto:[11]pasik@iki.fi
>        >    3. mailto:[12]Jan.Cescut@kgs.si
>        >    4. mailto:[13]pasik@iki.fi
>        >    5. mailto:[14]xen-users@lists.xensource.com
>        >    6. mailto:[15]Xen-users@lists.xensource.com
>        >    7. [16]http://lists.xensource.com/xen-users
> 
>      --
>      Sergio Roberto Charpinel Jr.
> 
>    --
>    Sergio Roberto Charpinel Jr.
> 
> References
> 
>    Visible links
>    1. mailto:sergiocharpinel@gmail.com
>    2. mailto:pasik@iki.fi
>    3. mailto:pasik@iki.fi
>    4. mailto:pasik@iki.fi
>    5. mailto:Jan.Cescut@kgs.si
>    6. mailto:pasik@iki.fi
>    7. mailto:xen-users@lists.xensource.com
>    8. mailto:Xen-users@lists.xensource.com
>    9. http://lists.xensource.com/xen-users
>   10. mailto:pasik@iki.fi
>   11. mailto:pasik@iki.fi
>   12. mailto:Jan.Cescut@kgs.si
>   13. mailto:pasik@iki.fi
>   14. mailto:xen-users@lists.xensource.com
>   15. mailto:Xen-users@lists.xensource.com
>   16. http://lists.xensource.com/xen-users
_______________________________________________
Xen-users mailing list
Xen-users@lists.xensource.com
http://lists.xensource.com/xen-users

Sergio Charpinel Jr.

2010-Mar-09 13:36 UTC

head link

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

I dont know if it is the information you asked, but with cat
/proc/interrupts, i got this:

21:         25          0          0          0        Phys-irq
 uhci_hcd:usb3, uhci_hcd:usb5

But now, I think that it is something related to CentOS kernel.
I saw some posts related to my problem, and some people resolved setting
pciback.permissive option. But, seems like in CentOS we can''t set it.

http://lists.xensource.com/archives/html/xen-users/2008-02/msg00247.html
http://osdir.com/ml/centos/2009-11/msg00766.html
http://lists.centos.org/pipermail/centos-virt/2008-September/000632.html

2010/3/9 Pasi Kärkkäinen <pasik@iki.fi>
> On Tue, Mar 09, 2010 at 09:16:12AM -0300, Sergio Charpinel Jr. wrote:
> >    Tried to access webcam with another application (xawtv) and got the
> same
> >    error.
> >
>
> Ok. The irq-related pastes are very unreadable below..
>
> If you _don''t_ hide the USB controller from dom0, does it share
IRQ with
> some other device?
> Ie. do you see the same IRQ (that the usb controller has) also for some
> other device?
>
> -- Pasi
>
> >    2010/3/8 Sergio Charpinel Jr. <[1]sergiocharpinel@gmail.com>
> >
> >      Pasi,
> >      I dont know if I unbind the device correctly. I''m using
this script:
> >      modprobe pciback
> >      BDF=0000:00:1d.3
> >      # Unbind a PCI function from its driver as necessary
> >      [ ! -e /sys/bus/pci/devices/$BDF/driver/unbind ] || \
> >              echo -n $BDF > /sys/bus/pci/devices/$BDF/driver/unbind
> >      # Add a new slot to the PCI Backend''s list
> >      echo -n $BDF > /sys/bus/pci/drivers/pciback/new_slot
> >      # Now that the backend is watching for the slot, bind to it
> >      echo -n $BDF > /sys/bus/pci/drivers/pciback/bind
> >      And I got this in dmesg after running it:
> >      uhci_hcd 0000:00:1d.3: remove, state 1
> >      usb usb5: USB disconnect, address 1
> >      usb 5-1: USB disconnect, address 2
> >      drivers/media/video/stv680.c:
[usb_stv680_remove_disconnected:1451]
> >      STV(i): STV0680 disconnected
> >      uhci_hcd 0000:00:1d.3: USB bus 5 deregistered
> >      ACPI: PCI interrupt for device 0000:00:1d.3 disabled
> >      pciback 0000:00:1d.3: seizing device
> >      PCI: Enabling device 0000:00:1d.3 (0000 -> 0001)
> >      ACPI: PCI Interrupt 0000:00:1d.3[D] -> GSI 22 (level, low)
-> IRQ 21
> >      ACPI: PCI interrupt for device 0000:00:1d.3 disabled
> >      tap tap-1-51712: 2 getting info
> >      pciback: vpci: 0000:00:1d.3: assign to virtual slot 0
> >      ACPI: PCI interrupt for device 0000:00:1d.3 disabled
> >      tap tap-2-51712: 2 getting info
> >      pciback: vpci: 0000:00:1d.3: assign to virtual slot 0
> >      device vif2.0 entered promiscuous mode
> >      ADDRCONF(NETDEV_UP): vif2.0: link is not ready
> >      PCI: Enabling device 0000:00:1d.3 (0000 -> 0001)
> >      ACPI: PCI Interrupt 0000:00:1d.3[D] -> GSI 22 (level, low)
-> IRQ 21
> >      ACPI: PCI Interrupt 0000:00:1d.3[D] -> GSI 22 (level, low)
-> IRQ 21
> >      PCI: Setting latency timer of device 0000:00:1d.3 to 64
> >      pciback 0000:00:1d.3: Driver tried to write to a read-only
> configuration
> >      space field at offset 0xc0, size 2. This may be harmless, but if
you
> >      have problems with your device:
> >      1) see permissive attribute in sysfs
> >      2) report problems to the xen-devel mailing list along with
details
> of
> >      your device obtained from lspci.
> >      blktap: ring-ref 9, event-channel 7, protocol 1 (x86_64-abi)
> >      Also, here is the output of cat /proc/interrupts in dom0:
> >      cat /proc/interrupts
> >                 CPU0              CPU1              CPU2
>  CPU3
> >
> >       ..
> >       20:         65          0          0          0        Phys-irq
> >       ehci_hcd:usb1, uhci_hcd:usb2, uhci_hcd:usb4
> >       21:         26          0          0          0        Phys-irq
> >       uhci_hcd:usb3
> >      245:     127288          0          0         26        Phys-irq
>  peth0
> >      ...
> >      and in domU:
> >
> >      cat /proc/interrupts
> >                 CPU0
> >       21:          0        Phys-irq  uhci_hcd:usb1
> >      As you see, I got an warning message in dmesg.
> >      Do you know what could be?
> >      2010/3/8 Pasi Kärkkäinen <[2]pasik@iki.fi>
> >
> >        On Mon, Mar 08, 2010 at 11:28:41AM -0300, Sergio Charpinel Jr.
> wrote:
> >        >    Not sure, how can I confirm?
> >        >
> >
> >        Check /proc/interrupts and "lspci -vvv" in dom0.
> >        Also read dom0 "dmesg" output for the devices in
question.
> >
> >        -- Pasi
> >
> >        >    2010/3/8 Pasi Kärkkäinen <[1][3]pasik@iki.fi>
> >        >
> >        >      On Mon, Mar 08, 2010 at 11:23:44AM -0300, Sergio
Charpinel
> Jr.
> >        wrote:
> >        >      >    Thanks Pasi,
> >        >      >    Tried with Xen from CentOS 5.4 repo, and got
the same
> >        error.
> >        >      >    Also with extra =
''swiotlb=force'' in DomU conf file.
> >        >      >    DomU boots, but when I start zoneminder (a
software
> that
> >        access the
> >        >      >    webcam), the kernel panic occurs.
> >        >      >    I will test another application.
> >        >      >
> >        >
> >        >      Is the PCI device you passthrough using a shared
interrupt
> >        (IRQ)?
> >        >      If yes, that can (and will) cause problems.
> >        >
> >        >      -- Pasi
> >        >
> >        >      >    2010/3/5 Pasi Kärkkäinen
<[1][2][4]pasik@iki.fi>
> >        >      >
> >        >      >      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][2][3][5]Jan.Cescut@kgs.si>
> >        >      >      >
> >        >      >      >      Thanks for thorough explanation.
> >        >      >      >
> >        >      >      >      Have a nice day,
> >        >      >      >      Jan
> >        >      >      >      -----Original Message-----
> >        >      >      >      From: Pasi KÃ*rkkÃ*inen
> >        [mailto:[2][3][4][6]pasik@iki.fi]
> >        >      >      >      Sent: 27. februar 2010 14:04
> >        >      >      >      To: Jan Ä*eÅ¡Ä*ut
> >        >      >      >      Cc: [3][4][5][7]
> xen-users@lists.xensource.com
> >        >      >      >      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][5][6][8]Xen-users@lists.xensource.com
> >        >      >      >      [5][6][7][9]
> http://lists.xensource.com/xen-users
> >        >      >      >
> >        >      >      >    --
> >        >      >      >    Sergio Roberto Charpinel Jr.
> >        >      >      >
> >        >
> >        >    --
> >        >    Sergio Roberto Charpinel Jr.
> >        >
> >        > References
> >        >
> >        >    Visible links
> >        >    1. mailto:[10]pasik@iki.fi
> >        >    2. mailto:[11]pasik@iki.fi
> >        >    3. mailto:[12]Jan.Cescut@kgs.si
> >        >    4. mailto:[13]pasik@iki.fi
> >        >    5. mailto:[14]xen-users@lists.xensource.com
> >        >    6. mailto:[15]Xen-users@lists.xensource.com
> >        >    7. [16]http://lists.xensource.com/xen-users
> >
> >      --
> >      Sergio Roberto Charpinel Jr.
> >
> >    --
> >    Sergio Roberto Charpinel Jr.
> >
> > References
> >
> >    Visible links
> >    1. mailto:sergiocharpinel@gmail.com
> >    2. mailto:pasik@iki.fi
> >    3. mailto:pasik@iki.fi
> >    4. mailto:pasik@iki.fi
> >    5. mailto:Jan.Cescut@kgs.si
> >    6. mailto:pasik@iki.fi
> >    7. mailto:xen-users@lists.xensource.com
> >    8. mailto:Xen-users@lists.xensource.com
> >    9. http://lists.xensource.com/xen-users
> >   10. mailto:pasik@iki.fi
> >   11. mailto:pasik@iki.fi
> >   12. mailto:Jan.Cescut@kgs.si
> >   13. mailto:pasik@iki.fi
> >   14. mailto:xen-users@lists.xensource.com
> >   15. mailto:Xen-users@lists.xensource.com
> >   16. http://lists.xensource.com/xen-users
>


-- 
Sergio Roberto Charpinel Jr.


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

Sergio Charpinel Jr.

2010-Mar-15 13:25 UTC

head link

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

Hi,

After recompiling linux-2.18.6-xen.hg and changing XEN -> PCI backend Mode
from Virtual PCI to Passthrough and resolving some dependences (blk as
module, enable SATA_PIIX) , it worked.

Dont know if those options are necessary.

Thanks for the attention, and hope this helps someone.


2010/3/9 Sergio Charpinel Jr. <sergiocharpinel@gmail.com>
> I dont know if it is the information you asked, but with cat
> /proc/interrupts, i got this:
>
> 21:         25          0          0          0        Phys-irq
>  uhci_hcd:usb3, uhci_hcd:usb5
>
> But now, I think that it is something related to CentOS kernel.
> I saw some posts related to my problem, and some people resolved setting
> pciback.permissive option. But, seems like in CentOS we can''t set
it.
>
> http://lists.xensource.com/archives/html/xen-users/2008-02/msg00247.html
> http://osdir.com/ml/centos/2009-11/msg00766.html
> http://lists.centos.org/pipermail/centos-virt/2008-September/000632.html
>
> 2010/3/9 Pasi Kärkkäinen <pasik@iki.fi>
>
> On Tue, Mar 09, 2010 at 09:16:12AM -0300, Sergio Charpinel Jr. wrote:
>> >    Tried to access webcam with another application (xawtv) and got
the
>> same
>> >    error.
>> >
>>
>> Ok. The irq-related pastes are very unreadable below..
>>
>> If you _don''t_ hide the USB controller from dom0, does it
share IRQ with
>> some other device?
>> Ie. do you see the same IRQ (that the usb controller has) also for some
>> other device?
>>
>> -- Pasi
>>
>> >    2010/3/8 Sergio Charpinel Jr.
<[1]sergiocharpinel@gmail.com>
>> >
>> >      Pasi,
>> >      I dont know if I unbind the device correctly. I''m
using this
>> script:
>> >      modprobe pciback
>> >      BDF=0000:00:1d.3
>> >      # Unbind a PCI function from its driver as necessary
>> >      [ ! -e /sys/bus/pci/devices/$BDF/driver/unbind ] || \
>> >              echo -n $BDF >
/sys/bus/pci/devices/$BDF/driver/unbind
>> >      # Add a new slot to the PCI Backend''s list
>> >      echo -n $BDF > /sys/bus/pci/drivers/pciback/new_slot
>> >      # Now that the backend is watching for the slot, bind to it
>> >      echo -n $BDF > /sys/bus/pci/drivers/pciback/bind
>> >      And I got this in dmesg after running it:
>> >      uhci_hcd 0000:00:1d.3: remove, state 1
>> >      usb usb5: USB disconnect, address 1
>> >      usb 5-1: USB disconnect, address 2
>> >      drivers/media/video/stv680.c:
[usb_stv680_remove_disconnected:1451]
>> >      STV(i): STV0680 disconnected
>> >      uhci_hcd 0000:00:1d.3: USB bus 5 deregistered
>> >      ACPI: PCI interrupt for device 0000:00:1d.3 disabled
>> >      pciback 0000:00:1d.3: seizing device
>> >      PCI: Enabling device 0000:00:1d.3 (0000 -> 0001)
>> >      ACPI: PCI Interrupt 0000:00:1d.3[D] -> GSI 22 (level, low)
-> IRQ
>> 21
>> >      ACPI: PCI interrupt for device 0000:00:1d.3 disabled
>> >      tap tap-1-51712: 2 getting info
>> >      pciback: vpci: 0000:00:1d.3: assign to virtual slot 0
>> >      ACPI: PCI interrupt for device 0000:00:1d.3 disabled
>> >      tap tap-2-51712: 2 getting info
>> >      pciback: vpci: 0000:00:1d.3: assign to virtual slot 0
>> >      device vif2.0 entered promiscuous mode
>> >      ADDRCONF(NETDEV_UP): vif2.0: link is not ready
>> >      PCI: Enabling device 0000:00:1d.3 (0000 -> 0001)
>> >      ACPI: PCI Interrupt 0000:00:1d.3[D] -> GSI 22 (level, low)
-> IRQ
>> 21
>> >      ACPI: PCI Interrupt 0000:00:1d.3[D] -> GSI 22 (level, low)
-> IRQ
>> 21
>> >      PCI: Setting latency timer of device 0000:00:1d.3 to 64
>> >      pciback 0000:00:1d.3: Driver tried to write to a read-only
>> configuration
>> >      space field at offset 0xc0, size 2. This may be harmless, but
if
>> you
>> >      have problems with your device:
>> >      1) see permissive attribute in sysfs
>> >      2) report problems to the xen-devel mailing list along with
details
>> of
>> >      your device obtained from lspci.
>> >      blktap: ring-ref 9, event-channel 7, protocol 1 (x86_64-abi)
>> >      Also, here is the output of cat /proc/interrupts in dom0:
>> >      cat /proc/interrupts
>> >                 CPU0              CPU1              CPU2
>>  CPU3
>> >
>> >       ..
>> >       20:         65          0          0          0       
Phys-irq
>> >       ehci_hcd:usb1, uhci_hcd:usb2, uhci_hcd:usb4
>> >       21:         26          0          0          0       
Phys-irq
>> >       uhci_hcd:usb3
>> >      245:     127288          0          0         26       
Phys-irq
>>  peth0
>> >      ...
>> >      and in domU:
>> >
>> >      cat /proc/interrupts
>> >                 CPU0
>> >       21:          0        Phys-irq  uhci_hcd:usb1
>> >      As you see, I got an warning message in dmesg.
>> >      Do you know what could be?
>> >      2010/3/8 Pasi Kärkkäinen <[2]pasik@iki.fi>
>> >
>> >        On Mon, Mar 08, 2010 at 11:28:41AM -0300, Sergio Charpinel
Jr.
>> wrote:
>> >        >    Not sure, how can I confirm?
>> >        >
>> >
>> >        Check /proc/interrupts and "lspci -vvv" in dom0.
>> >        Also read dom0 "dmesg" output for the devices in
question.
>> >
>> >        -- Pasi
>> >
>> >        >    2010/3/8 Pasi Kärkkäinen <[1][3]pasik@iki.fi>
>> >        >
>> >        >      On Mon, Mar 08, 2010 at 11:23:44AM -0300, Sergio
Charpinel
>> Jr.
>> >        wrote:
>> >        >      >    Thanks Pasi,
>> >        >      >    Tried with Xen from CentOS 5.4 repo, and
got the same
>> >        error.
>> >        >      >    Also with extra =
''swiotlb=force'' in DomU conf file.
>> >        >      >    DomU boots, but when I start zoneminder
(a software
>> that
>> >        access the
>> >        >      >    webcam), the kernel panic occurs.
>> >        >      >    I will test another application.
>> >        >      >
>> >        >
>> >        >      Is the PCI device you passthrough using a shared
interrupt
>> >        (IRQ)?
>> >        >      If yes, that can (and will) cause problems.
>> >        >
>> >        >      -- Pasi
>> >        >
>> >        >      >    2010/3/5 Pasi Kärkkäinen
<[1][2][4]pasik@iki.fi>
>> >        >      >
>> >        >      >      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][2][3][5]Jan.Cescut@kgs.si>
>> >        >      >      >
>> >        >      >      >      Thanks for thorough
explanation.
>> >        >      >      >
>> >        >      >      >      Have a nice day,
>> >        >      >      >      Jan
>> >        >      >      >      -----Original Message-----
>> >        >      >      >      From: Pasi KÃ*rkkÃ*inen
>> >        [mailto:[2][3][4][6]pasik@iki.fi]
>> >        >      >      >      Sent: 27. februar 2010 14:04
>> >        >      >      >      To: Jan Ä*eÅ¡Ä*ut
>> >        >      >      >      Cc: [3][4][5][7]
>> xen-users@lists.xensource.com
>> >        >      >      >      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][5][6][8]Xen-users@lists.xensource.com
>> >        >      >      >      [5][6][7][9]
>> http://lists.xensource.com/xen-users
>> >        >      >      >
>> >        >      >      >    --
>> >        >      >      >    Sergio Roberto Charpinel Jr.
>> >        >      >      >
>> >        >
>> >        >    --
>> >        >    Sergio Roberto Charpinel Jr.
>> >        >
>> >        > References
>> >        >
>> >        >    Visible links
>> >        >    1. mailto:[10]pasik@iki.fi
>> >        >    2. mailto:[11]pasik@iki.fi
>> >        >    3. mailto:[12]Jan.Cescut@kgs.si
>> >        >    4. mailto:[13]pasik@iki.fi
>> >        >    5. mailto:[14]xen-users@lists.xensource.com
>> >        >    6. mailto:[15]Xen-users@lists.xensource.com
>> >        >    7. [16]http://lists.xensource.com/xen-users
>> >
>> >      --
>> >      Sergio Roberto Charpinel Jr.
>> >
>> >    --
>> >    Sergio Roberto Charpinel Jr.
>> >
>> > References
>> >
>> >    Visible links
>> >    1. mailto:sergiocharpinel@gmail.com
>> >    2. mailto:pasik@iki.fi
>> >    3. mailto:pasik@iki.fi
>> >    4. mailto:pasik@iki.fi
>> >    5. mailto:Jan.Cescut@kgs.si
>> >    6. mailto:pasik@iki.fi
>> >    7. mailto:xen-users@lists.xensource.com
>> >    8. mailto:Xen-users@lists.xensource.com
>> >    9. http://lists.xensource.com/xen-users
>> >   10. mailto:pasik@iki.fi
>> >   11. mailto:pasik@iki.fi
>> >   12. mailto:Jan.Cescut@kgs.si
>> >   13. mailto:pasik@iki.fi
>> >   14. mailto:xen-users@lists.xensource.com
>> >   15. mailto:Xen-users@lists.xensource.com
>> >   16. http://lists.xensource.com/xen-users
>>
>
>
>
> --
> Sergio Roberto Charpinel Jr.
>


-- 
Sergio Roberto Charpinel Jr.


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

Sergio Charpinel Jr.

2010-Mar-15 14:15 UTC

head link

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

No sorry,
Just worked with a different cam. Testing with the other one results in the
same error. It is assigned to another device.

Maybe is a shared interruption problem, like Pasi said.


2010/3/15 Sergio Charpinel Jr. <sergiocharpinel@gmail.com>
> Hi,
>
> After recompiling linux-2.18.6-xen.hg and changing XEN -> PCI backend
Mode
> from Virtual PCI to Passthrough and resolving some dependences (blk as
> module, enable SATA_PIIX) , it worked.
>
> Dont know if those options are necessary.
>
> Thanks for the attention, and hope this helps someone.
>
>
> 2010/3/9 Sergio Charpinel Jr. <sergiocharpinel@gmail.com>
>
> I dont know if it is the information you asked, but with cat
>> /proc/interrupts, i got this:
>>
>> 21:         25          0          0          0        Phys-irq
>>  uhci_hcd:usb3, uhci_hcd:usb5
>>
>> But now, I think that it is something related to CentOS kernel.
>> I saw some posts related to my problem, and some people resolved
setting
>> pciback.permissive option. But, seems like in CentOS we can''t
set it.
>>
>>
http://lists.xensource.com/archives/html/xen-users/2008-02/msg00247.html
>> http://osdir.com/ml/centos/2009-11/msg00766.html
>>
http://lists.centos.org/pipermail/centos-virt/2008-September/000632.html
>>
>> 2010/3/9 Pasi Kärkkäinen <pasik@iki.fi>
>>
>> On Tue, Mar 09, 2010 at 09:16:12AM -0300, Sergio Charpinel Jr. wrote:
>>> >    Tried to access webcam with another application (xawtv) and
got the
>>> same
>>> >    error.
>>> >
>>>
>>> Ok. The irq-related pastes are very unreadable below..
>>>
>>> If you _don''t_ hide the USB controller from dom0, does it
share IRQ with
>>> some other device?
>>> Ie. do you see the same IRQ (that the usb controller has) also for
some
>>> other device?
>>>
>>> -- Pasi
>>>
>>> >    2010/3/8 Sergio Charpinel Jr.
<[1]sergiocharpinel@gmail.com>
>>> >
>>> >      Pasi,
>>> >      I dont know if I unbind the device correctly.
I''m using this
>>> script:
>>> >      modprobe pciback
>>> >      BDF=0000:00:1d.3
>>> >      # Unbind a PCI function from its driver as necessary
>>> >      [ ! -e /sys/bus/pci/devices/$BDF/driver/unbind ] || \
>>> >              echo -n $BDF >
/sys/bus/pci/devices/$BDF/driver/unbind
>>> >      # Add a new slot to the PCI Backend''s list
>>> >      echo -n $BDF > /sys/bus/pci/drivers/pciback/new_slot
>>> >      # Now that the backend is watching for the slot, bind to
it
>>> >      echo -n $BDF > /sys/bus/pci/drivers/pciback/bind
>>> >      And I got this in dmesg after running it:
>>> >      uhci_hcd 0000:00:1d.3: remove, state 1
>>> >      usb usb5: USB disconnect, address 1
>>> >      usb 5-1: USB disconnect, address 2
>>> >      drivers/media/video/stv680.c:
>>> [usb_stv680_remove_disconnected:1451]
>>> >      STV(i): STV0680 disconnected
>>> >      uhci_hcd 0000:00:1d.3: USB bus 5 deregistered
>>> >      ACPI: PCI interrupt for device 0000:00:1d.3 disabled
>>> >      pciback 0000:00:1d.3: seizing device
>>> >      PCI: Enabling device 0000:00:1d.3 (0000 -> 0001)
>>> >      ACPI: PCI Interrupt 0000:00:1d.3[D] -> GSI 22 (level,
low) -> IRQ
>>> 21
>>> >      ACPI: PCI interrupt for device 0000:00:1d.3 disabled
>>> >      tap tap-1-51712: 2 getting info
>>> >      pciback: vpci: 0000:00:1d.3: assign to virtual slot 0
>>> >      ACPI: PCI interrupt for device 0000:00:1d.3 disabled
>>> >      tap tap-2-51712: 2 getting info
>>> >      pciback: vpci: 0000:00:1d.3: assign to virtual slot 0
>>> >      device vif2.0 entered promiscuous mode
>>> >      ADDRCONF(NETDEV_UP): vif2.0: link is not ready
>>> >      PCI: Enabling device 0000:00:1d.3 (0000 -> 0001)
>>> >      ACPI: PCI Interrupt 0000:00:1d.3[D] -> GSI 22 (level,
low) -> IRQ
>>> 21
>>> >      ACPI: PCI Interrupt 0000:00:1d.3[D] -> GSI 22 (level,
low) -> IRQ
>>> 21
>>> >      PCI: Setting latency timer of device 0000:00:1d.3 to 64
>>> >      pciback 0000:00:1d.3: Driver tried to write to a
read-only
>>> configuration
>>> >      space field at offset 0xc0, size 2. This may be harmless,
but if
>>> you
>>> >      have problems with your device:
>>> >      1) see permissive attribute in sysfs
>>> >      2) report problems to the xen-devel mailing list along
with
>>> details of
>>> >      your device obtained from lspci.
>>> >      blktap: ring-ref 9, event-channel 7, protocol 1
(x86_64-abi)
>>> >      Also, here is the output of cat /proc/interrupts in dom0:
>>> >      cat /proc/interrupts
>>> >                 CPU0              CPU1              CPU2
>>>  CPU3
>>> >
>>> >       ..
>>> >       20:         65          0          0          0       
Phys-irq
>>> >       ehci_hcd:usb1, uhci_hcd:usb2, uhci_hcd:usb4
>>> >       21:         26          0          0          0       
Phys-irq
>>> >       uhci_hcd:usb3
>>> >      245:     127288          0          0         26       
Phys-irq
>>>  peth0
>>> >      ...
>>> >      and in domU:
>>> >
>>> >      cat /proc/interrupts
>>> >                 CPU0
>>> >       21:          0        Phys-irq  uhci_hcd:usb1
>>> >      As you see, I got an warning message in dmesg.
>>> >      Do you know what could be?
>>> >      2010/3/8 Pasi Kärkkäinen <[2]pasik@iki.fi>
>>> >
>>> >        On Mon, Mar 08, 2010 at 11:28:41AM -0300, Sergio
Charpinel Jr.
>>> wrote:
>>> >        >    Not sure, how can I confirm?
>>> >        >
>>> >
>>> >        Check /proc/interrupts and "lspci -vvv" in
dom0.
>>> >        Also read dom0 "dmesg" output for the devices
in question.
>>> >
>>> >        -- Pasi
>>> >
>>> >        >    2010/3/8 Pasi Kärkkäinen
<[1][3]pasik@iki.fi>
>>> >        >
>>> >        >      On Mon, Mar 08, 2010 at 11:23:44AM -0300,
Sergio
>>> Charpinel Jr.
>>> >        wrote:
>>> >        >      >    Thanks Pasi,
>>> >        >      >    Tried with Xen from CentOS 5.4 repo,
and got the
>>> same
>>> >        error.
>>> >        >      >    Also with extra =
''swiotlb=force'' in DomU conf file.
>>> >        >      >    DomU boots, but when I start
zoneminder (a software
>>> that
>>> >        access the
>>> >        >      >    webcam), the kernel panic occurs.
>>> >        >      >    I will test another application.
>>> >        >      >
>>> >        >
>>> >        >      Is the PCI device you passthrough using a
shared
>>> interrupt
>>> >        (IRQ)?
>>> >        >      If yes, that can (and will) cause problems.
>>> >        >
>>> >        >      -- Pasi
>>> >        >
>>> >        >      >    2010/3/5 Pasi Kärkkäinen
<[1][2][4]pasik@iki.fi>
>>> >        >      >
>>> >        >      >      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][2][3][5]Jan.Cescut@kgs.si>
>>> >        >      >      >
>>> >        >      >      >      Thanks for thorough
explanation.
>>> >        >      >      >
>>> >        >      >      >      Have a nice day,
>>> >        >      >      >      Jan
>>> >        >      >      >      -----Original
Message-----
>>> >        >      >      >      From: Pasi KÃ*rkkÃ*inen
>>> >        [mailto:[2][3][4][6]pasik@iki.fi]
>>> >        >      >      >      Sent: 27. februar 2010
14:04
>>> >        >      >      >      To: Jan Ä*eÅ¡Ä*ut
>>> >        >      >      >      Cc: [3][4][5][7]
>>> xen-users@lists.xensource.com
>>> >        >      >      >      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][5][6][8]Xen-users@lists.xensource.com
>>> >        >      >      >      [5][6][7][9]
>>> http://lists.xensource.com/xen-users
>>> >        >      >      >
>>> >        >      >      >    --
>>> >        >      >      >    Sergio Roberto Charpinel
Jr.
>>> >        >      >      >
>>> >        >
>>> >        >    --
>>> >        >    Sergio Roberto Charpinel Jr.
>>> >        >
>>> >        > References
>>> >        >
>>> >        >    Visible links
>>> >        >    1. mailto:[10]pasik@iki.fi
>>> >        >    2. mailto:[11]pasik@iki.fi
>>> >        >    3. mailto:[12]Jan.Cescut@kgs.si
>>> >        >    4. mailto:[13]pasik@iki.fi
>>> >        >    5. mailto:[14]xen-users@lists.xensource.com
>>> >        >    6. mailto:[15]Xen-users@lists.xensource.com
>>> >        >    7. [16]http://lists.xensource.com/xen-users
>>> >
>>> >      --
>>> >      Sergio Roberto Charpinel Jr.
>>> >
>>> >    --
>>> >    Sergio Roberto Charpinel Jr.
>>> >
>>> > References
>>> >
>>> >    Visible links
>>> >    1. mailto:sergiocharpinel@gmail.com
>>> >    2. mailto:pasik@iki.fi
>>> >    3. mailto:pasik@iki.fi
>>> >    4. mailto:pasik@iki.fi
>>> >    5. mailto:Jan.Cescut@kgs.si
>>> >    6. mailto:pasik@iki.fi
>>> >    7. mailto:xen-users@lists.xensource.com
>>> >    8. mailto:Xen-users@lists.xensource.com
>>> >    9. http://lists.xensource.com/xen-users
>>> >   10. mailto:pasik@iki.fi
>>> >   11. mailto:pasik@iki.fi
>>> >   12. mailto:Jan.Cescut@kgs.si
>>> >   13. mailto:pasik@iki.fi
>>> >   14. mailto:xen-users@lists.xensource.com
>>> >   15. mailto:Xen-users@lists.xensource.com
>>> >   16. http://lists.xensource.com/xen-users
>>>
>>
>>
>>
>> --
>> Sergio Roberto Charpinel Jr.
>>
>
>
>
> --
> Sergio Roberto Charpinel Jr.
>


-- 
Sergio Roberto Charpinel Jr.


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

Sergio Charpinel Jr.

2010-Mar-16 17:20 UTC

head link

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

HI, Finally I it worked. I will post the results that I got, and hope this
helps someone.

- I''m using CentOS 5.4 and it just worked after recompiling xen.hg
kernel. I
changed this options:
 + PCI Backend inside kernel (not as module)
 + PCI Backend mode to Passthrogh

- Set pciback.permissive and pciback.hide in kernel boot config

- Couldnt make it work with 2 pendrives and a webcam that can be used as
pendrive. With two others webcam (normal webcam), it worked.

Bye

2010/3/15 Sergio Charpinel Jr. <sergiocharpinel@gmail.com>
> No sorry,
> Just worked with a different cam. Testing with the other one results in the
> same error. It is assigned to another device.
>
> Maybe is a shared interruption problem, like Pasi said.
>
>
> 2010/3/15 Sergio Charpinel Jr. <sergiocharpinel@gmail.com>
>
> Hi,
>>
>> After recompiling linux-2.18.6-xen.hg and changing XEN -> PCI
backend Mode
>> from Virtual PCI to Passthrough and resolving some dependences (blk as
>> module, enable SATA_PIIX) , it worked.
>>
>> Dont know if those options are necessary.
>>
>> Thanks for the attention, and hope this helps someone.
>>
>>
>> 2010/3/9 Sergio Charpinel Jr. <sergiocharpinel@gmail.com>
>>
>> I dont know if it is the information you asked, but with cat
>>> /proc/interrupts, i got this:
>>>
>>> 21:         25          0          0          0        Phys-irq
>>>  uhci_hcd:usb3, uhci_hcd:usb5
>>>
>>> But now, I think that it is something related to CentOS kernel.
>>> I saw some posts related to my problem, and some people resolved
setting
>>> pciback.permissive option. But, seems like in CentOS we
can''t set it.
>>>
>>>
http://lists.xensource.com/archives/html/xen-users/2008-02/msg00247.html
>>> http://osdir.com/ml/centos/2009-11/msg00766.html
>>>
http://lists.centos.org/pipermail/centos-virt/2008-September/000632.html
>>>
>>> 2010/3/9 Pasi Kärkkäinen <pasik@iki.fi>
>>>
>>> On Tue, Mar 09, 2010 at 09:16:12AM -0300, Sergio Charpinel Jr.
wrote:
>>>> >    Tried to access webcam with another application (xawtv)
and got the
>>>> same
>>>> >    error.
>>>> >
>>>>
>>>> Ok. The irq-related pastes are very unreadable below..
>>>>
>>>> If you _don''t_ hide the USB controller from dom0, does
it share IRQ with
>>>> some other device?
>>>> Ie. do you see the same IRQ (that the usb controller has) also
for some
>>>> other device?
>>>>
>>>> -- Pasi
>>>>
>>>> >    2010/3/8 Sergio Charpinel Jr.
<[1]sergiocharpinel@gmail.com>
>>>> >
>>>> >      Pasi,
>>>> >      I dont know if I unbind the device correctly.
I''m using this
>>>> script:
>>>> >      modprobe pciback
>>>> >      BDF=0000:00:1d.3
>>>> >      # Unbind a PCI function from its driver as necessary
>>>> >      [ ! -e /sys/bus/pci/devices/$BDF/driver/unbind ] || \
>>>> >              echo -n $BDF >
/sys/bus/pci/devices/$BDF/driver/unbind
>>>> >      # Add a new slot to the PCI Backend''s list
>>>> >      echo -n $BDF >
/sys/bus/pci/drivers/pciback/new_slot
>>>> >      # Now that the backend is watching for the slot, bind
to it
>>>> >      echo -n $BDF > /sys/bus/pci/drivers/pciback/bind
>>>> >      And I got this in dmesg after running it:
>>>> >      uhci_hcd 0000:00:1d.3: remove, state 1
>>>> >      usb usb5: USB disconnect, address 1
>>>> >      usb 5-1: USB disconnect, address 2
>>>> >      drivers/media/video/stv680.c:
>>>> [usb_stv680_remove_disconnected:1451]
>>>> >      STV(i): STV0680 disconnected
>>>> >      uhci_hcd 0000:00:1d.3: USB bus 5 deregistered
>>>> >      ACPI: PCI interrupt for device 0000:00:1d.3 disabled
>>>> >      pciback 0000:00:1d.3: seizing device
>>>> >      PCI: Enabling device 0000:00:1d.3 (0000 -> 0001)
>>>> >      ACPI: PCI Interrupt 0000:00:1d.3[D] -> GSI 22
(level, low) -> IRQ
>>>> 21
>>>> >      ACPI: PCI interrupt for device 0000:00:1d.3 disabled
>>>> >      tap tap-1-51712: 2 getting info
>>>> >      pciback: vpci: 0000:00:1d.3: assign to virtual slot 0
>>>> >      ACPI: PCI interrupt for device 0000:00:1d.3 disabled
>>>> >      tap tap-2-51712: 2 getting info
>>>> >      pciback: vpci: 0000:00:1d.3: assign to virtual slot 0
>>>> >      device vif2.0 entered promiscuous mode
>>>> >      ADDRCONF(NETDEV_UP): vif2.0: link is not ready
>>>> >      PCI: Enabling device 0000:00:1d.3 (0000 -> 0001)
>>>> >      ACPI: PCI Interrupt 0000:00:1d.3[D] -> GSI 22
(level, low) -> IRQ
>>>> 21
>>>> >      ACPI: PCI Interrupt 0000:00:1d.3[D] -> GSI 22
(level, low) -> IRQ
>>>> 21
>>>> >      PCI: Setting latency timer of device 0000:00:1d.3 to
64
>>>> >      pciback 0000:00:1d.3: Driver tried to write to a
read-only
>>>> configuration
>>>> >      space field at offset 0xc0, size 2. This may be
harmless, but if
>>>> you
>>>> >      have problems with your device:
>>>> >      1) see permissive attribute in sysfs
>>>> >      2) report problems to the xen-devel mailing list
along with
>>>> details of
>>>> >      your device obtained from lspci.
>>>> >      blktap: ring-ref 9, event-channel 7, protocol 1
(x86_64-abi)
>>>> >      Also, here is the output of cat /proc/interrupts in
dom0:
>>>> >      cat /proc/interrupts
>>>> >                 CPU0              CPU1              CPU2
>>>>  CPU3
>>>> >
>>>> >       ..
>>>> >       20:         65          0          0          0     
Phys-irq
>>>> >       ehci_hcd:usb1, uhci_hcd:usb2, uhci_hcd:usb4
>>>> >       21:         26          0          0          0     
Phys-irq
>>>> >       uhci_hcd:usb3
>>>> >      245:     127288          0          0         26     
Phys-irq
>>>>  peth0
>>>> >      ...
>>>> >      and in domU:
>>>> >
>>>> >      cat /proc/interrupts
>>>> >                 CPU0
>>>> >       21:          0        Phys-irq  uhci_hcd:usb1
>>>> >      As you see, I got an warning message in dmesg.
>>>> >      Do you know what could be?
>>>> >      2010/3/8 Pasi Kärkkäinen <[2]pasik@iki.fi>
>>>> >
>>>> >        On Mon, Mar 08, 2010 at 11:28:41AM -0300, Sergio
Charpinel Jr.
>>>> wrote:
>>>> >        >    Not sure, how can I confirm?
>>>> >        >
>>>> >
>>>> >        Check /proc/interrupts and "lspci -vvv"
in dom0.
>>>> >        Also read dom0 "dmesg" output for the
devices in question.
>>>> >
>>>> >        -- Pasi
>>>> >
>>>> >        >    2010/3/8 Pasi Kärkkäinen
<[1][3]pasik@iki.fi>
>>>> >        >
>>>> >        >      On Mon, Mar 08, 2010 at 11:23:44AM -0300,
Sergio
>>>> Charpinel Jr.
>>>> >        wrote:
>>>> >        >      >    Thanks Pasi,
>>>> >        >      >    Tried with Xen from CentOS 5.4
repo, and got the
>>>> same
>>>> >        error.
>>>> >        >      >    Also with extra =
''swiotlb=force'' in DomU conf
>>>> file.
>>>> >        >      >    DomU boots, but when I start
zoneminder (a software
>>>> that
>>>> >        access the
>>>> >        >      >    webcam), the kernel panic occurs.
>>>> >        >      >    I will test another application.
>>>> >        >      >
>>>> >        >
>>>> >        >      Is the PCI device you passthrough using a
shared
>>>> interrupt
>>>> >        (IRQ)?
>>>> >        >      If yes, that can (and will) cause
problems.
>>>> >        >
>>>> >        >      -- Pasi
>>>> >        >
>>>> >        >      >    2010/3/5 Pasi Kärkkäinen
<[1][2][4]pasik@iki.fi>
>>>> >        >      >
>>>> >        >      >      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][2][3][5]Jan.Cescut@kgs.si>
>>>> >        >      >      >
>>>> >        >      >      >      Thanks for thorough
explanation.
>>>> >        >      >      >
>>>> >        >      >      >      Have a nice day,
>>>> >        >      >      >      Jan
>>>> >        >      >      >      -----Original
Message-----
>>>> >        >      >      >      From: Pasi
KÃ*rkkÃ*inen
>>>> >        [mailto:[2][3][4][6]pasik@iki.fi]
>>>> >        >      >      >      Sent: 27. februar
2010 14:04
>>>> >        >      >      >      To: Jan Ä*eÅ¡Ä*ut
>>>> >        >      >      >      Cc: [3][4][5][7]
>>>> xen-users@lists.xensource.com
>>>> >        >      >      >      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][5][6][8]Xen-users@lists.xensource.com
>>>> >        >      >      >      [5][6][7][9]
>>>> http://lists.xensource.com/xen-users
>>>> >        >      >      >
>>>> >        >      >      >    --
>>>> >        >      >      >    Sergio Roberto
Charpinel Jr.
>>>> >        >      >      >
>>>> >        >
>>>> >        >    --
>>>> >        >    Sergio Roberto Charpinel Jr.
>>>> >        >
>>>> >        > References
>>>> >        >
>>>> >        >    Visible links
>>>> >        >    1. mailto:[10]pasik@iki.fi
>>>> >        >    2. mailto:[11]pasik@iki.fi
>>>> >        >    3. mailto:[12]Jan.Cescut@kgs.si
>>>> >        >    4. mailto:[13]pasik@iki.fi
>>>> >        >    5. mailto:[14]xen-users@lists.xensource.com
>>>> >        >    6. mailto:[15]Xen-users@lists.xensource.com
>>>> >        >    7. [16]http://lists.xensource.com/xen-users
>>>> >
>>>> >      --
>>>> >      Sergio Roberto Charpinel Jr.
>>>> >
>>>> >    --
>>>> >    Sergio Roberto Charpinel Jr.
>>>> >
>>>> > References
>>>> >
>>>> >    Visible links
>>>> >    1. mailto:sergiocharpinel@gmail.com
>>>> >    2. mailto:pasik@iki.fi
>>>> >    3. mailto:pasik@iki.fi
>>>> >    4. mailto:pasik@iki.fi
>>>> >    5. mailto:Jan.Cescut@kgs.si
>>>> >    6. mailto:pasik@iki.fi
>>>> >    7. mailto:xen-users@lists.xensource.com
>>>> >    8. mailto:Xen-users@lists.xensource.com
>>>> >    9. http://lists.xensource.com/xen-users
>>>> >   10. mailto:pasik@iki.fi
>>>> >   11. mailto:pasik@iki.fi
>>>> >   12. mailto:Jan.Cescut@kgs.si
>>>> >   13. mailto:pasik@iki.fi
>>>> >   14. mailto:xen-users@lists.xensource.com
>>>> >   15. mailto:Xen-users@lists.xensource.com
>>>> >   16. http://lists.xensource.com/xen-users
>>>>
>>>
>>>
>>>
>>> --
>>> Sergio Roberto Charpinel Jr.
>>>
>>
>>
>>
>> --
>> Sergio Roberto Charpinel Jr.
>>
>
>
>
> --
> Sergio Roberto Charpinel Jr.
>


-- 
Sergio Roberto Charpinel Jr.


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

Paolo Rivetti

2010-Mar-21 20:19 UTC

head link

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

I can not assign the PCI card to the PV guest.
When I start the machine I get the error: non-page-aligned MMIO BAR  
found

I have the same configuration
I''m using CentOS 5.4 and Xen 3.4.2
I recompiled the kernel enabling PCI Backend inside the kernel (not as  
module) and PCI Backend Mode to Passthrogh.

This is my grub.conf configuration

title CentOS (2.6.18.8-xen-d2)
         root (hd0,0)
         kernel /xen.gz
         module /vmlinuz-2.6.18.8-xen-d2 ro root=/dev/vg0/lv0 rhgb  
quiet noreboot dom0_mem=1024M pciback.permissive  
pciback.hide=(0000:01:00.0)
	module /initrd-2.6.18.8-xen-d2.img

xm create -c /etc/xen/of0
Using config file "/etc/xen/of0".
Error: pci: 0000:01:00.0: non-page-aligned MMIO BAR found.

There are a lot of emails on the internet, but few solutions, some  
have no idea what it is?


On Mar 16, 2010, at 6:20 PM, Sergio Charpinel Jr. wrote:
> HI, Finally I it worked. I will post the results that I got, and  
> hope this helps someone.
>
> - I''m using CentOS 5.4 and it just worked after recompiling xen.hg
> kernel. I changed this options:
>  + PCI Backend inside kernel (not as module)
>  + PCI Backend mode to Passthrogh
>
> - Set pciback.permissive and pciback.hide in kernel boot config
>
> - Couldnt make it work with 2 pendrives and a webcam that can be  
> used as pendrive. With two others webcam (normal webcam), it worked.
>
> Bye
>
> 2010/3/15 Sergio Charpinel Jr. <sergiocharpinel@gmail.com>
> No sorry,
> Just worked with a different cam. Testing with the other one results  
> in the same error. It is assigned to another device.
>
> Maybe is a shared interruption problem, like Pasi said.
>
>
> 2010/3/15 Sergio Charpinel Jr. <sergiocharpinel@gmail.com>
>
> Hi,
>
> After recompiling linux-2.18.6-xen.hg and changing XEN -> PCI  
> backend Mode from Virtual PCI to Passthrough and resolving some  
> dependences (blk as module, enable SATA_PIIX) , it worked.
>
> Dont know if those options are necessary.
>
> Thanks for the attention, and hope this helps someone.
>
>
> 2010/3/9 Sergio Charpinel Jr. <sergiocharpinel@gmail.com>
>
> I dont know if it is the information you asked, but with cat /proc/ 
> interrupts, i got this:
>
> 21:         25          0          0          0        Phys-irq   
> uhci_hcd:usb3, uhci_hcd:usb5
>
> But now, I think that it is something related to CentOS kernel.
> I saw some posts related to my problem, and some people resolved  
> setting pciback.permissive option. But, seems like in CentOS we  
> can''t set it.
>
> http://lists.xensource.com/archives/html/xen-users/2008-02/msg00247.html
> http://osdir.com/ml/centos/2009-11/msg00766.html
> http://lists.centos.org/pipermail/centos-virt/2008-September/000632.html
>
> 2010/3/9 Pasi Kärkkäinen <pasik@iki.fi>
>
> On Tue, Mar 09, 2010 at 09:16:12AM -0300, Sergio Charpinel Jr. wrote:
> >    Tried to access webcam with another application (xawtv) and got  
> the same
> >    error.
> >
>
> Ok. The irq-related pastes are very unreadable below..
>
> If you _don''t_ hide the USB controller from dom0, does it share
IRQ
> with some other device?
> Ie. do you see the same IRQ (that the usb controller has) also for  
> some other device?
>
> -- Pasi
>
> >    2010/3/8 Sergio Charpinel Jr. <[1]sergiocharpinel@gmail.com>
> >
> >      Pasi,
> >      I dont know if I unbind the device correctly. I''m using
this
> script:
> >      modprobe pciback
> >      BDF=0000:00:1d.3
> >      # Unbind a PCI function from its driver as necessary
> >      [ ! -e /sys/bus/pci/devices/$BDF/driver/unbind ] || \
> >              echo -n $BDF > /sys/bus/pci/devices/$BDF/driver/unbind
> >      # Add a new slot to the PCI Backend''s list
> >      echo -n $BDF > /sys/bus/pci/drivers/pciback/new_slot
> >      # Now that the backend is watching for the slot, bind to it
> >      echo -n $BDF > /sys/bus/pci/drivers/pciback/bind
> >      And I got this in dmesg after running it:
> >      uhci_hcd 0000:00:1d.3: remove, state 1
> >      usb usb5: USB disconnect, address 1
> >      usb 5-1: USB disconnect, address 2
> >      drivers/media/video/stv680.c: [usb_stv680_remove_disconnected: 
> 1451]
> >      STV(i): STV0680 disconnected
> >      uhci_hcd 0000:00:1d.3: USB bus 5 deregistered
> >      ACPI: PCI interrupt for device 0000:00:1d.3 disabled
> >      pciback 0000:00:1d.3: seizing device
> >      PCI: Enabling device 0000:00:1d.3 (0000 -> 0001)
> >      ACPI: PCI Interrupt 0000:00:1d.3[D] -> GSI 22 (level, low)
->
> IRQ 21
> >      ACPI: PCI interrupt for device 0000:00:1d.3 disabled
> >      tap tap-1-51712: 2 getting info
> >      pciback: vpci: 0000:00:1d.3: assign to virtual slot 0
> >      ACPI: PCI interrupt for device 0000:00:1d.3 disabled
> >      tap tap-2-51712: 2 getting info
> >      pciback: vpci: 0000:00:1d.3: assign to virtual slot 0
> >      device vif2.0 entered promiscuous mode
> >      ADDRCONF(NETDEV_UP): vif2.0: link is not ready
> >      PCI: Enabling device 0000:00:1d.3 (0000 -> 0001)
> >      ACPI: PCI Interrupt 0000:00:1d.3[D] -> GSI 22 (level, low)
->
> IRQ 21
> >      ACPI: PCI Interrupt 0000:00:1d.3[D] -> GSI 22 (level, low)
->
> IRQ 21
> >      PCI: Setting latency timer of device 0000:00:1d.3 to 64
> >      pciback 0000:00:1d.3: Driver tried to write to a read-only  
> configuration
> >      space field at offset 0xc0, size 2. This may be harmless, but  
> if you
> >      have problems with your device:
> >      1) see permissive attribute in sysfs
> >      2) report problems to the xen-devel mailing list along with  
> details of
> >      your device obtained from lspci.
> >      blktap: ring-ref 9, event-channel 7, protocol 1 (x86_64-abi)
> >      Also, here is the output of cat /proc/interrupts in dom0:
> >      cat /proc/interrupts
> >                 CPU0              CPU1               
> CPU2              CPU3
> >
> >       ..
> >       20:         65          0          0          0        Phys- 
> irq
> >       ehci_hcd:usb1, uhci_hcd:usb2, uhci_hcd:usb4
> >       21:         26          0          0          0        Phys- 
> irq
> >       uhci_hcd:usb3
> >      245:     127288          0          0         26        Phys- 
> irq  peth0
> >      ...
> >      and in domU:
> >
> >      cat /proc/interrupts
> >                 CPU0
> >       21:          0        Phys-irq  uhci_hcd:usb1
> >      As you see, I got an warning message in dmesg.
> >      Do you know what could be?
> >      2010/3/8 Pasi Kärkkäinen <[2]pasik@iki.fi>
> >
> >        On Mon, Mar 08, 2010 at 11:28:41AM -0300, Sergio Charpinel  
> Jr. wrote:
> >        >    Not sure, how can I confirm?
> >        >
> >
> >        Check /proc/interrupts and "lspci -vvv" in dom0.
> >        Also read dom0 "dmesg" output for the devices in
question.
> >
> >        -- Pasi
> >
> >        >    2010/3/8 Pasi Kärkkäinen <[1][3]pasik@iki.fi>
> >        >
> >        >      On Mon, Mar 08, 2010 at 11:23:44AM -0300, Sergio  
> Charpinel Jr.
> >        wrote:
> >        >      >    Thanks Pasi,
> >        >      >    Tried with Xen from CentOS 5.4 repo, and got
> the same
> >        error.
> >        >      >    Also with extra =
''swiotlb=force'' in DomU conf
> file.
> >        >      >    DomU boots, but when I start zoneminder (a  
> software that
> >        access the
> >        >      >    webcam), the kernel panic occurs.
> >        >      >    I will test another application.
> >        >      >
> >        >
> >        >      Is the PCI device you passthrough using a shared  
> interrupt
> >        (IRQ)?
> >        >      If yes, that can (and will) cause problems.
> >        >
> >        >      -- Pasi
> >        >
> >        >      >    2010/3/5 Pasi Kärkkäinen
<[1][2][4]pasik@iki.fi>
> >        >      >
> >        >      >      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][2][3][5]Jan.Cescut@kgs.si>
> >        >      >      >
> >        >      >      >      Thanks for thorough explanation.
> >        >      >      >
> >        >      >      >      Have a nice day,
> >        >      >      >      Jan
> >        >      >      >      -----Original Message-----
> >        >      >      >      From: Pasi KÃ*rkkÃ*inen
> >        [mailto:[2][3][4][6]pasik@iki.fi]
> >        >      >      >      Sent: 27. februar 2010 14:04
> >        >      >      >      To: Jan Ä*eÅ¡Ä*ut
> >        >      >      >      Cc:
[3][4][5][7]xen-users@lists.xensource.com
> >        >      >      >      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][5][6][8]Xen- 
> users@lists.xensource.com
> >        >      >      >     
[5][6][7][9]http://lists.xensource.com/xen-users
> >        >      >      >
> >        >      >      >    --
> >        >      >      >    Sergio Roberto Charpinel Jr.
> >        >      >      >
> >        >
> >        >    --
> >        >    Sergio Roberto Charpinel Jr.
> >        >
> >        > References
> >        >
> >        >    Visible links
> >        >    1. mailto:[10]pasik@iki.fi
> >        >    2. mailto:[11]pasik@iki.fi
> >        >    3. mailto:[12]Jan.Cescut@kgs.si
> >        >    4. mailto:[13]pasik@iki.fi
> >        >    5. mailto:[14]xen-users@lists.xensource.com
> >        >    6. mailto:[15]Xen-users@lists.xensource.com
> >        >    7. [16]http://lists.xensource.com/xen-users
> >
> >      --
> >      Sergio Roberto Charpinel Jr.
> >
> >    --
> >    Sergio Roberto Charpinel Jr.
> >
> > References
> >
> >    Visible links
> >    1. mailto:sergiocharpinel@gmail.com
> >    2. mailto:pasik@iki.fi
> >    3. mailto:pasik@iki.fi
> >    4. mailto:pasik@iki.fi
> >    5. mailto:Jan.Cescut@kgs.si
> >    6. mailto:pasik@iki.fi
> >    7. mailto:xen-users@lists.xensource.com
> >    8. mailto:Xen-users@lists.xensource.com
> >    9. http://lists.xensource.com/xen-users
> >   10. mailto:pasik@iki.fi
> >   11. mailto:pasik@iki.fi
> >   12. mailto:Jan.Cescut@kgs.si
> >   13. mailto:pasik@iki.fi
> >   14. mailto:xen-users@lists.xensource.com
> >   15. mailto:Xen-users@lists.xensource.com
> >   16. http://lists.xensource.com/xen-users
>
>
>
> -- 
> Sergio Roberto Charpinel Jr.
>
>
>
> -- 
> Sergio Roberto Charpinel Jr.
>
>
>
> -- 
> Sergio Roberto Charpinel Jr.
>
>
>
> -- 
> Sergio Roberto Charpinel Jr.
> _______________________________________________
> Xen-users mailing list
> Xen-users@lists.xensource.com
> http://lists.xensource.com/xen-users


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

Pasi Kärkkäinen

2010-Mar-21 20:56 UTC

head link

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

On Sun, Mar 21, 2010 at 09:19:44PM +0100, Paolo Rivetti
wrote:>    I can not assign the PCI card to the PV guest.
>    When I start the machine I get the error: non-page-aligned MMIO BAR
found
>    I have the same configuration
>    I''m using CentOS 5.4 and Xen 3.4.2
>    I recompiled the kernel enabling PCI Backend inside the kernel (not as
>    module) and PCI Backend Mode to Passthrogh.
>    This is my grub.conf configuration
>    title CentOS (2.6.18.8-xen-d2)
>            root (hd0,0)
>            kernel /xen.gz
>            module /vmlinuz-2.6.18.8-xen-d2 ro root=/dev/vg0/lv0 rhgb quiet
>    noreboot dom0_mem=1024M pciback.permissive pciback.hide=(0000:01:00.0)
>            module /initrd-2.6.18.8-xen-d2.img
>    xm create -c /etc/xen/of0
>    Using config file "/etc/xen/of0".
>    Error: pci: 0000:01:00.0: non-page-aligned MMIO BAR found.
>    There are a lot of emails on the internet, but few solutions, some have
no
>    idea what it is?
Did you try the reassigndev= option? 

That should fix the "non-page-aligned MMIO BAR found" issue.

-- Pasi



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

Paolo Rivetti

2010-Mar-21 22:56 UTC

head link

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

Thanks Pasi, now works. I used ''guestdev ='' which replaced  
''reassigndev =''
(http://xenbits.xensource.com/linux-2.6.18-xen.hg?rev/a3ad7a5f2dcd)
My final configuration now is:
title CentOS (2.6.18.8-xen-d2)
         root (hd0,0)
         kernel /xen.gz
         module /vmlinuz-2.6.18.8-xen-d2 ro root=/dev/vg0/lv0 rhgb  
quiet noreboot dom0_mem=1024M pciback.permissive  
pciback.hide=(01:00.0) guestdev=01:00.0 reassign_resources
         module /initrd-2.6.18.8-xen-d2.img

It was a great effort, but eventually it works. Xen offers a lot of  
functionality but is very complex!

On Mar 21, 2010, at 9:56 PM, Pasi Kärkkäinen wrote:
> On Sun, Mar 21, 2010 at 09:19:44PM +0100, Paolo Rivetti wrote:
>>   I can not assign the PCI card to the PV guest.
>>   When I start the machine I get the error: non-page-aligned MMIO  
>> BAR found
>>   I have the same configuration
>>   I''m using CentOS 5.4 and Xen 3.4.2
>>   I recompiled the kernel enabling PCI Backend inside the kernel  
>> (not as
>>   module) and PCI Backend Mode to Passthrogh.
>>   This is my grub.conf configuration
>>   title CentOS (2.6.18.8-xen-d2)
>>           root (hd0,0)
>>           kernel /xen.gz
>>           module /vmlinuz-2.6.18.8-xen-d2 ro root=/dev/vg0/lv0 rhgb  
>> quiet
>>   noreboot dom0_mem=1024M pciback.permissive  
>> pciback.hide=(0000:01:00.0)
>>           module /initrd-2.6.18.8-xen-d2.img
>>   xm create -c /etc/xen/of0
>>   Using config file "/etc/xen/of0".
>>   Error: pci: 0000:01:00.0: non-page-aligned MMIO BAR found.
>>   There are a lot of emails on the internet, but few solutions,  
>> some have no
>>   idea what it is?
>
> Did you try the reassigndev= option?
>
> That should fix the "non-page-aligned MMIO BAR found" issue.
>
> -- Pasi
>
>


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

Pasi Kärkkäinen

2010-Mar-22 08:57 UTC

head link

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

On Sun, Mar 21, 2010 at 11:56:54PM +0100, Paolo Rivetti
wrote:>    Thanks Pasi, now works. I used ''guestdev ='' which
replaced ''reassigndev =''
>    ([1]http://xenbits.xensource.com/linux-2.6.18-xen.hg?rev/a3ad7a5f2dcd)
>    My final configuration now is:
>    title CentOS (2.6.18.8-xen-d2)
>            root (hd0,0)
>            kernel /xen.gz
>            module /vmlinuz-2.6.18.8-xen-d2 ro root=/dev/vg0/lv0 rhgb quiet
>    noreboot dom0_mem=1024M pciback.permissive pciback.hide=(01:00.0)
>    guestdev=01:00.0 reassign_resources
>            module /initrd-2.6.18.8-xen-d2.img
>    It was a great effort, but eventually it works. Xen offers a lot of
>    functionality but is very complex!
Good to hear it works!

ps. I''m working on adding these things to a wiki page, for easier usage
in the future :)

-- Pasi
>    On Mar 21, 2010, at 9:56 PM, Pasi Kärkkäinen wrote:
> 
>      On Sun, Mar 21, 2010 at 09:19:44PM +0100, Paolo Rivetti wrote:
> 
>          I can not assign the PCI card to the PV guest.
> 
>          When I start the machine I get the error: non-page-aligned MMIO
BAR
>        found
> 
>          I have the same configuration
> 
>          I''m using CentOS 5.4 and Xen 3.4.2
> 
>          I recompiled the kernel enabling PCI Backend inside the kernel
(not
>        as
> 
>          module) and PCI Backend Mode to Passthrogh.
> 
>          This is my grub.conf configuration
> 
>          title CentOS (2.6.18.8-xen-d2)
> 
>                  root (hd0,0)
> 
>                  kernel /xen.gz
> 
>                  module /vmlinuz-2.6.18.8-xen-d2 ro root=/dev/vg0/lv0 rhgb
>        quiet
> 
>          noreboot dom0_mem=1024M pciback.permissive
>        pciback.hide=(0000:01:00.0)
> 
>                  module /initrd-2.6.18.8-xen-d2.img
> 
>          xm create -c /etc/xen/of0
> 
>          Using config file "/etc/xen/of0".
> 
>          Error: pci: 0000:01:00.0: non-page-aligned MMIO BAR found.
> 
>          There are a lot of emails on the internet, but few solutions, some
>        have no
> 
>          idea what it is?
> 
>      Did you try the reassigndev= option?
> 
>      That should fix the "non-page-aligned MMIO BAR found" issue.
> 
>      -- Pasi
> 
> References
> 
>    Visible links
>    1. http://xenbits.xensource.com/linux-2.6.18-xen.hg?rev/a3ad7a5f2dcd
_______________________________________________
Xen-users mailing list
Xen-users@lists.xensource.com
http://lists.xensource.com/xen-users

Xen users - Feb 2010 - PCI Passthrough without VT-d

[Xen-users] PCI Passthrough without VT-d

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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