Re: [Xen-devel] [PATCH] Fix change of CDROM for block-configure command

[Keir Fraser <keir@xxxxxxxxxxxxx>]

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@xxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxx>
> 
> Best Regards,
> 
> ---
> Takanori Kasai
> 
> 
> ----- Original Message -----
> From: "Kasai Takanori" <kasai.takanori@xxxxxxxxxxxxxx>
> To: "xen-devel" <xen-devel@xxxxxxxxxxxxxxxxxxx>
> 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@xxxxxxxxxxxxxxxxxxx
> http://lists.xensource.com/xen-devel


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