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.* _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
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.
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
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.
> 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. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
> > 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. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
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. > >
> 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. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel