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

Re: Does Xen 3.4.3 support pvops kernel 2.6.32.12 ?

[Boris Derzhavets]

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

However, my current environment just been built today via xen-3.4-testing.hg :-

root@ServerKoala:~# xm info
host                   : ServerKoala
release                : 2.6.32.12
version                : #16 SMP Sun May 16 20:17:58 MSD 2010
machine                : x86_64
nr_cpus                : 4
nr_nodes               : 1
cores_per_socket       : 4
threads_per_core       : 1
cpu_mhz                : 2833
hw_caps                : bfebfbff:20100800:00000000:00000140:0408e3fd:00000000:00000001:00000000
virt_caps              : hvm
total_memory           : 8190
free_memory            : 2056
node_to_cpu            : node0:0-3
node_to_memory         : node0:2056
xen_major              : 3
xen_minor              : 4
xen_extra              : .3-rc7-pre
xen_caps               : xen-3.0-x86_64 xen-3.0-x86_32p hvm-3.0-x86_32 hvm-3.0-x86_32p hvm-3.0-x86_64 
xen_scheduler          : credit
xen_pagesize           : 4096
platform_params        : virt_start=0xffff800000000000
xen_changeset          : Thu May 13 10:40:19 2010 +0100 19967:d11bdc25b36d
cc_compiler            : gcc version 4.4.1 (Ubuntu 4.4.1-4ubuntu9) 
cc_compile_by          : root
cc_compile_domain      : 
cc_compile_date        : Sun May 16 19:40:04 MSD 2010
xend_config_format     : 4

Boris.


--- On Sun, 5/16/10, Keir Fraser <keir.fraser@eu.citrix.com> wrote:

From: Keir Fraser <keir.fraser@eu.citrix.com>
Subject: Re: Does Xen 3.4.3 support pvops kernel 2.6.32.12 ?
To: "Boris Derzhavets" <bderzhavets@yahoo.com>
Cc: "Xen-devel" <xen-devel@lists.xensource.com>
Date: Sunday, May 16, 2010, 7:09 AM

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





      

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

[-- Attachment #2: config.2.6.32.12.gz --]
[-- Type: application/x-gzip, Size: 27434 bytes --]

[-- Attachment #3: dmesg.log.gz --]
[-- Type: application/x-gzip, Size: 14079 bytes --]

[-- Attachment #4: xm_list_-l.txt --]
[-- Type: text/plain, Size: 4982 bytes --]

(domain
    (domid 0)
    (bootloader )
    (on_crash restart)
    (uuid 00000000-0000-0000-0000-000000000000)
    (bootloader_args )
    (vcpus 4)
    (name Domain-0)
    (cpus
        ((0
             1
             2
             3
             4
             5
             6
             7
             8
             9
             10
             11
             12
             13
             14
             15
             16
             17
             18
             19
             20
             21
             22
             23
             24
             25
             26
             27
             28
             29
             30
             31
         )
            (0
                1
                2
                3
                4
                5
                6
                7
                8
                9
                10
                11
                12
                13
                14
                15
                16
                17
                18
                19
                20
                21
                22
                23
                24
                25
                26
                27
                28
                29
                30
                31
            )
            (0
                1
                2
                3
                4
                5
                6
                7
                8
                9
                10
                11
                12
                13
                14
                15
                16
                17
                18
                19
                20
                21
                22
                23
                24
                25
                26
                27
                28
                29
                30
                31
            )
            (0
                1
                2
                3
                4
                5
                6
                7
                8
                9
                10
                11
                12
                13
                14
                15
                16
                17
                18
                19
                20
                21
                22
                23
                24
                25
                26
                27
                28
                29
                30
                31
            )
        )
    )
    (on_reboot restart)
    (on_poweroff destroy)
    (maxmem 16777215)
    (memory 6800)
    (shadow_memory 0)
    (features )
    (on_xend_start ignore)
    (on_xend_stop ignore)
    (cpu_time 306.517396646)
    (online_vcpus 4)
    (image (linux (kernel )))
    (status 2)
    (state r-----)
)
(domain
    (domid 2)
    (bootloader /usr/lib/xen-default/bin/pygrub)
    (on_crash restart)
    (uuid e8450878-324a-dcf0-63ba-6b825a141e44)
    (bootloader_args )
    (vcpus 2)
    (name VF13PV)
    (cpus (() ()))
    (on_reboot restart)
    (on_poweroff destroy)
    (maxmem 2048)
    (memory 2048)
    (shadow_memory 0)
    (features )
    (on_xend_start ignore)
    (on_xend_stop ignore)
    (start_time 1274029740.38)
    (cpu_time 46.469983375)
    (online_vcpus 2)
    (image
        (linux
            (kernel )
            (device_model /usr/lib64/xen/bin/qemu-dm)
            (notes
                (HV_START_LOW 18446603336221196288)
                (FEATURES '!writable_page_tables|pae_pgdir_above_4gb')
                (VIRT_BASE 18446744071562067968)
                (GUEST_VERSION 2.6)
                (PADDR_OFFSET 0)
                (GUEST_OS linux)
                (HYPERCALL_PAGE 18446744071578849280)
                (LOADER generic)
                (SUSPEND_CANCEL 1)
                (PAE_MODE yes)
                (ENTRY 18446744071591059968)
                (XEN_VERSION xen-3.0)
            )
        )
    )
    (status 2)
    (state -b----)
    (store_mfn 2129478)
    (console_mfn 2129477)
    (device
        (vif
            (bridge eth0)
            (mac 00:16:36:0c:63:de)
            (script /etc/xen/scripts/vif-bridge)
            (uuid f09fad10-18db-3bdb-0f93-0a1768bfc9d0)
            (backend 0)
        )
    )
    (device (vkbd (backend 0)))
    (device
        (console
            (protocol vt100)
            (location 2)
            (uuid 2fc5ba38-7afb-fcbf-05da-c2728c58f10b)
        )
    )
    (device
        (vbd
            (protocol x86_64-abi)
            (uuid 1c57d6b5-01cc-8e42-9ee1-60282d9dac44)
            (bootable 1)
            (dev xvda:disk)
            (uname phy:/dev/sdb5)
            (mode w)
            (backend 0)
            (bootable 1)
            (VDI )
        )
    )
    (device
        (vfb
            (vncunused 1)
            (keymap en-us)
            (vnc 1)
            (uuid a99a4c5c-cdb1-09b2-2270-b788f3c2d871)
            (location 127.0.0.1:5900)
        )
    )
)

[-- Attachment #5: 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]

Ah, well if it already works then great. I thought there had been a previous
report of it not working, and no subsequent fix.

 -- Keir

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

> However, my current environment just been built today via xen-3.4-testing.hg
> :-
> 
> root@ServerKoala:~# xm info
> host                   : ServerKoala
> release                : 2.6.32.12
> version                : #16 SMP Sun May 16 20:17:58 MSD 2010
> machine                : x86_64
> nr_cpus                : 4
> nr_nodes               : 1
> cores_per_socket       : 4
> threads_per_core       : 1
> cpu_mhz                : 2833
> hw_caps                :
> bfebfbff:20100800:00000000:00000140:0408e3fd:00000000:00000001:00000000
> virt_caps              : hvm
> total_memory           : 8190
> free_memory            : 2056
> node_to_cpu            : node0:0-3
> node_to_memory         : node0:2056
> xen_major              : 3
> xen_minor              : 4
> xen_extra              : .3-rc7-pre
> xen_caps               : xen-3.0-x86_64 xen-3.0-x86_32p hvm-3.0-x86_32
> hvm-3.0-x86_32p hvm-3.0-x86_64
> xen_scheduler          : credit
> xen_pagesize           : 4096
> platform_params        : virt_start=0xffff800000000000
> xen_changeset          : Thu May 13 10:40:19 2010 +0100 19967:d11bdc25b36d
> cc_compiler            : gcc version 4.4.1 (Ubuntu 4.4.1-4ubuntu9)
> cc_compile_by          : root
> cc_compile_domain      :
> cc_compile_date        : Sun May 16 19:40:04 MSD 2010
> xend_config_format     : 4
> 
> Boris.
> 
> 
> --- On Sun, 5/16/10, Keir Fraser <keir.fraser@eu.citrix.com> wrote:
>> 
>> From: Keir Fraser <keir.fraser@eu.citrix.com>
>> Subject: Re: Does Xen 3.4.3 support pvops kernel 2.6.32.12 ?
>> To: "Boris Derzhavets" <bderzhavets@yahoo.com>
>> Cc: "Xen-devel" <xen-devel@lists.xensource.com>
>> Date: Sunday, May 16, 2010, 7:09 AM
>> 
>> On 16/05/2010 11:54, "Boris Derzhavets" <bderzhavets@yahoo.com
>> </mc/compose?to=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
>> 
>> 
> 
>