Mailing List Archive

Direct Ethernet Connection Bug (3.0.4-1)
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


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
Re: Direct Ethernet Connection Bug (3.0.4-1) [ In reply to ]
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



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
Re: Direct Ethernet Connection Bug (3.0.4-1) [ In reply to ]
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


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
Re: Direct Ethernet Connection Bug (3.0.4-1) [ In reply to ]
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



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
Re: Direct Ethernet Connection Bug (3.0.4-1) [ In reply to ]
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


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
Re: Direct Ethernet Connection Bug (3.0.4-1) [ In reply to ]
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!

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