Direct Ethernet Connection Bug (3.0.4-1)

Direct Ethernet Connection Bug (3.0.4-1)

[Timo Benk]

Hello,

i am trying to configure a direct ethernet connection between two Domain-Us:

If i start the Domain with the frontend-Device-Driver, i get the following
log message inside the domain hosting the backend-device-driver:

Feb  2 12:53:04 xendom1 kernel: ------------[ cut here ]------------
Feb  2 12:53:04 xendom1 kernel: kernel BUG at drivers/xen/netback/interface.c:205!
Feb  2 12:53:04 xendom1 kernel: invalid opcode: 0000 [#1]
Feb  2 12:53:04 xendom1 kernel: SMP
Feb  2 12:53:04 xendom1 kernel: Modules linked in: netbk xenbus_be ipv6 dm_mod
Feb  2 12:53:04 xendom1 kernel: CPU:    0
Feb  2 12:53:04 xendom1 kernel: EIP:    0061:[<e1117832>]    Tainted: GF     VLI
Feb  2 12:53:04 xendom1 kernel: EFLAGS: 00210286   (2.6.16.38-xenU #1)
Feb  2 12:53:04 xendom1 kernel: EIP is at netif_map+0x292/0x2e0 [netbk]
Feb  2 12:53:04 xendom1 kernel: eax: c0647ee0   ebx: 00000000   ecx: ffffffff   edx: 00000001
Feb  2 12:53:04 xendom1 kernel: esi: 0000020a   edi: 0000020b   ebp: cca49b80   esp: cfdade7c
Feb  2 12:53:04 xendom1 kernel: ds: 007b   es: 007b   ss: 0069
Feb  2 12:53:04 xendom1 kernel: Process xenwatch (pid: 8, threadinfo=cfdac000 task=c095a570)
Feb  2 12:53:04 xendom1 kernel: Stack: <0>fffffffe c032dbe8 cf8147c0 00000002 ffffffff 00000000 00000000 cfdade9c
Feb  2 12:53:04 xendom1 kernel:        e10f6000 00000000 00000002 0000020a c0250008 00000001 00000000 cf8147c0
Feb  2 12:53:04 xendom1 kernel:        cf8147c0 fffffffe 00000000 00000001 c0258db3 00000000 c1602400 cf864940
Feb  2 12:53:04 xendom1 kernel: Call Trace:
Feb  2 12:53:04 xendom1 kernel:  [<c0250008>] redo_format+0xe8/0x230
Feb  2 12:53:04 xendom1 kernel:  [<c0258db3>] xenbus_read+0x43/0x60
Feb  2 12:53:04 xendom1 kernel:  [<c02591ad>] xenbus_scanf+0x1d/0x60
Feb  2 12:53:04 xendom1 kernel:  [<e1116a5c>] frontend_changed+0x23c/0x670 [netbk]
Feb  2 12:53:04 xendom1 kernel:  [<c025a548>] otherend_changed+0xa8/0xb0
Feb  2 12:53:04 xendom1 kernel:  [<c0259290>] xenwatch_thread+0x0/0x180
Feb  2 12:53:04 xendom1 kernel:  [<c02587d2>] xenwatch_handle_callback+0x12/0x50
Feb  2 12:53:04 xendom1 kernel:  [<c02593f6>] xenwatch_thread+0x166/0x180
Feb  2 12:53:04 xendom1 kernel:  [<c02587c0>] xenwatch_handle_callback+0x0/0x50
Feb  2 12:53:04 xendom1 kernel:  [<c0130810>] autoremove_wake_function+0x0/0x50
Feb  2 12:53:04 xendom1 kernel:  [<c013058b>] kthread+0xab/0xe0
Feb  2 12:53:04 xendom1 kernel:  [<c01304e0>] kthread+0x0/0xe0
Feb  2 12:53:04 xendom1 kernel:  [<c0102b45>] kernel_thread_helper+0x5/0x10
Feb  2 12:53:04 xendom1 kernel: Code: 95 fb ff ff e8 50 33 18 df e9 ad fd ff ff 89 e8 e8 b4 f8 ff ff 8d 74 26 00 e9 dc fe ff ff 0f 0b dd 00 48 7d 11 e1 e9 c2 fe ff ff <0f> 0b cd 00 48 7d 11 e1 e9 31 fe ff ff 8d 44 24 44 b9 06 00 00

Greetings,
-timo
-- 
Timo Benk - Jabber ID: fry@downtempo.de - ICQ ID: #414944731
PGP Public Key: http://m28s01.vlinux.de/timo_benk_gpg_key.asc

Re: Direct Ethernet Connection Bug (3.0.4-1)

[Keir Fraser]

On 2/2/07 11:53, "Timo Benk" <timo.benk@gmx.de> wrote:

> If i start the Domain with the frontend-Device-Driver, i get the following
> log message inside the domain hosting the backend-device-driver:

Ability to map other guests' memory via grant tables is restricted to
domains that have some privilege to access I/o memory. This is because of
some unmap races in current grant-table code, allowing mapping domain to
theoretically use a stale mapping in its TLB for a very short time after
unmapping the foreign page.

So, this crash indicates that you have not given any I/O-memory access
privilege to the backend domain. Have you actually given it access to the
Ethernet PCI device and its I/O memory and I/O port resources?

 -- Keir

Re: Direct Ethernet Connection Bug (3.0.4-1)

[Timo Benk]

Keir Fraser wrote:
> On 2/2/07 11:53, "Timo Benk" <timo.benk@gmx.de> wrote:
> 
>> If i start the Domain with the frontend-Device-Driver, i get the following
>> log message inside the domain hosting the backend-device-driver:
> 
> Ability to map other guests' memory via grant tables is restricted to
> domains that have some privilege to access I/o memory. This is because of
> some unmap races in current grant-table code, allowing mapping domain to
> theoretically use a stale mapping in its TLB for a very short time after
> unmapping the foreign page.
> 
> So, this crash indicates that you have not given any I/O-memory access
> privilege to the backend domain. Have you actually given it access to the
> Ethernet PCI device and its I/O memory and I/O port resources?

Hm, you are right, i have not given any domains any other privileges then
the default setup. Can you give me a hint where i can configure that?

For the PCI-Device: I do not have a PCI device.

I want a whole virtual, direct connection between two Domain-Us. That worked
at least in 3.0.2 for me, without setting any permissions.

 ---------    ---------
| xendom1 |  | xendom2 |
| eth0----|--|--vif3.0 |
 ---------    ---------

Greetings,
-timo

-- 
Timo Benk - Jabber ID: fry@downtempo.de - ICQ ID: #414944731
PGP Public Key: http://m28s01.vlinux.de/timo_benk_gpg_key.asc

Re: Direct Ethernet Connection Bug (3.0.4-1)

[Keir Fraser]

On 2/2/07 15:28, "Timo Benk" <timo.benk@gmx.de> wrote:

>> So, this crash indicates that you have not given any I/O-memory access
>> privilege to the backend domain. Have you actually given it access to the
>> Ethernet PCI device and its I/O memory and I/O port resources?
> 
> Hm, you are right, i have not given any domains any other privileges then
> the default setup. Can you give me a hint where i can configure that?

Ah, but I see actually you don't want a physical device backing up this
network -- you just want point-to-point virtual network comms between the
two domUs?

The only way to grant any iomem to a domU in current tools is by assigning
access to a PCI device.

What I can do is add a Xen boot parameter 'permissive_grant' to allow any
domU to map foreign pages via grant tables. This boot parameter can then be
removed when we fix the TLB-flushing races in the grant table code.

Are you running from xen-unstable, or a different codebase?

 -- Keir

Re: Direct Ethernet Connection Bug (3.0.4-1)

[Timo Benk]

Keir Fraser wrote:
> On 2/2/07 15:28, "Timo Benk" <timo.benk@gmx.de> wrote:
> 
>>> So, this crash indicates that you have not given any I/O-memory access
>>> privilege to the backend domain. Have you actually given it access to the
>>> Ethernet PCI device and its I/O memory and I/O port resources?
>> Hm, you are right, i have not given any domains any other privileges then
>> the default setup. Can you give me a hint where i can configure that?
> 
> Ah, but I see actually you don't want a physical device backing up this
> network -- you just want point-to-point virtual network comms between the
> two domUs?
Yes.

> The only way to grant any iomem to a domU in current tools is by assigning
> access to a PCI device.
> 
> What I can do is add a Xen boot parameter 'permissive_grant' to allow any
> domU to map foreign pages via grant tables. This boot parameter can then be
> removed when we fix the TLB-flushing races in the grant table code.
That sounds good so far.

> Are you running from xen-unstable, or a different codebase?
xen-testing 3.0.4-1

Greetings,
-timo

-- 
Timo Benk - Jabber ID: fry@downtempo.de - ICQ ID: #414944731
PGP Public Key: http://m28s01.vlinux.de/timo_benk_gpg_key.asc

Re: Direct Ethernet Connection Bug (3.0.4-1)

[Mark Williamson]

On Friday 02 February 2007 15:47, Keir Fraser wrote:
> On 2/2/07 15:28, "Timo Benk" <timo.benk@gmx.de> wrote:
> >> So, this crash indicates that you have not given any I/O-memory access
> >> privilege to the backend domain. Have you actually given it access to
> >> the Ethernet PCI device and its I/O memory and I/O port resources?
> >
> > Hm, you are right, i have not given any domains any other privileges then
> > the default setup. Can you give me a hint where i can configure that?
>
> Ah, but I see actually you don't want a physical device backing up this
> network -- you just want point-to-point virtual network comms between the
> two domUs?
>
> The only way to grant any iomem to a domU in current tools is by assigning
> access to a PCI device.

I guess an interim hack which you might get away with (!?) is to pass the domU 
a PCI device which you make sure it *doesn't* have a driver for, so it won't 
actually try to use it.

I think this has been used to elevate privileges on Xen before in this kind of 
situation - very hacky, though!

Cheers,
Mark

> What I can do is add a Xen boot parameter 'permissive_grant' to allow any
> domU to map foreign pages via grant tables. This boot parameter can then be
> removed when we fix the TLB-flushing races in the grant table code.
>
> Are you running from xen-unstable, or a different codebase?
>
>  -- Keir
>
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

-- 
Dave: Just a question. What use is a unicyle with no seat?  And no pedals!
Mark: To answer a question with a question: What use is a skateboard?
Dave: Skateboards have wheels.
Mark: My wheel has a wheel!