Folks, We''re planning to roll an update to the 3.1 branch, hopefully towards the end of next week. I have a fair number of patches already queued up to consider for backport, but if anyone has any in particular they would like to be considered, please let us know! This is *particularly* aimed at ia64 and powerpc maintainers, since I currently have no ia64 or ppc patches queued up for backport. Regards, Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On Mon, Sep 03, 2007 at 03:34:42PM +0100, Keir Fraser wrote:> Folks, > > We''re planning to roll an update to the 3.1 branch, hopefully towards the > end of next week. I have a fair number of patches already queued up to > consider for backport, but if anyone has any in particular they would like > to be considered, please let us know! This is *particularly* aimed at ia64 > and powerpc maintainers, since I currently have no ia64 or ppc patches > queued up for backport.I''d like to get the PVFB changes to replace libvncserver with QEMU into the release. I''ll post updated patches ASAP. I recently managed to get support for TLS + x509 certificate authentication merged into upstream QEMU for the VNC server so we have some serious quality security there. The back-port to QEMU 0.9.0 in Xen should be fairly easy for me to do, so I''ll hopefully be able submit that in the next week too. Regards, Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=| _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Two things I would like to see fixed (which may already be...) are: 1. the bug in qemu that was giving me random crashes (see patch supplied by ''Daniel P. Berrange [berrange@redhat.com]'' in the xen-users list with the subject ''qemu-dm crashing under 3.1'' on or around 20070615). HVM is pretty much not usable without it - uptimes of a few days maximum. 2. A fix for the bug where HVM domains ignore the flag to say use local time. My windows domains all start 10 hours off. Thanks James> -----Original Message----- > From: xen-devel-bounces@lists.xensource.com [mailto:xen-devel- > bounces@lists.xensource.com] On Behalf Of Keir Fraser > Sent: Tuesday, 4 September 2007 00:35 > To: xen-devel > Subject: [Xen-devel] RFC: Xen 3.1.1 > > Folks, > > We''re planning to roll an update to the 3.1 branch, hopefully towardsthe> end of next week. I have a fair number of patches already queued up to > consider for backport, but if anyone has any in particular they wouldlike> to be considered, please let us know! This is *particularly* aimed atia64> and powerpc maintainers, since I currently have no ia64 or ppc patches > queued up for backport. > > Regards, > Keir > > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On Mon, Sep 03, 2007 at 03:34:42PM +0100, Keir Fraser wrote:> We''re planning to roll an update to the 3.1 branch, hopefully towards the > end of next week.That seems awfully quick, given that we can''t yet see what will be in the release? Top of my list are all the patches that implement missing Xen API stuff such as 15275:b643179d7452 Also the managed domain foibles like 15149:8fcefab1d63b and 15394:168b143a1a88, etc. Both of these groups of patches are essentially finishing stuff that should have been in the release already so seem important. 15161:e046da853ffc - whilst an RFE, this would be very nice to have. 15164:d93e560c1d50 15165:4730ec3d5ab3 15179:152dc0d812b2 - these are essentially about not losing data 15621:f85acff5bef5, 15251:6f06bd06ef47 and related - low risk but without these ballooning patches, dom0 behaviour can become pathological 15253:ebe4140fe4f8 - this was a nasty little bug 15283:e08cbd487414 - reflect current reality 15671:0c79a9414f8d, 15673:f343d3c16dcc, 15674:07364f8574b8 - nasty random corruption? regards john _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On 3/9/07 20:18, "Daniel P. Berrange" <berrange@redhat.com> wrote:> I''d like to get the PVFB changes to replace libvncserver with QEMU into the > release. I''ll post updated patches ASAP. > > I recently managed to get support for TLS + x509 certificate authentication > merged into upstream QEMU for the VNC server so we have some serious quality > security there. The back-port to QEMU 0.9.0 in Xen should be fairly easy for > me to do, so I''ll hopefully be able submit that in the next week too.Does backporting these to 3.1 make sense given that it uses qemu 0.8.2? -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On Tue, Sep 04, 2007 at 08:12:58AM +0100, Keir Fraser wrote:> On 3/9/07 20:18, "Daniel P. Berrange" <berrange@redhat.com> wrote: > > > I''d like to get the PVFB changes to replace libvncserver with QEMU into the > > release. I''ll post updated patches ASAP. > > > > I recently managed to get support for TLS + x509 certificate authentication > > merged into upstream QEMU for the VNC server so we have some serious quality > > security there. The back-port to QEMU 0.9.0 in Xen should be fairly easy for > > me to do, so I''ll hopefully be able submit that in the next week too. > > Does backporting these to 3.1 make sense given that it uses qemu 0.8.2?I''ve backported them to 3.1 / QEMU 0.8.2 for the Fedora 8, test2 release but it was not exactly pretty. There''ve been a fair few changes to QEMU & its VNC server between 0.8.2 and 0.9.0, plus the various Xen specific patches, so I had to pull in a fair number of other changes first. If there''s interest I can send out the patches against 3.1, but otherwise I''ll just focus on the xen-unstable tree. Regards, Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=| _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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@lists.xensource.com http://lists.xensource.com/xen-devel
Could the haldaemon''s work be pushed into blkback in the kernel? -- Keir On 5/9/07 17:43, "Pat Campbell" <plc@novell.com> 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@lists.xensource.com > http://lists.xensource.com/xen-devel_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On Wed, Sep 05, 2007 at 10:43:30AM -0600, Pat Campbell wrote:> 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.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. Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=| _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
> On Wed, Sep 5, 2007 at 11:39 AM, Keir Fraser <Keir.Fraser@cl.cam.ac.uk> 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@novell.com> 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@lists.xensource.com >> http://lists.xensource.com/xen- devel_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
>>> On Wed, Sep 5, 2007 at 11:56 AM, in message <20070905175633.GI5503@redhat.com>,"Daniel P. Berrange" <berrange@redhat.com> wrote:> On Wed, Sep 05, 2007 at 10:43:30AM - 0600, Pat Campbell wrote: >> 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. > > 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. > > 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. 4 active FV guests, all configured to the same physical CDROM ( 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 able to access the additional info because of the CD size not being changed while any app has the CD device open. Pat _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel