xen/arm Problem with virtual disks

xen/arm Problem with virtual disks

[Andrii Anisov]

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

Hello,

I'm trying to provide my DomU with virtual disk but have faced some strange
issue. Disk device is discovered in DomU but it is not usable. In DomU some
trash is read from the xvd* device, and does not reflect what is read from
the correspondent device in Dom0. Moreover trash read from the device
differs each time (I checked that by dd)

I have xen 4.3 release with my patches for panda5 board.
Dom0 is K3.8, DomU is K3.4.
Dom0 environment is busybox, /etc/xen/scripts/block and related scripts are
adjusted to be executed by busybox ash.

In my config I have following disk definition:

disk = ["phy:/dev/mmcblk0,xvdb,w"]


on verbose create, related output is:

ibxl: debug: libxl_device.c:257:libxl__device_disk_set_backend: Disk
vdev=xvdb spec.backend=phy
libxl: debug: libxl_event.c:559:libxl__ev_xswatch_register: watch w=0x379f8
wpath=/local/domain/0/backend/vbd/1/51728/state token=3/0: register
slotnum=3
libxl: debug: libxl_create.c:1241:do_domain_create: ao 0x36880: inprogress:
poller=0x36808, flags=i
libxl: debug: libxl_event.c:503:watchfd_callback: watch w=0x379f8
wpath=/local/domain/0/backend/vbd/1/51728/state token=3/0: event
epath=/local/domain/0/backend/vbd/1/51728/state
libxl: debug: libxl_event.c:647:devstate_watch_callback: backend
/local/domain/0/backend/vbd/1/51728/state wanted state 2 still waiting
state 1
libxl: debug: libxl_event.c:503:watchfd_callback: watch w=0x379f8
wpath=/local/domain/0/backend/vbd/1/51728/state token=3/0: event
epath=/local/domain/0/backend/vbd/1/51728/state
libxl: debug: libxl_event.c:643:devstate_watch_callback: backend
/local/domain/0/backend/vbd/1/51728/state wanted state 2 ok
libxl: debug: libxl_event.c:596:libxl__ev_xswatch_deregister: watch
w=0x379f8 wpath=/local/domain/0/backend/vbd/1/51728/state token=3/0:
deregister slotnum=3
libxl: debug: libxl_event.c:608:libxl__ev_xswatch_deregister: watch
w=0x379f8: deregister unregistered
libxl: debug: libxl_device.c:959:device_hotplug: calling hotplug script:
/etc/xen/scripts/block add


When DomU discovers virtual disk, in Dom0 console I see following output:

xen-blkback:ring-ref 8, event-channel 3, protocol 1 (arm-abi)

Could it be a problem in contradiction of blkfront and blkback in different
kernels?
Could you please give me some clue to debug such an issue?

*Sincerely,*
*Andrii Anisov.*

[-- Attachment #1.2: Type: text/html, Size: 3363 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/arm Problem with virtual disks

[Ian Campbell]

On Wed, 2013-09-18 at 17:03 +0300, Andrii Anisov wrote:
> Hello,
> 
> 
> I'm trying to provide my DomU with virtual disk but have faced some
> strange issue. Disk device is discovered in DomU but it is not usable.
> In DomU some trash is read from the xvd* device, and does not reflect
> what is read from the correspondent device in Dom0. Moreover trash
> read from the device differs each time (I checked that by dd)
> 
> 
> I have xen 4.3 release with my patches for panda5 board.
> Dom0 is K3.8, DomU is K3.4.

Did 3.4 really have Xen on ARM support? I thought we started later than
that.

> Could it be a problem in contradiction of blkfront and blkback in
> different kernels?

We did iterate a few times on the ABI before getting to a stable point.
I don't recall precisely when or whether that made any difference to the
block protocol though.

> Could you please give me some clue to debug such an issue?

I'd definitely recommend starting by pulling your domU kernel up to
something more recent, e.g. 3.8 like dom0.

Ian.

Re: xen/arm Problem with virtual disks

[Andrii Anisov]

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

> Did 3.4 really have Xen on ARM support? I thought we started later than
> that.

Yep, I forgot, we did backport for our 3.4 at the very beginning... Virtual
console and network worked fine, but we decided to move to virtual disks
few days ago.

We did iterate a few times on the ABI before getting to a stable point.
> I don't recall precisely when or whether that made any difference to the
> block protocol though.

I see, so we should reinvent the wheel... Or double check what have been
backported:)


