xen-netback notify DomU to send ARP.

xen-netback notify DomU to send ARP.

[jianhai luan]

[-- Attachment #1: Type: text/plain, Size: 747 bytes --]

Hi,
   When Xen Dom0's network circumstance changed, DomU
should be notified in some special condition. For
example the below circumstance:
   ping from Guest A to DomU:
   Guest A --> eth0 - bond0 - xenbr0 --VIF(DOMU)
               eth1 /
   when eth0 inactive, and eth1 active.
   Guest A --> eth0   bond0 - xenbr0 --VIF(DOMU)
               eth1 /
   Guest A will don't reach to DomU. After Guest A
   send ARP request and DomU respond, Guest A will
   reach DomU. But some more second will be elapsed.
               eth0   bond0 - xenbr0 --VIF(DOMU)
   Guest A --> eth1/

If Xen netback watch the network change, will notify
DomU by change it own status. So netfront will watch
netback's change, and DomU send ARP initiative.

Thanks,
Jason

[-- Attachment #2: .0001-xen-netback-notify-DomU-to-send-ARP.patch.swp --]
[-- Type: application/octet-stream, Size: 12288 bytes --]

Re: xen-netback notify DomU to send ARP.

[jianhai luan]

[-- Attachment #1.1: Type: text/plain, Size: 2657 bytes --]


On 2013-1-8 21:42, Ian Campbell wrote:
> On Tue, 2013-01-08 at 13:13 +0000, Jan Beulich wrote:
>>>>> On 08.01.13 at 12:57, jianhai luan <jianhai.luan@oracle.com> wrote:
>>>     When Xen Dom0's network circumstance changed, DomU
>>> should be notified in some special condition. For
>>> example the below circumstance:
>>>     ping from Guest A to DomU:
>>>     Guest A --> eth0 - bond0 - xenbr0 --VIF(DOMU)
>>>                 eth1 /
>>>     when eth0 inactive, and eth1 active.
> How is eth0 failing? Are you unplugging it, un-enslaving it or taking
> some other sort of administrative action?
In my emulation environment, i unplug it or ifdown the interface, while 
eth0 maybe wrong in productive environment.
>
> Which bonding mode are you using?
Bond running in active-backup mode.
>
> Doesn't this state change cause the switch to which eth0 and eth1 are
> attached to forget the MAC tables associated with the eth0 port, meaning
> that subsequent traffic will be flooded until it learns that eth1 is the
> new port?
>
>>>     Guest A --> eth0   bond0 - xenbr0 --VIF(DOMU)
>>>                 eth1 /
>>>     Guest A will don't reach to DomU. After Guest A
>>>     send ARP request and DomU respond, Guest A will
>>>     reach DomU. But some more second will be elapsed.
>>>                 eth0   bond0 - xenbr0 --VIF(DOMU)
>>>     Guest A --> eth1/
>> Isn't a change to the availability of the bonds supposed to be
>> transparent to Guest A _and_ DomU? I.e. aren't you trying to fix
>> an eventual problem here in the wrong place?
> In non-virtualised bonding the bonding drive can take care of some of
> this because it knows its own MAC address and can send appropriate
> gratuitous frames (depends on the bonding mode) to paper over things. In
> the virtualised case it (most likely) doesn't know VIF(DOMU)s MAC
> address.
   If you have know all ip and mac before modprobe bond, you can 
configure the bond argument. But you don't know all ip and mac before 
start new virtual.
   If bond want to know all DomU's ip and mac which pass through, it 
must check all skb. it's not good idea.
>
>>> If Xen netback watch the network change, will notify
>>> DomU by change it own status. So netfront will watch
>>> netback's change, and DomU send ARP initiative.
>> Your patch is, at least according to what I see, completely
>> unusable - line breaks dropped, line order reversed, and
>> (guessing) some UTF-16/UCS-2 characters inserted at the top.
>> Please attach patches as plain ASCII.
>  From the name it looks to me like it is the vi temp file created while
> you have the file open rather than the actual patch file...
>
> Ian.
>
Thanks,
Jason


[-- Attachment #1.2: Type: text/html, Size: 5439 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

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

Re: xen-netback notify DomU to send ARP.

[Jason Luan]

于 2013年01月09日 00:00, Ian Campbell 写道:
> On Tue, 2013-01-08 at 15:40 +0000, jianhai luan wrote:
>> On 2013-1-8 21:42, Ian Campbell wrote:
>>> On Tue, 2013-01-08 at 13:13 +0000, Jan Beulich wrote:
>>>>>>> On 08.01.13 at 12:57, jianhai luan <jianhai.luan@oracle.com>
>>>>>>> wrote:
>>>>>      When Xen Dom0's network circumstance changed, DomU
>>>>> should be notified in some special condition. For
>>>>> example the below circumstance:
>>>>>      ping from Guest A to DomU:
>>>>>      Guest A --> eth0 - bond0 - xenbr0 --VIF(DOMU)
>>>>>                  eth1 /
>>>>>      when eth0 inactive, and eth1 active.
>>> How is eth0 failing? Are you unplugging it, un-enslaving it or
>>> taking
>>> some other sort of administrative action?
>> In my emulation environment, i unplug it or ifdown the interface,
> I expect these would behave rather different, since the affect of ifdown
> looks rather different to an unplug from the PoV of the switch.
>
> Is the ifdown case something which you are trying to solve or just what
> appeared to be a convenient test case? I'd be less inclined to worry
> about explict admin actions such as that.
>
> Unplugging the cable should cause:
>
I do above listed thing to let switch active slave only.
I think that we should put attention on the thing which bond switch 
active slave interface in active-backup mode. In network circumstance, 
many thing will cause the switch, what do Vif when the event happen?
>>> Doesn't this state change cause the switch to which eth0 and eth1
>>> are
>>> attached to forget the MAC tables associated with the eth0 port,
>>> meaning
>>> that subsequent traffic will be flooded until it learns that eth1 is
>>> the
>>> new port?
> Ian
>
>
>
> _______________________________________________
> Xen-devel mailing list
Thanks,
Jason
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel



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

Re: xen-netback notify DomU to send ARP.

[Jason Luan]

[-- Attachment #1.1: Type: text/plain, Size: 2907 bytes --]

于 2013年01月09日 20:03, Ian Campbell 写道:
> On Wed, 2013-01-09 at 01:07 +0000, Jason Luan wrote:
>> 于 2013年01月09日 00:00, Ian Campbell 写道:
>>> On Tue, 2013-01-08 at 15:40 +0000, jianhai luan wrote:
>>>> On 2013-1-8 21:42, Ian Campbell wrote:
>>>>> On Tue, 2013-01-08 at 13:13 +0000, Jan Beulich wrote:
>>>>>>>>> On 08.01.13 at 12:57, jianhai luan <jianhai.luan@oracle.com>
>>>>>>>>> wrote:
>>>>>>> When Xen Dom0's network circumstance changed, DomU
>>>>>>> should be notified in some special condition. For
>>>>>>> example the below circumstance:
>>>>>>> ping from Guest A to DomU:
>>>>>>> Guest A --> eth0 - bond0 - xenbr0 --VIF(DOMU)
>>>>>>> eth1 /
>>>>>>> when eth0 inactive, and eth1 active.
>>>>> How is eth0 failing? Are you unplugging it, un-enslaving it or
>>>>> taking
>>>>> some other sort of administrative action?
>>>> In my emulation environment, i unplug it or ifdown the interface,
>>> I expect these would behave rather different, since the affect of
>>> ifdown
>>> looks rather different to an unplug from the PoV of the switch.
>>>
>>> Is the ifdown case something which you are trying to solve or just what
>>> appeared to be a convenient test case? I'd be less inclined to worry
>>> about explict admin actions such as that.
>>>
>>> Unplugging the cable should cause:
>>>
>> I do above listed thing to let switch active slave only.
>> I think that we should put attention on the thing which bond switch
>> active slave interface in active-backup mode. In network circumstance,
>> many thing will cause the switch, what do Vif when the event happen?
> Sorry, I'm having a bit of trouble parsing the above, but are you asking
> what the VIF should do when the active slave in the bond changes without
> the previously active slave actually failing?
sorry for your misunderstanding.
>
> The issue is that traffic will continue to arrive on the now inactive
> slave, but will be discarded (the expected behaviour for
> Active/Passive)?
Yes. the traffic will continue to arrive on the switcher's port which
connected the inactive
slave before, and the switcher's port don't connect (or don't reach) the
inactive slave now,
so the link will be disconnected before DomU send ARP. After DomU send
ARP, the traffic will
know how to reach the correct switcher's port which connected with the
active slave.
>
> Is this something which happens in practice? Does the active slave
> change even while it remains a viable path?
Yes, please think the below the scene.
PC -- switcher
port A -- eth0 --bond0 --xenbr0 -DomU
port B -- eth1/
or
PC -- switcher A -- eth0 -- bond0 -- xenbr0 -- DomU
\- switcher B -- eth1 /

If Port A or switcher A wrong, the traffic from PC to DomU will be
disconnected before found
correct path (port B or Switcher B ).
>
> Ian.
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel


[-- Attachment #1.2: Type: text/html, Size: 6594 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

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

Re: xen-netback notify DomU to send ARP.

[Jason Luan]

于 2013年01月09日 21:44, Jan Beulich 写道:
>>>> On 09.01.13 at 13:28, jianhai luan <jianhai.luan@oracle.com> wrote:
>>>> +	switch (event) {
>>>> +	case NETDEV_NOTIFY_PEERS:
>>>> +		/* Notify frontend to Send gratuitous ARP */
>>>> +		xenbus_switch_state(be->dev, XenbusStateInitialised);
>>>> +		xenbus_switch_state(be->dev, );
>>> This is the sort of change that clearly isn't acceptable, as I don't
>>> think you have ways to check _all_ existing frontends for their
>>> compatibility with this. A connected -> connected transition
>>> might be acceptable (that was done in the block frontend too, for
>>> implementing dynamic resize), but will likely need to be
>>> accompanied by a frontend side patch to handle that (which so
>>> far should be a no-op).
>> The latest xen net-frontent driver have handled the condition. State
>> XenbusStateInitialised will do nothing,
>> but change to XenbusStateConnected will trigger
>> netdev_notify_peers(netdev) to send ARP.
> Did you read my earlier reply carefully? You still only talk about
> (upstream) Linux netfront, but this is not the only (possible)
> frontend. You should not invoke state transitions that can -
> even if only theoretically - blow up frontends. And afaict the
I only want to notify xen-netfront. I don't know what is better way?
To attainthegoal, i try to modify virtual interrupt, but the way is
morecomplicated,modified and working. So, i give up the way.
Would you like to give some suggestion about how to notify xen-netfront?
> only thing you can safely assume frontends ought to tolerate
> are transitions from Connected to Connected (or more
> generally from one state to the same one, but the other
> states aren't useful here, except maybe the Reconfigur* ones).
Sorry for that. At the beginning the patch be applied in kernel 2.6.18 to
fixed one issue. Only XenbusStateInitialised and XenbusStateClosed ( Not
Reconfigure* one) don't any thing, so i choose the XenbusStateInitialised.
Do you suggestion that i choose Reconfigure*?
>
> Jan
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel



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

Re: xen-netback notify DomU to send ARP.

[Jan Beulich]

>>> On 09.01.13 at 17:04, Jason Luan <luanjianhai@163.com> wrote:

(re-adding xen-devel)

> I don't know the meaning of Connected->Connected transition,  can you
> give me to detailed explanation?

Just take a look at drivers/block/xen-blkback/blkback.c:xen_vbd_resize().

Jan

Re: xen-netback notify DomU to send ARP.

[Jason Luan]

[-- Attachment #1.1: Type: text/plain, Size: 1741 bytes --]

Hi Ian,
   Could you give some advice about the patch?

Thanks,
Jason

? 2013?01?10? 15:00, jianhai luan ??:
> The patch main to fix the below circumstance:
> Bonding  run in Active-Backup mode.
> Out PC --> switcher
>             port A --> eth0 --> bond0 --> xenbr0 --> netbackend --> DomU
>             port B -- eth1 /
> Or
>
> Out PC (R)--> switcher A --> eth0 --> bond0 --> xenbr0 --> netbackend 
> --> DomU
>             \ switcher B -- eth1 /
>
> When Switcher Port A (active port) don't reach, or switcher A don't 
> reach,
> the surroundings will changed to the below circumstance.
> Out PC --> switcher
>             port A -X- eth0 -- bond0 -- xenbr0 -- netbackend -- DomU
>             port B -- eth1 /
> Or
>
> Out PC (R)--> switcher A -X- eth0 -- bond0 -- xenbr0 -- netbackend -- 
> DomU
>             \ switcher B -- eth1 /
>
> So, the former traffic will be unreachable before find the correct 
> path (by sending
> ARP request).
>
> So, the patch is main to found the bonding change event, and 
> gratutious ARP initialtivly
> to out PC find the correct path.
>
> the correct path should be the below circumstance:
> Out PC --> switcher
>             port A -X- eth0 --> bond0 --> xenbr0 --> netbackend --> DomU
>             port B --> eth1 /
> Or
>
> Out PC (R)--> switcher A -X- eth0 --> bond0 --> xenbr0 --> netbackend 
> --> DomU
>             \ switcher B --> eth1 /
>
> Thanks,
> Jason
> ?????????????
> ??????????,????????????????????,??????????
>
> 0001-xen-netback-notify-frontend-to-send-gratuitous-ARP.patch
> ??: http://163.fm/DGsSn9l
>
> ??: http://163.fm/SKhxM8D
>
>
>
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel


[-- Attachment #1.2: Type: text/html, Size: 4189 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

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

Re: xen-netback notify DomU to send ARP.

[Jason Luan]

[-- Attachment #1.1: Type: text/plain, Size: 2238 bytes --]

Hi Ian,
   The patch only notify around peer how to reach it when network 
circumstance changed.
I don't know what's  wrong about the patch (the new feature isn't proper 
or the patch have other problem)?
Why do any body ask the issue?

Thanks,
Jason
? 2013?01?10? 23:20, Jason Luan ??:
> Hi Ian,
>   Could you give some advice about the patch?
>
> Thanks,
> Jason
>
> ? 2013?01?10? 15:00, jianhai luan ??:
>> The patch main to fix the below circumstance:
>> Bonding  run in Active-Backup mode.
>> Out PC --> switcher
>>             port A --> eth0 --> bond0 --> xenbr0 --> netbackend --> DomU
>>             port B -- eth1 /
>> Or
>>
>> Out PC (R)--> switcher A --> eth0 --> bond0 --> xenbr0 --> netbackend 
>> --> DomU
>>             \ switcher B -- eth1 /
>>
>> When Switcher Port A (active port) don't reach, or switcher A don't 
>> reach,
>> the surroundings will changed to the below circumstance.
>> Out PC --> switcher
>>             port A -X- eth0 -- bond0 -- xenbr0 -- netbackend -- DomU
>>             port B -- eth1 /
>> Or
>>
>> Out PC (R)--> switcher A -X- eth0 -- bond0 -- xenbr0 -- netbackend -- 
>> DomU
>>             \ switcher B -- eth1 /
>>
>> So, the former traffic will be unreachable before find the correct 
>> path (by sending
>> ARP request).
>>
>> So, the patch is main to found the bonding change event, and 
>> gratutious ARP initialtivly
>> to out PC find the correct path.
>>
>> the correct path should be the below circumstance:
>> Out PC --> switcher
>>             port A -X- eth0 --> bond0 --> xenbr0 --> netbackend --> DomU
>>             port B --> eth1 /
>> Or
>>
>> Out PC (R)--> switcher A -X- eth0 --> bond0 --> xenbr0 --> netbackend 
>> --> DomU
>>             \ switcher B --> eth1 /
>>
>> Thanks,
>> Jason
>> ?????????????
>> ??????????,????????????????????,??????????
>>
>> 0001-xen-netback-notify-frontend-to-send-gratuitous-ARP.patch
>> ??: http://163.fm/DGsSn9l
>>
>> ??: http://163.fm/SKhxM8D
>>
>>
>>
>>
>>
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xen.org
>> http://lists.xen.org/xen-devel
>
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel


[-- Attachment #1.2: Type: text/html, Size: 5278 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

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

Re: xen-netback notify DomU to send ARP.

[Ian Campbell]

On Sun, 2013-01-13 at 01:51 +0000, Jason Luan wrote:
> Hi Ian, 
>   The patch only notify around peer how to reach it when network
> circumstance changed. 
> I don't know what's  wrong about the patch (the new feature isn't
> proper or the patch have other problem)? 

I think the main remaining concern is Jan's regarding what effect this
patch will have upon the various existing netfront's out in the wild.

Have you considered the behaviour of various distro kernels, and the
pvops and classic-Xen trees?

I don't mind if older kernels fail to ARP on this new transition (they
are no worse off than now) but if they crash or something that might be
an issue.

> Why do any body ask the issue?

What do you mean?

Ian.

Re: xen-netback notify DomU to send ARP.

[Jason Luan]

于 2013年01月14日 20:16, Ian Campbell 写道:
> On Sun, 2013-01-13 at 01:51 +0000, Jason Luan wrote:
>> Hi Ian,
>>    The patch only notify around peer how to reach it when network
>> circumstance changed.
>> I don't know what's  wrong about the patch (the new feature isn't
>> proper or the patch have other problem)?
> I think the main remaining concern is Jan's regarding what effect this
> patch will have upon the various existing netfront's out in the wild.
>
> Have you considered the behaviour of various distro kernels, and the
> pvops and classic-Xen trees?

Because the patch fix intern bug of oracle bug queue, I have test some 
netfontends( v2.6.32, v2.6.39 and
the latest kernel of Ubuntu 1104 ) on variable netbackend ( v2.6.18, 
v2.6.32 and v2.6.39) for more time, no
other issue be found.

But i don't test classic-xen trees, i will test for whole day at tomorrow.
>
> I don't mind if older kernels fail to ARP on this new transition (they
> are no worse off than now) but if they crash or something that might be
> an issue.

Yes, you are right. But if no other issue be introduced, sending 
gratuitous ARP initiative will be better.
So, Our trouble is which issue will be introduced by the patch at now? I 
don't found until now. If you have
already thought of some bug, would you like to tell me. I will try to 
fix it.
>
>> Why do any body ask the issue?

Sorry, It is typo (ask should be ack).
> What do you mean?
>
> Ian.
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

Thanks,
Jason


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

Re: xen-netback notify DomU to send ARP.

[Jan Beulich]

>>> On 14.01.13 at 14:39, Jason Luan <luanjianhai@163.com> wrote:
> 于 2013年01月14日 20:16, Ian Campbell 写道:
>> On Sun, 2013-01-13 at 01:51 +0000, Jason Luan wrote:
>>> Hi Ian,
>>>    The patch only notify around peer how to reach it when network
>>> circumstance changed.
>>> I don't know what's  wrong about the patch (the new feature isn't
>>> proper or the patch have other problem)?
>> I think the main remaining concern is Jan's regarding what effect this
>> patch will have upon the various existing netfront's out in the wild.
>>
>> Have you considered the behaviour of various distro kernels, and the
>> pvops and classic-Xen trees?
> 
> Because the patch fix intern bug of oracle bug queue, I have test some 
> netfontends( v2.6.32, v2.6.39 and
> the latest kernel of Ubuntu 1104 ) on variable netbackend ( v2.6.18, 
> v2.6.32 and v2.6.39) for more time, no
> other issue be found.
> 
> But i don't test classic-xen trees, i will test for whole day at tomorrow.

... and Windows and *BSD and Solaris and who knows what else.

Jan

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

Re: xen-netback notify DomU to send ARP.

[Jason Luan]

于 2013年01月14日 22:24, Jan Beulich 写道:
>>>> On 14.01.13 at 14:39, Jason Luan <luanjianhai@163.com> wrote:
>> 于 2013年01月14日 20:16, Ian Campbell 写道:
>>> On Sun, 2013-01-13 at 01:51 +0000, Jason Luan wrote:
>>>> Hi Ian,
>>>>     The patch only notify around peer how to reach it when network
>>>> circumstance changed.
>>>> I don't know what's  wrong about the patch (the new feature isn't
>>>> proper or the patch have other problem)?
>>> I think the main remaining concern is Jan's regarding what effect this
>>> patch will have upon the various existing netfront's out in the wild.
>>>
>>> Have you considered the behaviour of various distro kernels, and the
>>> pvops and classic-Xen trees?
>> Because the patch fix intern bug of oracle bug queue, I have test some
>> netfontends( v2.6.32, v2.6.39 and
>> the latest kernel of Ubuntu 1104 ) on variable netbackend ( v2.6.18,
>> v2.6.32 and v2.6.39) for more time, no
>> other issue be found.
>>
>> But i don't test classic-xen trees, i will test for whole day at tomorrow.
> ... and Windows and *BSD and Solaris and who knows what else.

I have tested the issue on Window, Windows don't occur other issue (but 
Window will don't send ARP) and run good.
I don't test the issue on *BSD and Solaris. Do you suggest that i do 
some test on BSD and Solaris?
>
> Jan
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
Thanks,
Jason


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

Re: xen-netback notify DomU to send ARP.

[Jan Beulich]

>>> On 14.01.13 at 15:43, Jason Luan <luanjianhai@163.com> wrote:
> 于 2013年01月14日 22:24, Jan Beulich 写道:
>>>>> On 14.01.13 at 14:39, Jason Luan <luanjianhai@163.com> wrote:
>>> 于 2013年01月14日 20:16, Ian Campbell 写道:
>>>> On Sun, 2013-01-13 at 01:51 +0000, Jason Luan wrote:
>>>>> Hi Ian,
>>>>>     The patch only notify around peer how to reach it when network
>>>>> circumstance changed.
>>>>> I don't know what's  wrong about the patch (the new feature isn't
>>>>> proper or the patch have other problem)?
>>>> I think the main remaining concern is Jan's regarding what effect this
>>>> patch will have upon the various existing netfront's out in the wild.
>>>>
>>>> Have you considered the behaviour of various distro kernels, and the
>>>> pvops and classic-Xen trees?
>>> Because the patch fix intern bug of oracle bug queue, I have test some
>>> netfontends( v2.6.32, v2.6.39 and
>>> the latest kernel of Ubuntu 1104 ) on variable netbackend ( v2.6.18,
>>> v2.6.32 and v2.6.39) for more time, no
>>> other issue be found.
>>>
>>> But i don't test classic-xen trees, i will test for whole day at tomorrow.
>> ... and Windows and *BSD and Solaris and who knows what else.
> 
> I have tested the issue on Window, Windows don't occur other issue (but 
> Window will don't send ARP) and run good.
> I don't test the issue on *BSD and Solaris. Do you suggest that i do 
> some test on BSD and Solaris?

My preference would be for you to adjust your patch. Failing
that, the next best one is for you to test all existing frontends
(including the multiple different ones available for Windows).

Jan

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