All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrew Cooper <andrew.cooper3@citrix.com>
To: Steven Haigh <netwiz@crc.id.au>
Cc: xen-devel@lists.xen.org
Subject: Re: HVMs terminating as (null)
Date: Sat, 23 Nov 2013 20:26:11 +0000	[thread overview]
Message-ID: <52910F63.4070705@citrix.com> (raw)
In-Reply-To: <52910B7F.6030503@crc.id.au>


[-- Attachment #1.1: Type: text/plain, Size: 3104 bytes --]

On 23/11/13 20:09, Steven Haigh wrote:
> On 24/11/13 07:03, Andrew Cooper wrote:
>> On 23/11/13 19:56, Steven Haigh wrote:
>>> On 24/11/13 06:38, Steven Haigh wrote:
>>>> On 24/11/13 06:27, Olaf Hering wrote:
>>>>> On Sun, Nov 24, Steven Haigh wrote:
>>>>>
>>>>>> Running Xen 4.2.3 with all the current XSA fixes.
>>>>>
>>>>> How exactly did you start the guests?
>>>>
>>>> The DomUs were started with: xl create /etc/xen/<configfile>
>>>>
>>>>> Does 'ps faxu' show qemu processes for the listed domain_ids?
>>>>> What is the 'xenstore-ls -f | sort' output?
>>>>
>>>> I'll have to check this when I manage to reproduce it. So far, I have
>>>> been unable to get a reliable way to reproduce it. I managed to get a
>>>> system to do it every time a HVM DomU was shutdown OR restarted - but
>>>> after a reboot of the Dom0 I can't get it into that state again.
>>>>
>>>> As soon as I can get a system in this state again, I'll leave it to see
>>>> what information I can extract.
>>>
>>> Ha! As always, as soon as I send this, I notice its happened on a Dom0.
>>>
>>> # xl list
>>> Name                                        ID   Mem VCPUs      State
>>> Time(s)
>>> Domain-0                                     0  1579     2     r-----
>>>  2731.3
>>> planner.vm                                   1  1013     1     -b----
>>>   189.3
>>> (null)                                       2     0     1     --psrd
>>>   301.1
>>> tracker.vm                                   3  1013     2     -b----
>>>   834.4
>>>
>>> Attached is the output of:
>>> # xl debug-keys q
>>> # xl dmesg  > xen-dmesg.log
>>> # gzip xen-dmesg.log
>>
>> Ok - from dmesg.
>>
>> (XEN) General information for domain 2:
>> (XEN)     refcnt=1 dying=2 pause_count=2
>> (XEN)     nr_pages=2 xenheap_pages=0 shared_pages=0 paged_pages=0
>> dirty_cpus={} max_pages=262400
>> (XEN)     handle=ef58ef1a-784d-4e59-8079-42bdee87f219 vm_assist=00000000
>> (XEN)     paging assistance: hap refcounts translate external
>> ...
>> (XEN) Memory pages belonging to domain 2:
>> (XEN)     DomPage 00000000000866e0: caf=00000001, taf=0000000000000000
>> (XEN)     DomPage 00000000000866e1: caf=00000001, taf=0000000000000000
>> (XEN)     PoD entries=0 cachesize=0
>>
>>
>> So there are indeed two outstanding pages causing this domain to become
>> a zombie.  They are normal pages, with 1 outstanding ref.
>>
>> Can you collect "xl debug-keys g" as well?
>
> Sure - attached.

(XEN)       -------- active --------       -------- shared --------
(XEN) [ref] localdom mfn      pin          localdom gmfn     flags
(XEN) grant-table for remote domain:    2 (v1)
(XEN) [16302]        0 0x0866e1 0x00000001          0 0x0064e1 0x19
(XEN) [16320]        0 0x0866e0 0x00000001          0 0x0064e0 0x19

Ok - so domain 2 has two outstanding grants.  This explains why it is a
zombie.

Both these grants are GFT_writing | GFT_reading | GFT_permit_access, but
seemingly unmapped.

I will have to defer to someone who knows the grant code better.  Is it
possible for a domain to be a zombie just because it has two grants it
hasn't manually invalidated?

~Andrew


[-- Attachment #1.2: Type: text/html, Size: 6441 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

  reply	other threads:[~2013-11-23 20:26 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-11-23 16:14 HVMs terminating as (null) Steven Haigh
2013-11-23 16:18 ` Andrew Cooper
2013-11-23 16:38   ` Sander Eikelenboom
2013-11-25 10:36     ` Ian Campbell
2013-11-25 10:47       ` Steven Haigh
2013-11-25 10:50       ` Sander Eikelenboom
2013-11-25 10:56         ` Steven Haigh
2013-11-25 11:02           ` Ian Campbell
2013-11-25 11:02           ` Andrew Cooper
2013-11-25 11:08         ` Ian Campbell
2013-11-23 19:27 ` Olaf Hering
2013-11-23 19:38   ` Steven Haigh
2013-11-23 19:56     ` Steven Haigh
2013-11-23 20:03       ` Andrew Cooper
2013-11-23 20:09         ` Steven Haigh
2013-11-23 20:26           ` Andrew Cooper [this message]
2013-11-24 17:14             ` Wei Liu
2013-11-25  1:19               ` Steven Haigh
2013-11-25 11:07                 ` Wei Liu

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=52910F63.4070705@citrix.com \
    --to=andrew.cooper3@citrix.com \
    --cc=netwiz@crc.id.au \
    --cc=xen-devel@lists.xen.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.