regression with c/s 21223

regression with c/s 21223

[Jim Fehlig]

Hi Keir,

Unfortunately, my fix for losing device config [1] has caused duplicate
devices to appear when successfully starting a managed domain that uses
tapdisk :(. 

# xm li -l domu1 | grep tap
        (tap2
            (uname tap:aio:/mnt1/images/domu1/disk0)
# xm start domu1
# xm li -l domu1 | grep tap
        (tap2
            (uname tap:aio:/mnt1/images/domu1/disk0)
        (tap
            (uname tap:aio:/mnt1/images/domu1disk0)

This particular host does not have blktap2 driver so blktap1 is used
instead.  (NB: I do not see the problem when using blktap2, but we are
not yet supporting it.)

c/s 21223 attempted to make to_sxp() consult the stored config if no
running config was found for a given device class.  tap2 vs tap provides
an interesting twist.  If blktap2 dev controller is consulted (cls ==
tap2), no running config is returned since the device is really being
handled by blktap1.  The existing config is then consulted, in which
case a blktap2 (tap2) device is found.  When blktap1 controller is
consulted (cls == tap), it returns running config found in xenstore
resulting in duplicate devices.

Frankly, I'm not sure how best to handle this case.  The current
philosophy seems to be treat all 'tap:foo' devices as blktap2 (see c/s
19874 - author cc'd), but fall back to blktap1 if blktap2 is not found
when domU is started.  I'm certainly having problems differentiating
between the two in to_sxp().

Any suggestions on how to prevent the bug reported in [1] without this
new regression?

Thanks,
Jim

[1] http://lists.xensource.com/archives/html/xen-devel/2010-04/msg01127.html

Re: regression with c/s 21223

[Keir Fraser]

On 07/05/2010 04:36, "Jim Fehlig" <jfehlig@novell.com> wrote:

> Frankly, I'm not sure how best to handle this case.  The current
> philosophy seems to be treat all 'tap:foo' devices as blktap2 (see c/s
> 19874 - author cc'd), but fall back to blktap1 if blktap2 is not found
> when domU is started.  I'm certainly having problems differentiating
> between the two in to_sxp().
> 
> Any suggestions on how to prevent the bug reported in [1] without this
> new regression?

Way outside my comfort zone with xend I'm afraid. Do you think we need
explicit differentiation between tap and tap2?

 -- Keir

Re: regression with c/s 21223

[Jim Fehlig]

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

Keir Fraser wrote:
> On 07/05/2010 04:36, "Jim Fehlig" <jfehlig@novell.com> wrote:
>
>   
>> Frankly, I'm not sure how best to handle this case.  The current
>> philosophy seems to be treat all 'tap:foo' devices as blktap2 (see c/s
>> 19874 - author cc'd), but fall back to blktap1 if blktap2 is not found
>> when domU is started.  I'm certainly having problems differentiating
>> between the two in to_sxp().
>>
>> Any suggestions on how to prevent the bug reported in [1] without this
>> new regression?
>>     
>
> Way outside my comfort zone with xend I'm afraid. Do you think we need
> explicit differentiation between tap and tap2?
>   

That is certainly an approach we are considering for our Xen 4.0-based
packages - see attached patch.  As mentioned previously, we are not yet
supporting blktap2 so such a change seems appropriate in our case.

I'm hoping some of the folks that integrated blktap2 in xend can provide
suggestions.

Regards,
Jim


[-- Attachment #2: suse-disable-tap2-default.patch --]
[-- Type: text/x-patch, Size: 1171 bytes --]

Index: xen-4.0.0-testing/tools/python/xen/xm/main.py
===================================================================
--- xen-4.0.0-testing.orig/tools/python/xen/xm/main.py
+++ xen-4.0.0-testing/tools/python/xen/xm/main.py
@@ -2629,8 +2629,10 @@ def xm_usb_list_assignable_devices(args)
 def parse_block_configuration(args):
     dom = args[0]
 
-    if args[1].startswith('tap:'):
+    if args[1].startswith('tap2:'):
         cls = 'tap2'
+    elif args[1].startswith('tap:'):
+        cls = 'tap'
     else:
         cls = 'vbd'
 
Index: xen-4.0.0-testing/tools/python/xen/xm/create.py
===================================================================
--- xen-4.0.0-testing.orig/tools/python/xen/xm/create.py
+++ xen-4.0.0-testing/tools/python/xen/xm/create.py
@@ -791,8 +791,10 @@ def configure_disks(config_devs, vals):
     """Create the config for disks (virtual block devices).
     """
     for (uname, dev, mode, backend, protocol) in vals.disk:
-        if uname.startswith('tap:'):
+        if uname.startswith('tap2:'):
             cls = 'tap2'
+        elif uname.startswith('tap:'):
+            cls = 'tap'
         else:
             cls = 'vbd'
 

[-- Attachment #3: Type: text/plain, Size: 138 bytes --]

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

Re: regression with c/s 21223

[Keir Fraser]

On 07/05/2010 14:37, "Jim Fehlig" <jfehlig@novell.com> wrote:

>> Way outside my comfort zone with xend I'm afraid. Do you think we need
>> explicit differentiation between tap and tap2?
>>   
> 
> That is certainly an approach we are considering for our Xen 4.0-based
> packages - see attached patch.  As mentioned previously, we are not yet
> supporting blktap2 so such a change seems appropriate in our case.

Does that simple patch really "just work"? I suppose it really just punts
the tap2 issues, unless we also get rid of the tap2-falls-back-to-tap1
logic?

 -- Keir

> I'm hoping some of the folks that integrated blktap2 in xend can provide
> suggestions.

Re: regression with c/s 21223

[Jim Fehlig]

Keir Fraser wrote:
> On 07/05/2010 14:37, "Jim Fehlig" <jfehlig@novell.com> wrote:
>
>   
>>> Way outside my comfort zone with xend I'm afraid. Do you think we need
>>> explicit differentiation between tap and tap2?
>>>   
>>>       
>> That is certainly an approach we are considering for our Xen 4.0-based
>> packages - see attached patch.  As mentioned previously, we are not yet
>> supporting blktap2 so such a change seems appropriate in our case.
>>     
>
> Does that simple patch really "just work"?

It does for me, and I've done quite a bit of testing using 'tap:foo' and
'tap2:foo', with and without blktap2 module loaded.

>  I suppose it really just punts
> the tap2 issues, unless we also get rid of the tap2-falls-back-to-tap1
> logic?
>   

It reverts 2 hunks of c/s 19874, which implicitly converts the device to
tap2 in a xend client app!  If the same configuration is provided to
xend through libvirt, this implicit conversion does not occur.  I'd
suspect this is true for direct users of XenAPI as well.

But yes, I agree that if an explicit differentiation between tap and
tap2 exists, then the tap2-fall-back-to-tap1 logic should be removed. 
It would be nice to get input from others, particularly authors of
blktap2 integration patches :-).

Regards,
Jim

Re: regression with c/s 21223

[Keir Fraser]

On 07/05/2010 20:31, "Jim Fehlig" <jfehlig@novell.com> wrote:

>>  I suppose it really just punts
>> the tap2 issues, unless we also get rid of the tap2-falls-back-to-tap1
>> logic?
>>   
> 
> It reverts 2 hunks of c/s 19874, which implicitly converts the device to
> tap2 in a xend client app!  If the same configuration is provided to
> xend through libvirt, this implicit conversion does not occur.  I'd
> suspect this is true for direct users of XenAPI as well.
> 
> But yes, I agree that if an explicit differentiation between tap and
> tap2 exists, then the tap2-fall-back-to-tap1 logic should be removed.
> It would be nice to get input from others, particularly authors of
> blktap2 integration patches :-).

Well, in the absence of that I'm happy to take the patch, and I guess
backport it for 4.0.1.

 -- Keir

Does Xen 3.4.3 support pvops kernel 2.6.32.12 ?

[Boris Derzhavets]

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

Sorry, if i missed something in previous discussion (threads) .
But it sounds for me that answer is "NO" due to 3.4.3 
doesn't have all required CSs for IOAPIC (2.6.32.X) back ported.

Boris.






      

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

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

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

Re: Does Xen 3.4.3 support pvops kernel 2.6.32.12 ?

[Keir Fraser]

On 16/05/2010 11:54, "Boris Derzhavets" <bderzhavets@yahoo.com> wrote:

> Sorry, if i missed something in previous discussion (threads) .
> But it sounds for me that answer is "NO" due to 3.4.3
> doesn't have all required CSs for IOAPIC (2.6.32.X) back ported.

Yeah, I think it misses the boat. Maybe 3.4.4 if there is some developer
interest in cherry-picking the patches, and sufficient testing effort.

 -- Keir

Re: Re: Does Xen 3.4.3 support pvops kernel 2.6.32.12 ?

[Joanna Rutkowska]

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

On 05/16/2010 01:09 PM, Keir Fraser wrote:
> On 16/05/2010 11:54, "Boris Derzhavets" <bderzhavets@yahoo.com> wrote:
> 
>> Sorry, if i missed something in previous discussion (threads) .
>> But it sounds for me that answer is "NO" due to 3.4.3
>> doesn't have all required CSs for IOAPIC (2.6.32.X) back ported.
> 
> Yeah, I think it misses the boat. Maybe 3.4.4 if there is some developer
> interest in cherry-picking the patches, and sufficient testing effort.
> 
Hmmm... I'm just running 2.6.32.12 for my Dom0 (Based on Young's RPMS
with some minor modifications for Qubes) on Xen 3.4.3-rc3 and it seems
to be working fine.

j.


[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 226 bytes --]

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

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