From: PGNet Dev <pgnet.dev@gmail.com>
To: Wei Liu <wei.liu2@citrix.com>
Cc: xen-devel@lists.xen.org
Subject: Re: Xen 4.6 --with-ovmf, on UEFI Dom0 host up/running, but logging repeated "d1v0 Over-allocation for domain" ?
Date: Fri, 18 Mar 2016 09:19:48 -0700 [thread overview]
Message-ID: <5a088a12-a87d-e8f7-b400-3c0ddbef2709@gmail.com> (raw)
In-Reply-To: <20160318160322.GJ28955@citrix.com>
> In Dom0:
>
> xenstore-ls -f /local/domain/$guest_domid
>
> and paste it here.
xl list
Name ID Mem VCPUs State
Time(s)
Domain-0 0 4096 1 r-----
111.3
test-template 1 2049 1 -b----
106.3
xenstore-ls -f /local/domain/1
/local/domain/1/vm = "/vm/7088e288-a0ba-4848-80e6-19a05f1772a2"
/local/domain/1/name = "test-template"
/local/domain/1/cpu = ""
/local/domain/1/cpu/0 = ""
/local/domain/1/cpu/0/availability = "online"
/local/domain/1/memory = ""
/local/domain/1/memory/static-max = "2097152"
/local/domain/1/memory/target = "2080768"
/local/domain/1/memory/videoram = "16384"
/local/domain/1/device = ""
/local/domain/1/device/suspend = ""
/local/domain/1/device/suspend/event-channel = ""
/local/domain/1/device/vbd = ""
/local/domain/1/device/vbd/51712 = ""
/local/domain/1/device/vbd/51712/backend =
"/local/domain/0/backend/vbd/1/51712"
/local/domain/1/device/vbd/51712/backend-id = "0"
/local/domain/1/device/vbd/51712/state = "4"
/local/domain/1/device/vbd/51712/virtual-device = "51712"
/local/domain/1/device/vbd/51712/device-type = "disk"
/local/domain/1/device/vbd/51712/ring-ref = "8"
/local/domain/1/device/vbd/51712/event-channel = "15"
/local/domain/1/device/vbd/51712/protocol = "x86_64-abi"
/local/domain/1/device/vbd/51712/feature-persistent = "1"
/local/domain/1/device/vbd/51776 = ""
/local/domain/1/device/vbd/51776/backend =
"/local/domain/0/backend/vbd/1/51776"
/local/domain/1/device/vbd/51776/backend-id = "0"
/local/domain/1/device/vbd/51776/state = "4"
/local/domain/1/device/vbd/51776/virtual-device = "51776"
/local/domain/1/device/vbd/51776/device-type = "disk"
/local/domain/1/device/vbd/51776/ring-ref = "9"
/local/domain/1/device/vbd/51776/event-channel = "16"
/local/domain/1/device/vbd/51776/protocol = "x86_64-abi"
/local/domain/1/device/vbd/51776/feature-persistent = "1"
/local/domain/1/device/vbd/51792 = ""
/local/domain/1/device/vbd/51792/backend =
"/local/domain/0/backend/vbd/1/51792"
/local/domain/1/device/vbd/51792/backend-id = "0"
/local/domain/1/device/vbd/51792/state = "4"
/local/domain/1/device/vbd/51792/virtual-device = "51792"
/local/domain/1/device/vbd/51792/device-type = "disk"
/local/domain/1/device/vbd/51792/ring-ref = "10"
/local/domain/1/device/vbd/51792/event-channel = "17"
/local/domain/1/device/vbd/51792/protocol = "x86_64-abi"
/local/domain/1/device/vbd/51792/feature-persistent = "1"
/local/domain/1/device/vbd/51808 = ""
/local/domain/1/device/vbd/51808/backend =
"/local/domain/0/backend/vbd/1/51808"
/local/domain/1/device/vbd/51808/backend-id = "0"
/local/domain/1/device/vbd/51808/state = "4"
/local/domain/1/device/vbd/51808/virtual-device = "51808"
/local/domain/1/device/vbd/51808/device-type = "disk"
/local/domain/1/device/vbd/51808/ring-ref = "11"
/local/domain/1/device/vbd/51808/event-channel = "18"
/local/domain/1/device/vbd/51808/protocol = "x86_64-abi"
/local/domain/1/device/vbd/51808/feature-persistent = "1"
/local/domain/1/device/vkbd = ""
/local/domain/1/device/vkbd/0 = ""
/local/domain/1/device/vkbd/0/backend = "/local/domain/0/backend/vkbd/1/0"
/local/domain/1/device/vkbd/0/backend-id = "0"
/local/domain/1/device/vkbd/0/state = "4"
/local/domain/1/device/vkbd/0/request-abs-pointer = "1"
/local/domain/1/device/vkbd/0/page-ref = "253746"
/local/domain/1/device/vkbd/0/page-gref = "1249"
/local/domain/1/device/vkbd/0/event-channel = "22"
/local/domain/1/device/vif = ""
/local/domain/1/device/vif/0 = ""
/local/domain/1/device/vif/0/backend = "/local/domain/0/backend/vif/1/0"
/local/domain/1/device/vif/0/backend-id = "0"
/local/domain/1/device/vif/0/state = "4"
/local/domain/1/device/vif/0/handle = "0"
/local/domain/1/device/vif/0/mac = "00:16:3e:10:00:01"
/local/domain/1/device/vif/0/multi-queue-num-queues = "1"
/local/domain/1/device/vif/0/tx-ring-ref = "768"
/local/domain/1/device/vif/0/rx-ring-ref = "769"
/local/domain/1/device/vif/0/event-channel-tx = "20"
/local/domain/1/device/vif/0/event-channel-rx = "21"
/local/domain/1/device/vif/0/request-rx-copy = "1"
/local/domain/1/device/vif/0/feature-rx-notify = "1"
/local/domain/1/device/vif/0/feature-sg = "1"
/local/domain/1/device/vif/0/feature-gso-tcpv4 = "1"
/local/domain/1/device/vif/0/feature-gso-tcpv6 = "1"
/local/domain/1/device/vif/0/feature-ipv6-csum-offload = "1"
/local/domain/1/control = ""
/local/domain/1/control/shutdown = ""
/local/domain/1/control/platform-feature-multiprocessor-suspend = "1"
/local/domain/1/control/platform-feature-xs_reset_watches = "1"
/local/domain/1/hvmloader = ""
/local/domain/1/hvmloader/bios = "ovmf"
/local/domain/1/hvmloader/allow-memory-relocate = "0"
/local/domain/1/data = ""
/local/domain/1/domid = "1"
/local/domain/1/store = ""
/local/domain/1/store/port = "1"
/local/domain/1/store/ring-ref = "1044476"
/local/domain/1/platform = ""
/local/domain/1/platform/acpi = "1"
/local/domain/1/platform/acpi_s3 = "1"
/local/domain/1/platform/acpi_s4 = "1"
/local/domain/1/console = ""
/local/domain/1/console/backend = "/local/domain/0/backend/console/1/0"
/local/domain/1/console/backend-id = "0"
/local/domain/1/console/limit = "1048576"
/local/domain/1/console/type = "xenconsoled"
/local/domain/1/console/output = "pty"
/local/domain/1/console/tty = "/dev/pts/0"
/local/domain/1/console/port = "2"
/local/domain/1/console/ring-ref = "1044479"
/local/domain/1/console/vnc-listen = "0.0.0.0"
/local/domain/1/console/vnc-port = "5901"
/local/domain/1/image = ""
/local/domain/1/image/device-model-pid = "3405"
/local/domain/1/serial = ""
/local/domain/1/serial/0 = ""
/local/domain/1/serial/0/tty = "/dev/pts/1"
> First observation is that the log message starts with d1v0, which means
> domain 1 vcpu 0, so Dom0 is irrelevant in that case.
ok
> The guest kernel command line looks normal.
>
> You can also verify if your guest is trying to balloon in memory by
> looking at sysfs knobs.
>
> According to Linux kernel documentation, the relevant knobs live under
>
> /sys/devices/system/xen_memory0/*
Here, anyway, at Guest
/sys/devices/system/xen_memory/xen_memory0/*
tree /sys/devices/system/xen_memory/xen_memory0
/sys/devices/system/xen_memory/xen_memory0
├── info
│ ├── current_kb
│ ├── high_kb
│ └── low_kb
├── max_retry_count
├── max_schedule_delay
├── power
│ ├── async
│ ├── autosuspend_delay_ms
│ ├── control
│ ├── runtime_active_kids
│ ├── runtime_active_time
│ ├── runtime_enabled
│ ├── runtime_status
│ ├── runtime_suspended_time
│ └── runtime_usage
├── retry_count
├── schedule_delay
├── subsystem -> ../../../../bus/xen_memory
├── target
├── target_kb
└── uevent
IIUC (?), it's the *_kb that are relevant
find . | grep _kb
./info/current_kb
./info/low_kb
./info/high_kb
./target_kb
cat `find . | grep _kb`
2079272
131064
0
2080768
Comparing to that at the Dom0
cat `find . | grep _kb`
4194304
121064
0
4194304
I note only that at the Guest, (target_kb) > (current_kb).
Fwiw, in my Guest config
...
bios = 'ovmf'
maxmem = 2048
memory = 2048
hap = 1
shadow_memory = 16
...
>>> Do you see the same message repeated when using seabios?
>>
>> Haven't yet checked.
>>
>> Atm, I've only UEFI guests, setup. To test, I'll just have to spin up a
>> non-UEFI guest. A bit later ...
>
> Yes, this would be helpful for identifying the issue.
I'll post back when I have an answer.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
prev parent reply other threads:[~2016-03-18 16:19 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-03-18 15:21 Xen 4.6 --with-ovmf, on UEFI Dom0 host up/running, but logging repeated "d1v0 Over-allocation for domain" ? PGNet Dev
2016-03-18 15:48 ` Wei Liu
2016-03-18 15:55 ` PGNet Dev
2016-03-18 16:03 ` Wei Liu
2016-03-18 16:19 ` PGNet Dev [this message]
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=5a088a12-a87d-e8f7-b400-3c0ddbef2709@gmail.com \
--to=pgnet.dev@gmail.com \
--cc=wei.liu2@citrix.com \
--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.