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

[Xen-devel] RFC: Xen cdrom haldaemon


  • To: <xen-devel@xxxxxxxxxxxxxxxxxxx>
  • From: "Pat Campbell" <plc@xxxxxxxxxx>
  • Date: Wed, 05 Sep 2007 10:43:30 -0600
  • Delivery-date: Wed, 05 Sep 2007 09:47:46 -0700
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>

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


Attachment: cdrom-test.c
Description: Binary data

Attachment: xen-3.1-cdrom.patch
Description: Text document

_______________________________________________
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®.