From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Pat Campbell" Subject: Re: RFC: Xen cdrom haldaemon Date: Thu, 06 Sep 2007 08:05:17 -0600 Message-ID: <46DFB2D1.3E48.0018.0@novell.com> References: <20070903191808.GC22983@redhat.com> <46DE8884.3E48.0018.0@novell.com> <20070905175633.GI5503@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Return-path: In-Reply-To: <20070905175633.GI5503@redhat.com> Content-Disposition: inline List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: "Daniel P. Berrange" Cc: xen-devel@lists.xensource.com List-Id: xen-devel@lists.xenproject.org >>> On Wed, Sep 5, 2007 at 11:56 AM, in message <20070905175633.GI5503@redh= at.com>, "Daniel P. Berrange" wrote:=20 > On Wed, Sep 05, 2007 at 10:43:30AM - 0600, Pat Campbell wrote: >> The basic flow of the patch is: >>=20 >> Kernel: >> blkback driver:=20 >> if block device is a physical cdrom then >> Add media_present=3D1 into xenstore backend/vbd=20 >> for this device >> Place a xenstore watch on media_present >> =20 >> 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 >>=20 >> Any access with fd closed results in EACCESS error >>=20 >> qemu >> if block device is a cdrom >> Place a xenstore watch on media_present=20 >> 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 >>=20 >> Any access with fd closed results in EACCESS error >> =20 >> xend >> Starts XEN HalDaemon process >> =20 >> XEN HalDaemon =20 >> 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 >>=20 >> I am just learning python, could use a python guy to enhance = and=20 >> generalize. >=20 > To be honest this sounds like rather overkill. Why on earth is blkback > opening the device in the first place? blkback/blkfront don't have any > kind of support for CDROM capabilities, so paravirt drivers for a disk > device Xend marked as a cdrom don't make sense. If we stop blkback from > processing any devices with the ':cdrom' annotation, then only QEMU will > have the device open & the problem should go away if I'm understanding > your description properly. >=20 > Dan. Getting rid of the blkback open FD for QEMU guests would help but the root problem still exists. We still need to get all open file descriptors = to the CDROM device closed and reopened when the media is swapped out. This is a contrived scenario but possible. =20 4 active FV guests, all configured to the same physical CDROM=20 ( These guests for whatever reason share the CDROM data ) Currently there will be 8 open descriptors, 4 if blkback is changed Admin wants to swap out the CD with a new one that has additional info All open descriptors have to be closed before any guest will be=20 able to access the additional info because of the CD size not = being=20 changed while any app has the CD device open.=20 Pat