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

Re: [Xen-devel] Re: [PATCH] xen: mask XSAVE in cpuid since we don't allow guests to use it


  • To: bderzhavets@xxxxxxxxx
  • From: Andrew Lyon <andrew.lyon@xxxxxxxxx>
  • Date: Wed, 11 Mar 2009 19:13:00 +0000
  • Cc: Jeremy Fitzhardinge <jeremy@xxxxxxxx>, Xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxx>, Keir Fraser <keir.fraser@xxxxxxxxxxxxx>
  • Delivery-date: Wed, 11 Mar 2009 12:13:29 -0700
  • Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=IDEGL6w5L5+IkmFfpk7sDMMSkDbmVurXFKNSiYDou/BAJpo3sC9EbeCdpsX2STMi/H NiWtIrtBpTC5daTBHqUMjfm2VlMsFXZQY/KvCX2LaxzO7ff+dmilWTQcTbm+YTvpX7s4 15srse6h8YW3KR6adX3AQwwpTexIuM585CwCk=
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>

On Wed, Mar 11, 2009 at 4:27 PM, Boris Derzhavets <bderzhavets@xxxxxxxxx> wrote:
> It's not so important for me. The important thing is:-
>
> CentOS 5.2 PV DomU may be loaded only the very first time under Suse's
> 2.6.27 xen-ified kernel & Xen Unstable ( the most recent). Attempt to
> shutdown and start it again gives VBD cannot be connected . Hotplug scripts
> not working. That's a core issue, same behavior as under 2.6.29-rc7 (with
> XSAVE patch ). Kernel doesn't seem to be a root cause.
> I believe Xen unstable is broken in some way.
>
> Boris.

This sounds very much like the problem I described in thread subject
"domain id number on xen unstable", I maintain my own 2.6.27 dom0
kernel using opensuse Xen patches which I rebase to apply to vanilla
without the many other patches opensuse usually applies to the kernel
tree, so from a Xen point of view I am using a very similar kernel to
yours, I found that I could start a hvm but after shutting it down
attempting to restart it would fail or hang, sometimes I got hotplug
error that vbd could not be connected.

The script that has problems on my system is xen-hotplug-cleanup , the
first time it is run it puts a lock in /var/run/xen-hotplug and never
removes it, so the next time the script runs it blocks waiting for the
lock and eventually times out.

The offending line in the script is:

vm=$(xenstore-read "/local/domain/${path_array[2]}/vm")

putting a echo immediately after that line shows that nothing after it
is executed, which is why the lock is not released.

replacing xen-hotplug-cleanup and xen-hotplug-common with the ones
from 3.3.1 seems to help, but after starting and stopping a few vm's
the entire system reboots, so I think some objects are not being
cleaned up, not surprising really, can hardly expect scripts to work
with the wrong version of Xen.

This problem has got me stuck into a nasty corner, only Xen unstable
can fit our virtualization requirements (need viridian for stable
windows smp), but the Xensource kernel is too old for our hardware.

I am going to put some serious effort into debugging this in the next few days.

Andy

>
>
>
> --- On Wed, 3/11/09, Jeremy Fitzhardinge <jeremy@xxxxxxxx> wrote:
>
> From: Jeremy Fitzhardinge <jeremy@xxxxxxxx>
> Subject: Re: [Xen-devel] Re: [PATCH] xen: mask XSAVE in cpuid since we don't
> allow guests to use it
> To: bderzhavets@xxxxxxxxx
> Cc: "Xen-devel" <xen-devel@xxxxxxxxxxxxxxxxxxx>, "Keir Fraser"
> <keir.fraser@xxxxxxxxxxxxx>
> Date: Wednesday, March 11, 2009, 12:09 PM
>
> Boris Derzhavets wrote:
>> Blktap helps out for multiple CentOS PV DomU restarts (with image on FS)
> under  Suse's 2.6.27 xen-ified kernel & Xen Unstable ( the most recent).
>> But it seems not implemented yet for 2.6.29-rc7
>>
>
> So your conclusion is that there's a regression in the tools stack when
> using blkback rather than blktab?
>
>    J
>
>
> _______________________________________________
> 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®.