[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


  • To: Pat Campbell <plc@xxxxxxxxxx>, <xen-devel@xxxxxxxxxxxxxxxxxxx>
  • From: Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>
  • Date: Wed, 05 Sep 2007 18:39:28 +0100
  • Delivery-date: Wed, 05 Sep 2007 10:35:30 -0700
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>
  • Thread-index: Acfv47Uz885UGVvWEdyaDQAWy6hiGQ==
  • Thread-topic: [Xen-devel] RFC: Xen cdrom haldaemon

Could the haldaemon's work be pushed into blkback in the kernel?

 -- 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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.