Xen devel - Jun 2007 - [PATCH] Fix change of CDROM for block-configure command

Hi All,

We contributed the problem when CD-ROM was changed as follows.
There was especially no comment though we confirmed the correction method.
Therefore, the patch that corrects these problems is contributed.

Signed-off-by: Takanori Kasai <kasai.takanori@jp.fujitsu.com>

Best Regards,

---
Takanori Kasai


----- Original Message ----- 
From: "Kasai Takanori" <kasai.takanori@jp.fujitsu.com>
To: "xen-devel" <xen-devel@lists.xensource.com>
Sent: Thursday, June 14, 2007 7:30 PM
Subject: [Xen-devel] About change of CDROM

> Hi All,
>
> We tested xm block-configure command.
> Because when the domain image is made, we install it from multiple CDROM.
>
> The procedure of the installation is as follows.
> 1) The HVM domain is started with the CDROM device.
> 　・configuration file :
>   　disk = [
>
''file:/xen/test/install-test.img,hda,w'',''phy:/dev/cdrom,hdc:cdrom,r''
]
>   　boot="d"
> 2) When the installation from CDROM of the first piece is completed, CDROM
is
> exchanged.
> 3) The exchange of CD-ROM is set by the xm block-configure command.
>  # xm block-configure <DomID> phy:/dev/cdrom hdc:cdrom r
> 4) The installation from CDROM of the second piece is continued.
>
> However, there are two problems in this procedure.
> 1) It takes time to recognize the exchange of CDROM.
> 2) Even if the same device is specified, it is not recognized.
>
> We investigated these problems.
>
> 1) It takes time to recognize the exchange of CDROM.
>
> The problem that it takes time for recognition is to wait intentionally on
the
> qemu-dm side.
> ・tools/ioemu/xenstore.c
> 314 void xenstore_process_event(void *opaque)
> 315 {
> ...
> 343     if (image[0]) {
> 344         media_filename[hd_index] = strdup(image);
> 345         xenstore_check_new_media_present(5000);     << This
> 346     }
>
> The processing recognized after it waits for five seconds is executed.
> We think that this waiting is unnecessary after exchanges CDROM.
>
> Why do you wait for five seconds before CDROM recognizes it?
> If it is unnecessary, we want to correct not to wait.
>
> 2) Even if the same device is specified, it is not recognized.
>
> Therefore, we allocated it in other devices once.
> # xm block-configure <DomID> phy:/dev/null hdc:cdrom r
> # xm block-configure <DomID> phy:/dev/cdrom hdc:cdrom r
>
> It is made not to recognize that the same device is specified in qemu-dm.
> ・tools/ioemu/xenstore.c
> 314 void xenstore_process_event(void *opaque)
> 315 {
> ...
> 332     image = xs_read(xsh, XBT_NULL, vec[XS_WATCH_PATH], &len);
> 333     if (image == NULL || !strcmp(image,
bs_table[hd_index]->filename))  <<
> This
> 334         goto out;  /* gone or identical */
>
> It doesn''t operate because it becomes naturally the same name
> when physics CDROM is allocated.
> Even if the name is the same, the content might be not same.
> Only when CDROM is exchanged, it is executed.
>
> When the same device is specified, should we check it?
> We want to correct not to check it.
>
>
> We have confirmed these problems are canceled by the appended patch.
>
> Best Regards,
>
> --
> Takanori Kasai
> 


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

ioemu-nowait-change: This 5s timeout is deliberate. If the media change
event is not delayed by some significant amount of time after the eject
event, Windows guests ignore the media change! The only fix we discovered
for this was to add the large timeout (but in fact Windows polls the CD-ROM
before that triggers, so in fact it detects the media significantly before
the 5 second delay is finished).

ioemu-nocheck-change: The strcmp is deliberate, to filter out redundant
firings of the xenstore watch. If you want to be able to e.g., notify of
changes to ''/dev/cdrom'' then that should be implemented at a
higher level
(e.g., in xend) by writing an empty string to xenstore, immediately followed
by ''/dev/cdrom'' (or whatever filename).

 -- Keir

On 19/6/07 08:05, "Kasai Takanori"
<kasai.takanori@jp.fujitsu.com> wrote:
> Hi All,
> 
> We contributed the problem when CD-ROM was changed as follows.
> There was especially no comment though we confirmed the correction method.
> Therefore, the patch that corrects these problems is contributed.
> 
> Signed-off-by: Takanori Kasai <kasai.takanori@jp.fujitsu.com>
> 
> Best Regards,
> 
> ---
> Takanori Kasai
> 
> 
> ----- Original Message -----
> From: "Kasai Takanori" <kasai.takanori@jp.fujitsu.com>
> To: "xen-devel" <xen-devel@lists.xensource.com>
> Sent: Thursday, June 14, 2007 7:30 PM
> Subject: [Xen-devel] About change of CDROM
> 
> 
>> Hi All,
>> 
>> We tested xm block-configure command.
>> Because when the domain image is made, we install it from multiple
CDROM.
>> 
>> The procedure of the installation is as follows.
>> 1) The HVM domain is started with the CDROM device.
>> 　・configuration file :
>>   　disk = [
>>
''file:/xen/test/install-test.img,hda,w'',''phy:/dev/cdrom,hdc:cdrom,r''
]
>>   　boot="d"
>> 2) When the installation from CDROM of the first piece is completed,
CDROM is
>> exchanged.
>> 3) The exchange of CD-ROM is set by the xm block-configure command.
>>  # xm block-configure <DomID> phy:/dev/cdrom hdc:cdrom r
>> 4) The installation from CDROM of the second piece is continued.
>> 
>> However, there are two problems in this procedure.
>> 1) It takes time to recognize the exchange of CDROM.
>> 2) Even if the same device is specified, it is not recognized.
>> 
>> We investigated these problems.
>> 
>> 1) It takes time to recognize the exchange of CDROM.
>> 
>> The problem that it takes time for recognition is to wait intentionally
on
>> the
>> qemu-dm side.
>> ・tools/ioemu/xenstore.c
>> 314 void xenstore_process_event(void *opaque)
>> 315 {
>> ...
>> 343     if (image[0]) {
>> 344         media_filename[hd_index] = strdup(image);
>> 345         xenstore_check_new_media_present(5000);     << This
>> 346     }
>> 
>> The processing recognized after it waits for five seconds is executed.
>> We think that this waiting is unnecessary after exchanges CDROM.
>> 
>> Why do you wait for five seconds before CDROM recognizes it?
>> If it is unnecessary, we want to correct not to wait.
>> 
>> 2) Even if the same device is specified, it is not recognized.
>> 
>> Therefore, we allocated it in other devices once.
>> # xm block-configure <DomID> phy:/dev/null hdc:cdrom r
>> # xm block-configure <DomID> phy:/dev/cdrom hdc:cdrom r
>> 
>> It is made not to recognize that the same device is specified in
qemu-dm.
>> ・tools/ioemu/xenstore.c
>> 314 void xenstore_process_event(void *opaque)
>> 315 {
>> ...
>> 332     image = xs_read(xsh, XBT_NULL, vec[XS_WATCH_PATH], &len);
>> 333     if (image == NULL || !strcmp(image,
bs_table[hd_index]->filename))
>> <<
>> This
>> 334         goto out;  /* gone or identical */
>> 
>> It doesn''t operate because it becomes naturally the same name
>> when physics CDROM is allocated.
>> Even if the name is the same, the content might be not same.
>> Only when CDROM is exchanged, it is executed.
>> 
>> When the same device is specified, should we check it?
>> We want to correct not to check it.
>> 
>> 
>> We have confirmed these problems are canceled by the appended patch.
>> 
>> Best Regards,
>> 
>> --
>> Takanori Kasai
>> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

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

Hi Keir,

Thank you for reply.
> ioemu-nowait-change: This 5s timeout is deliberate.
We consented that waiting was necessary for the Windows guest.
 
> ioemu-nocheck-change: The strcmp is deliberate, to filter out redundant
> firings of the xenstore watch. If you want to be able to e.g., ...
We corrected the patch like writing an empty once character in xend.
 
Signed-off-by: Takanori Kasai <kasai.takanori@jp.fujitsu.com>


BTW, there is an acute problem in the change of CDROM.

When physical device (/dev/cdrom) of CDROM is set first, 
CDROM of the second piece cannot be correctly read. 

It remains opening former device on backend 
even if it changes with block-configure.

Therefore, CDROM of the second piece can read only the size of the first piece.

linux-2.6.18-xen.hg/drivers/xen/blkback/xenbus.c
264  static void backend_changed(struct xenbus_watch *watch,
265                              const char **vec, unsigned int len)
...
315                  err = vbd_create(be->blkif, handle, major, minor,
316                                   (NULL == strchr(be->mode,
''w'')));

How do you think that we should correct about this problem?

Best Regards,

--
Takanori Kasai 

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