> I'd definitely recommend starting by pulling your domU kernel up to
> something more recent, e.g. 3.8 like dom0.

I wish I could... But we are running Android as DomU, and the latest stable
release for panda5 based on K3.4.

Sincerely,
Andrii Anisov.

[-- Attachment #1.2: Type: text/html, Size: 1411 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/arm Problem with virtual disks

[Ian Campbell]

On Wed, 2013-09-18 at 18:42 +0300, Andrii Anisov wrote:
>  
> 
>         
>         Did 3.4 really have Xen on ARM support? I thought we started
>         later than
>         that.
> Yep, I forgot, we did backport for our 3.4 at the very beginning...
> Virtual console and network worked fine, but we decided to move to
> virtual disks few days ago.
> 
> 
>         We did iterate a few times on the ABI before getting to a
>         stable point.
>         I don't recall precisely when or whether that made any
>         difference to the
>         block protocol though.
> I see, so we should reinvent the wheel... Or double check what have
> been backported:)
>   
>         I'd definitely recommend starting by pulling your domU kernel
>         up to
>         
>         something more recent, e.g. 3.8 like dom0.
> I wish I could... But we are running Android as DomU, and the latest
> stable release for panda5 based on K3.4.

It might still be worth running a newer kernel in a regular environment
just to validate that the platform is ok.

Then for 3.4 probably the first thing to do would be to diff the
include/xen directory in Linux against something newer and make sure
you've got all the ABI fixes -- from the include/xen/interface
subdirectory in particular.

>  
> Sincerely,
> Andrii Anisov.
> 
> 

Re: xen/arm Problem with virtual disks

[Andrii Anisov]

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

> It might still be worth running a newer kernel in a regular environment
> just to validate that the platform is ok.
>
Good point...
Maybe move Dom0 to the latest omap 3.11. Here we are not so limited. Or
not, taking in account Chen has some problems leads to system crash. That
is the thing to think about.


> Then for 3.4 probably the first thing to do would be to diff the
> include/xen directory in Linux against something newer and make sure
> you've got all the ABI fixes -- from the include/xen/interface
> subdirectory in particular.

Will check.

Sincerely,
Andrii Anisov.

