Re: [Xen-devel] RFC: Xen cdrom haldaemon

["Pat Campbell" <plc@xxxxxxxxxx>]

> On Wed, Sep 5, 2007 at 11:39 AM,  Keir Fraser <Keir.Fraser@xxxxxxxxxxxx> 
> wrote: 
>
> Could the haldaemon's work be pushed into blkback in the kernel?

Could be but if we pull it into the kernel we would have to write our own device
poll routine and no longer leverage HALD and DBUS. 

As I have thought about this some more I think the code I added to blkback 
to create the media present attribute should be moved up into xend as well.  

Pat

> 
>  --  Keir
> 
> On 5/9/07 17:43, "Pat Campbell" <plc@xxxxxxxxxx> wrote:
> 
>> Hi,
>> 
>> I have found that the DOM0 CDROM device returns a stale disk
>> size if a CD is changed while any application has the device open.
>> 
>> Test scenerio:  ( Don't need XEN for this )
>>   Two shell processes
>>     Shell A runs simple test program with an arg to
>>        open the cd for reading
>>        report media size using lseek(0, SEEK_END)
>>        then enter a sleep loop leaving FD open
>>     In Shell B 
>>        eject 
>>        insert a different CD
>>        eject - t, 
>>        run simple test progran, no arg
>>            ( size is still what was reported in shell A)
>>        Kill Shell A test CD process
>>        Run test CD process again, now you should have the
>>            correct size
>> 
>>   Simple test program, cdrom- test.c, has been attached.
>> 
>> I did enter a defect against the Linux kernel about this but
>> was unable to convince them it was their defect.
>> 
>> If we put Xen in the mix, say installing a FV Redhat system
>> from physical CD media you will have two CDROM device file
>> descriptors open.  One in blkback and the other in QEMU.
>> When you get to CD #2 you won't be able to complete the
>> install as the total disk size has not been updated for
>> the larger CD #2, stays at the smaller CD #1 size.
>> 
>> You can get the QEMU descriptor closed by using xen- store
>> writes but none effect the blkback FD and there is no
>> way, that I have found, to effect ALL open Xen related FDs on
>> that device.
>> 
>> I have created a proof of concept patch for 3.1 that addresses the
>> above issue by causing all VMs, FV and PV, to close thier open
>> pyhsical CDROM file descriptors when the device door is opened.  File
>> descriptors are re- opened when the door is closed AND a CD was
>> inserted.
>> 
>> The basic flow of the patch is:
>> 
>>  Kernel:
>>      blkback driver:
>>        if block device is a physical cdrom then
>>           Add media_present=1 into xenstore  backend/vbd
>>              for this device
>>           Place a xenstore watch on media_present
>>        
>>        watch_handler
>>           if watch token is media_present
>>               read value
>>               if 0 then close block device fd
>>               if 1 then re- open block device fd
>> 
>>        Any access with fd closed results in EACCESS error
>> 
>>     qemu
>>        if block device is a cdrom
>>           Place a xenstore watch on media_present
>>        watch_handler
>>           if watch token is media_present
>>               read value
>>               if 0 then close block device
>>               if 1 then re- open block device and set media_changed
>> 
>>        Any access with fd closed results in EACCESS error
>>  
>>     xend
>>        Starts XEN HalDaemon process
>>     
>>     XEN HalDaemon
>>       Registers event callback for HALD events
>>        callback handler
>>           gets device major/minor numbers
>>           for each vbd in xenstore
>>              if matching major and minor
>>                 if add_event ( cdrom door closed with media )
>>                    xenstore write 1 to vbd/media_present
>>                 else         ( cddrom door open )
>>                    xenstore write 0 to vbd/media_present
>> 
>>       I am just learning python, could use a python guy to enhance and
>>       generalize.
>> 
>> With my patch applied I was able to install RHEL5 from the 5 CD set as
>> well as a WIN2003 server from multi CD media.
>> 
>> The patch is attached. Patch still needs some work but I would like
>> some feedback before going further down this path. Is this something
>> that fits into the current and near future architecture and might be
>> considered for addition?
>> 
>> Thanks in advance
>> 
>> Pat
>> 
>> 
>> _______________________________________________
>> 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