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

[Andrew Lyon <andrew.lyon@xxxxxxxxx>]

On Wed, Mar 11, 2009 at 7:13 PM, Andrew Lyon <andrew.lyon@xxxxxxxxx> wrote:
> 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

I have just managed to get the Xensource 2.6.18.8 kernel working on
one of my test systems and this problem still happens, I updated Xen
unstable to latest hg as well, so this is definitely not a kernel
version problem, after starting and stopping one hvm I cannot start
any more, and xenstore-ls shows that objects are not being cleaned up
properly:

tool = ""
 xenstored = ""
local = ""
 domain = ""
  0 = ""
   vm = "/vm/00000000-0000-0000-0000-000000000000"
   device = ""
   control = ""
    platform-feature-multiprocessor-suspend = "1"
   error = ""
   memory = ""
    target = "3453952"
   cpu = ""
    1 = ""
     availability = "online"
    0 = ""
     availability = "online"
   name = "Domain-0"
   console = ""
    limit = "1048576"
    type = "xenconsoled"
   domid = "0"
   backend = ""
    vfb = ""
     1 = ""
      0 = ""
       hotplug-error = "/etc/xen/scripts/xen-hotplug-cleanup failed;
error detected."
       hotplug-status = "error"
    vbd = ""
     1 = ""
      768 = ""
       domain = "xptest"
       frontend = "/local/domain/1/device/vbd/768"
       uuid = "7f03ff88-17ca-5442-2684-fee0e2d43e98"
       bootable = "1"
       dev = "hda"
       state = "6"
       params = "/root/xp"
       mode = "w"
       online = "0"
       frontend-id = "1"
       type = "file"
       node = "/dev/loop0"
       physical-device = "7:0"
       hotplug-status = "connected"
    vif = ""
     1 = ""
      0 = ""
       domain = "xptest"
       handle = "0"
       uuid = "258a56f7-721d-647b-98c3-b030eb9572de"
       script = "/etc/xen/scripts/vif-bridge"
       state = "6"
       frontend = "/local/domain/1/device/vif/0"
       mac = "00:16:3e:4c:c2:43"
       online = "0"
       frontend-id = "1"
       feature-sg = "1"
       feature-gso-tcpv4 = "1"
       feature-rx-copy = "1"
       feature-rx-flip = "0"
       hotplug-status = "connected"
    console = ""
     1 = ""
   device-model = ""
vm = ""
 00000000-0000-0000-0000-000000000000 = ""
  on_xend_stop = "ignore"
  shadow_memory = "0"
  uuid = "00000000-0000-0000-0000-000000000000"
  on_reboot = "restart"
  image = "(linux (kernel ))"
   ostype = "linux"
   kernel = ""
   cmdline = ""
   ramdisk = ""
  on_poweroff = "destroy"
  bootloader_args = ""
  on_xend_start = "ignore"
  on_crash = "restart"
  xend = ""
   restart_count = "0"
  vcpus = "2"
  vcpu_avail = "3"
  bootloader = ""
  name = "Domain-0"
  memory = "3373"

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