[-- Attachment #1.2: Type: text/html, Size: 1524 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/arm Problem with virtual disks

[Julien Grall]

On 09/18/2013 03:03 PM, Andrii Anisov wrote:
> Hello,

Hello,

> I'm trying to provide my DomU with virtual disk but have faced some
> strange issue. Disk device is discovered in DomU but it is not usable.
> In DomU some trash is read from the xvd* device, and does not reflect
> what is read from the correspondent device in Dom0. Moreover trash read
> from the device differs each time (I checked that by dd)
> I have xen 4.3 release with my patches for panda5 board.

Xen 4.3 was only a tech preview and doesn't contains a couple of
important ARM fixes. If it's possible I advise you to move to xen 4.4
unstable.

> Dom0 is K3.8, DomU is K3.4.
> Dom0 environment is busybox, /etc/xen/scripts/block and related scripts
> are adjusted to be executed by busybox ash.
> 
> In my config I have following disk definition:
> 
>     disk = ["phy:/dev/mmcblk0,xvdb,w"]
> 
> 
> on verbose create, related output is:
> 
>     ibxl: debug: libxl_device.c:257:libxl__device_disk_set_backend: Disk
>     vdev=xvdb spec.backend=phy
>     libxl: debug: libxl_event.c:559:libxl__ev_xswatch_register: watch
>     w=0x379f8 wpath=/local/domain/0/backend/vbd/1/51728/state token=3/0:
>     register slotnum=3
>     libxl: debug: libxl_create.c:1241:do_domain_create: ao 0x36880:
>     inprogress: poller=0x36808, flags=i
>     libxl: debug: libxl_event.c:503:watchfd_callback: watch w=0x379f8
>     wpath=/local/domain/0/backend/vbd/1/51728/state token=3/0: event
>     epath=/local/domain/0/backend/vbd/1/51728/state
>     libxl: debug: libxl_event.c:647:devstate_watch_callback: backend
>     /local/domain/0/backend/vbd/1/51728/state wanted state 2 still
>     waiting state 1
>     libxl: debug: libxl_event.c:503:watchfd_callback: watch w=0x379f8
>     wpath=/local/domain/0/backend/vbd/1/51728/state token=3/0: event
>     epath=/local/domain/0/backend/vbd/1/51728/state
>     libxl: debug: libxl_event.c:643:devstate_watch_callback: backend
>     /local/domain/0/backend/vbd/1/51728/state wanted state 2 ok
>     libxl: debug: libxl_event.c:596:libxl__ev_xswatch_deregister: watch
>     w=0x379f8 wpath=/local/domain/0/backend/vbd/1/51728/state token=3/0:
>     deregister slotnum=3
>     libxl: debug: libxl_event.c:608:libxl__ev_xswatch_deregister: watch
>     w=0x379f8: deregister unregistered
>     libxl: debug: libxl_device.c:959:device_hotplug: calling hotplug
>     script: /etc/xen/scripts/block add
> 
> 
> When DomU discovers virtual disk, in Dom0 console I see following output:
> 
>     xen-blkback:ring-ref 8, event-channel 3, protocol 1 (arm-abi) 
> 
> Could it be a problem in contradiction of blkfront and blkback in
> different kernels?
> Could you please give me some clue to debug such an issue?
>

Few ideas:
   - list of possibly missing commits in xen 4.3:
	* d4435fe5e2f0dfadb41ef46c38f462f45d67762e: avoid the guest to update
the ACTLR himself
	* 8348707ce1c76e2fecbe9d413d5d8f2085bf57cb: correctly configure NSACR
to set ACTLR.SMP
   - http://lists.xen.org/archives/html/xen-devel/2013-06/msg01778.html.
I didn't find any conclusion/commit about this thread.

Perhaps Ian can add more input.

Cheers,


> *Sincerely,*
> *Andrii Anisov.*
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
> 


-- 
Julien Grall

Re: xen/arm Problem with virtual disks

[Ian Campbell]

On Wed, 2013-09-18 at 16:05 +0100, Julien Grall wrote:
> On 09/18/2013 03:03 PM, Andrii Anisov wrote:
> > Hello,
> 
> Hello,
> 
> > I'm trying to provide my DomU with virtual disk but have faced some
> > strange issue. Disk device is discovered in DomU but it is not usable.
> > In DomU some trash is read from the xvd* device, and does not reflect
> > what is read from the correspondent device in Dom0. Moreover trash read
> > from the device differs each time (I checked that by dd)
> > I have xen 4.3 release with my patches for panda5 board.
> 
> Xen 4.3 was only a tech preview and doesn't contains a couple of
> important ARM fixes. If it's possible I advise you to move to xen 4.4
> unstable.
> 
> > Dom0 is K3.8, DomU is K3.4.
> > Dom0 environment is busybox, /etc/xen/scripts/block and related scripts
> > are adjusted to be executed by busybox ash.
> > 
> > In my config I have following disk definition:
> > 
> >     disk = ["phy:/dev/mmcblk0,xvdb,w"]
> > 
> > 
> > on verbose create, related output is:
> > 
> >     ibxl: debug: libxl_device.c:257:libxl__device_disk_set_backend: Disk
> >     vdev=xvdb spec.backend=phy
> >     libxl: debug: libxl_event.c:559:libxl__ev_xswatch_register: watch
> >     w=0x379f8 wpath=/local/domain/0/backend/vbd/1/51728/state token=3/0:
> >     register slotnum=3
> >     libxl: debug: libxl_create.c:1241:do_domain_create: ao 0x36880:
> >     inprogress: poller=0x36808, flags=i
> >     libxl: debug: libxl_event.c:503:watchfd_callback: watch w=0x379f8
> >     wpath=/local/domain/0/backend/vbd/1/51728/state token=3/0: event
> >     epath=/local/domain/0/backend/vbd/1/51728/state
> >     libxl: debug: libxl_event.c:647:devstate_watch_callback: backend
> >     /local/domain/0/backend/vbd/1/51728/state wanted state 2 still
> >     waiting state 1
> >     libxl: debug: libxl_event.c:503:watchfd_callback: watch w=0x379f8
> >     wpath=/local/domain/0/backend/vbd/1/51728/state token=3/0: event
> >     epath=/local/domain/0/backend/vbd/1/51728/state
> >     libxl: debug: libxl_event.c:643:devstate_watch_callback: backend
> >     /local/domain/0/backend/vbd/1/51728/state wanted state 2 ok
> >     libxl: debug: libxl_event.c:596:libxl__ev_xswatch_deregister: watch
> >     w=0x379f8 wpath=/local/domain/0/backend/vbd/1/51728/state token=3/0:
> >     deregister slotnum=3
> >     libxl: debug: libxl_event.c:608:libxl__ev_xswatch_deregister: watch
> >     w=0x379f8: deregister unregistered
> >     libxl: debug: libxl_device.c:959:device_hotplug: calling hotplug
> >     script: /etc/xen/scripts/block add
> > 
> > 
> > When DomU discovers virtual disk, in Dom0 console I see following output:
> > 
> >     xen-blkback:ring-ref 8, event-channel 3, protocol 1 (arm-abi) 
> > 
> > Could it be a problem in contradiction of blkfront and blkback in
> > different kernels?
> > Could you please give me some clue to debug such an issue?
> >
> 
> Few ideas:
>    - list of possibly missing commits in xen 4.3:
> 	* d4435fe5e2f0dfadb41ef46c38f462f45d67762e: avoid the guest to update
> the ACTLR himself
> 	* 8348707ce1c76e2fecbe9d413d5d8f2085bf57cb: correctly configure NSACR
> to set ACTLR.SMP
>    - http://lists.xen.org/archives/html/xen-devel/2013-06/msg01778.html.
> I didn't find any conclusion/commit about this thread.

IIRC in the end the issue could no longer be reproduced and we put it
down to the lack of ACTLR.SMP.


Ian.

Re: xen/arm Problem with virtual disks

[Andrii Anisov]

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

>
> Xen 4.3 was only a tech preview and doesn't contains a couple of
> important ARM fixes. If it's possible I advise you to move to xen 4.4
> unstable.

Yes, I track the master branch from time to time. We definitely plan to
move to 4.4 unstable for our doings, but perhaps later in November.
Together with moving to Jacinto 6 and K3.8 based Android.


> Few ideas:
>    - list of possibly missing commits in xen 4.3:
>         * d4435fe5e2f0dfadb41ef46c38f462f45d67762e: avoid the guest to
> update
> the ACTLR himself
>         * 8348707ce1c76e2fecbe9d413d5d8f2085bf57cb: correctly configure
> NSACR
> to set ACTLR.SMP
>    - http://lists.xen.org/archives/html/xen-devel/2013-06/msg01778.html.
> I didn't find any conclusion/commit about this thread.

Thank you for ideas, will check the stuff.

Sincerely,
Andrii Anisov.

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

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

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