On 7/28/17 9:02 AM, PGNet Dev wrote:
On 7/27/17 11:23 PM, Juergen Gross wrote:
Can you please post the domain's config file used to create the domain
and the kernel config?
Sure.
https://pastebin.com/M6cr2pX7
Any add'l info needed?
_
On 7/27/17 11:23 PM, Juergen Gross wrote:
Can you please post the domain's config file used to create the domain
and the kernel config?
Sure.
https://pastebin.com/M6cr2pX7
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/x
I've upgraded a Xen server's
xen-4.9.0_08-517.2.x86_64
xen-libs-4.9.0_08-517.2.x86_64
kernel from 4.12x to 4.13x
uname -rm
4.13.0-rc2-2.gb545b87-default x86_64
After upgrading, I see in my Dom0-attached serial console, a steady stream of,
...
Daniel
On 7/5/17 3:02 PM, Daniel Kiper wrote:
-- wait for in-the-pipeline @kernel fixes to simply propagate
Or backport 6c64447 (x86/xen/efi: Initialize only the EFI struct members
used by Xen) and 457ea3f (efi: Process the MEMATTR table only if EFI_MEMMAP is
enabled). Latter is an extra fix i
On 7/5/17 12:58 AM, Jan Beulich wrote:
So there are two problems here: One is the fact that the kernel
really should put an Invalid Opcode exception handler in place
before intentionally raising any such exceptions (which WARN()
and WARN_ON() do). The other is that Linux commit 636259880a
("efi:
Hi
On 7/4/17 12:54 PM, Andrew Cooper wrote:
> On 04/07/17 20:48, PGNet Dev wrote:
>> [0.00] NX (Execute Disable) protection: active
>> [0.00] efi: EFI v2.31 by American Megatrends
>> [0.00] efi: ESRT=0x9ef8d998 ACPI 2.0=0x9e819000
> As a general remark, I think such issues should rather be brought up on
> xen-devel.
upgrading a working Xen server to
kernel 4.12.0-2.gb8e7496-default
Xen 4.9.0_08-512
now, boot crashes @
domain_crash_sync called from entry.S: fault at 82d080342328
entry.o#creat
On 5/30/17 12:29 AM, Roger Pau Monné wrote:
...
> dom0=pvh is what should be used once it's finished. Right now there's
> no PVHv2 Dom0 support in Linux, and the Xen side is not finished. If
> you manage to get this booting, you are going to hit a panic in Xen
> code [0].
...> I think builder='linu
On 5/29/17 10:03 AM, Roger Pau Monné wrote:
>> IIUC, Xen 4.9 + kernel-default > v4.11 should now fully support PVHv2?
>
> For DomUs yes, for Dom0 not yet.
thx
> Forget about this document, I should have removed it as part of the
> PVHv1 code removal. In any case, those where PVHv1 internal detai
Starting with
Xen Changes For Linux 4.11: Lands PVHv2 Guest Support
https://www.phoronix.com/scan.php?page=news_item&px=Linux-4.11-Xen-Changes
[GIT PULL] xen: features and fixes for 4.11-rc0
http://lkml.iu.edu/hypermail/linux/kernel/1702.2/03209.html
IIUC, Xen 4.
Working with Xen 4.9.0 host on kernel 4.11.3
dmesg | egrep -i "linux version|xen version"
[0.00] Linux version 4.11.3-2.g7262353-default
(geeko@buildhost) (gcc version 7.1.1 20170517 [gcc-7-branch revision 248152]
(SUSE Linux) ) #1 SMP PREEMPT Thu May 25 17:55:04
(apologies re: the empty 'double tap' :-/ )
On 5/14/17 8:39 AM, Andrew Cooper wrote:
>> So I'm still unclear -- is this^ now, correctly "all" using MSI/HPET?
>
> What are you trying to achieve? It is still not clear despite all on
> this thread.
>
> The Linux HEPT error messages are non-ideal,
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
On 5/13/17 3:15 PM, Valentin Vidic wrote:
> Try booting without 'hpet=force,verbose clocksource=hpet' and it should
> select xen by default:
Nope. Well, not quite ...
With both
'hpet=force,verbose clocksource=hpet'
removed, I end up with
cat /sys/devices/system/clocksource/clo
On 5/13/17 2:32 PM, Valentin Vidic wrote:
> On Sat, May 13, 2017 at 02:06:28PM -0700, PGNet Dev wrote:
>> xl dmesg | grep -i hpet | grep -vi command
>> [1.365876] hpet_acpi_add: no address or irqs in _CRS
>> [1.365876] hpet_acpi_add: no address or irqs in _CRS
&
On 5/13/17 1:16 PM, Andrew Cooper wrote:
We don't have code like that in upstream Xen. No function with that
name, or a string which looks like that error message.
noted
http://marc.info/?l=linux-kernel&m=149464267427111&w=2 indicates that
you are using a SuSE hypervisor.
yes, that's corre
On 5/13/17 1:28 PM, Valentin Vidic wrote:
On Sat, May 13, 2017 at 01:05:22PM -0700, PGNet Dev wrote:
back to the error at hand ...
xl dmesg | grep -i hpet
[1.365876] hpet_acpi_add: no address or irqs in _CRS
[1.365876] hpet_acpi_add: no address or irqs in _CRS
again, only
On 5/13/17 12:59 PM, Andrew Cooper wrote:
Ok. Lack of a clocksource is to be expected.
The reason why the HPETs are unavailable is that dom0 is not a position
to program them; dom0 doesn't know what Xen has set up in the IDT.
Use `xl dmesg` to get to the hypervisor dmesg log. You should see
m
On 5/13/17 12:38 PM, Andrew Cooper wrote:
> What is the issue here?
>
> Xen owns (and may use) any HPETs in the system. They are purposefully
> unavailable to even dom0.
The issue is that, when booting to Xen, hpet is not advertised as an available
clocksource, AND reports the hpet boot error p
Reading @
How to know if the balloon driver is running
http://www.gossamer-threads.com/lists/xen/users/315064#315064
"...
IIRC the core balloon driver is always present when Xen is enabled and
so the kernel will respond to requests from the host/toolstack to change
On 07/04/2016 04:22 AM, George Dunlap wrote:
Thanks for your persistence. :-)
I appreciate the reply :-)
It's likely that this is related to a known problem with the interface
between the balloon driver and the toolstack. The warning itself is
benign: it simply means that the balloon driver
In summary, there's a problem
An indication of the guest trying to allocate more memory that the host
admin has allowed.
that's filling logs with 10s of thousands of redundant log entries, with
a suspicion that it's 'ballooning' issue in the guest
Perhaps something wrong in the gue
On 06/29/2016 07:17 AM, Jan Beulich wrote:
I don't think a guest would itself issue any relevant messages.
You mentioned ballooning in the guest. The doc I found addressed
ballooning, in the guest.
If not that, then what output, with specificity, would be helpful in
troubleshooting this ?
fyi, per
Verify Xen Project PVHVM drivers are working in the Linux HVM guest
kernel
http://wiki.xen.org/wiki/Xen_Linux_PV_on_HVM_drivers
"Run "dmesg | egrep -i 'xen|front'" in the HVM guest VM."
with Guest cmd line,
... systemd.log_level=debug systemd.log_target=
On 06/29/2016 03:07 AM, Jan Beulich wrote:
What are these 'Over-allocation' messages?
An indication of the guest trying to allocate more memory that the
host admin has allowed.
currently, each guest has allocated
maxmem = 2048
memory = 2048
What needs to be fixed, or if of no concern,
(relo'd from user list)
I've launched an Ubuntu PVHVM guest, on a Xen 4.7 host
cat guest1.cfg
name = 'guest1'
builder = 'hvm'
xen_platform_pci = 1
device_model_version = 'qemu-xen'
bios = 'ovmf'
On UEFI Dom0 with
xl info | egrep "release|version"
release: 4.5.0-2.gb2c9ae5-default
version: #1 SMP PREEMPT Wed Mar 16 17:30:21 UTC 2016
(b2c9ae5)
xen_version: 4.620160318T070646
with Xen built with ovmf en
On 03/18/2016 08:48 AM, Wei Liu wrote:> The log message isn't
necessarily indication for a bug.
OVMF is huge, so it pushes up total memory consumption of the guest. It
is normal that you see that message when using OVMF during boot time.
What is unclear to me is why your guest keeps trying to
In Dom0:
xenstore-ls -f /local/domain/$guest_domid
and paste it here.
xl list
NameID Mem VCPUs State
Time(s)
Domain-0 0 4096 1 r-
111.3
test-template1 2049
On Mon, Feb 1, 2016 at 11:58 AM, Boris Ostrovsky
Current PVH implementation has never been described as
production-ready. What is happening now with HVMlite is
essentially bringing PVH to production-quality level.
So should I s/PVH/HVMlite/g?
From user perspective that will be alm
Here http://wiki.xenproject.org/wiki/Xen_EFI#Xen_as_gz_binary refers to
original discussion in 2013 (work has been deferred to Xen 4.6. )
and says "work has been deferred to Xen 4.6."
I think that this should be Xen 4.8 target.
That's roughly another year+ from now for EFI support?
Per, htt
I launch Xen on EFI currently via chainload in Grub2.
While troubleshooting other issue, it's , at best, quite inconvenient.
I understand multiboot2 support is in the works.
The latest status I've found on multiboot2 support in Xen is
http://lists.gnu.org/archive/html/grub-devel/2015-07/msg
On 02/02/2016 07:51 AM, Jan Beulich wrote:
So would you please confirm that this indeed fixes your issue?
I'm hesitant to put it in without confirmation, and it's likely too
late for 4.6.1 now anyway (so would then only appear in 4.6.2).
I don't build Xen. I use packages provided by Opensuse d
On 02/01/2016 11:14 AM, Boris Ostrovsky wrote:
Is 'HVMLite' replacing 'PVH'? Or are they separate modes?
Yes, HVMlite is replacing PVH. Probably once we get dom0 support.
If that's a 'done deal', and it sounds like it is, it'd be useful to
have it integrated into:
http://wiki.xen.org/wik
On 02/01/2016 06:11 AM, Boris Ostrovsky wrote:
This actually never happened for Linux: HVMlite showed up fast enough
that it didn't make sense anymore to add 32-bit support to Linux
(especially given that AMD was still not supported).
Is 'HVMLite' replacing 'PVH'? Or are they separate modes?
_
I'll get the dom0pvh issue logs posted.
http://xenbits.xen.org/docs/unstable/misc/pvh-readme.txt
" ...
To boot 64bit dom0 in PVH mode, add dom0pvh to grub xen command line.
..."
http://xenbits.xen.org/gitweb/?p=xen.git;a=blob;f=docs/misc/pvh.markdown
no mention
On 02/01/2016 04:29 AM, Roger Pau Monné wrote:
http://xenbits.xen.org/gitweb/?p=xen.git;a=blob;f=docs/misc/pvh.markdown
That's all sorted now, thanks.
I'll get the dom0pvh issue logs posted.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://
On 02/01/2016 02:28 AM, Roger Pau Monné wrote:
Do any of these^^ params need to also change with the addition of
pvh = 1
Yes, you need to remove builder, xen_platform_pci and
device_model_version, and add a kernel and ramdisk parameters that point
to the actual kernel and ramdisk tha
On 02/01/2016 01:59 AM, Wei Liu wrote:
(Cc Roger)
On Sun, Jan 31, 2016 at 01:27:23PM -0800, PGNet Dev wrote:
I run Xen 4.6 Dom0
rpm -qa | egrep -i "kernel-default-4|xen-4"
kernel-default-devel-4.4.0-8.1.g9f68b90.x86_64
xen-4.6.0_08-405.1.
On 02/01/2016 02:30 AM, Roger Pau Monné wrote:
Does your kernel support PVH mode (ie: CONFIG_PVH enabled?)
not CONFIG_PVH, but per http://wiki.xenproject.org/wiki/Linux_PVH
egrep \
"CONFIG_HYPERVISOR_GUEST=|CONFIG_PARAVIRT=|CONFIG_PARAVIRT_GUEST=|CONFIG_PARAVIRT_SPINLOCKS=|CONFIG_XEN=|CONFIG_
In any case, the !st issue, prior to any guest being launched, simply adding
@ GRUBG cfg
-GRUB_CMDLINE_XEN=" ..."
+GRUB_CMDLINE_XEN=" dom0pvh ..."
causes boot fail,
...
(XEN) [2016-01-31 19:28:09] d0v0 EPT violation 0x1aa (-w-/r-x) gpa
0x00f100054c mfn 0xf15
(XEN) [2016-01-31 1
I run Xen 4.6 Dom0
rpm -qa | egrep -i "kernel-default-4|xen-4"
kernel-default-devel-4.4.0-8.1.g9f68b90.x86_64
xen-4.6.0_08-405.1.x86_64
My guests are currently HVM in PVHVM mode; I'm exploring PVH.
IIUC, for 4.6, this doc
http://xenbits.xen.org/d
On 12/07/2015 06:20 AM, Konrad Rzeszutek Wilk wrote:
However I am wondering - why are you using '/mapbs' ? What did it
help? (The combination of 'efi=no-rs' means you are in effect not
using _any_ EFI operations - so doing /mapbs is not needed).
I used /mapbs because it was suggested in #irc by
On 12/05/2015 11:44 AM, Konrad Rzeszutek Wilk wrote:
Two issues exist with the SuperMicro EFI
(1) firmware EFI mis-mapping causing Xen PANIC on restart
Can you try 'reboot=acpi' ?
...
I.e., what combination of
/mapbs
efi=no-rs
reboot=acpi
All? It should be on the Xen command line
On 12/05/2015 10:05 AM, Konrad Rzeszutek Wilk wrote:
Two issues exist with the SuperMicro EFI
(1) firmware EFI mis-mapping causing Xen PANIC on restart
Can you try 'reboot=acpi' ?
Instead of, or in addition to, efi=no-rs?
I.e., what combination of
/mapbs
efi=no-rs
reboot=acpi
I run Xen 4.6 Dom0 on an Opensuse Leap 42.1 server.
Hardware is a SuperMicro X10SAT motherboard
(http://www.supermicro.com/products/motherboard/Xeon/C220/X10SAT.cfm),
with AMI v3 BIOS + "UEFI support"
Two issues exist with the SuperMicro EFI
(1) firmware EFI mis-mapping causing Xen P
On 10/30/2015 11:23 AM, Daniel Kiper wrote:
I missed that you are talking about PE executable. However,
as it was said you must create xen.cfg in advance and put it in the same
directory with xen.efi. Please check xen/docs/misc/efi.markdown for more
details.
TBH I'm not clear on whether the ex
On 10/30/2015 10:29 AM, Daniel Kiper wrote:
Will the aforementioned goals enable direct boot using systemd-boot
on EFI platforms ? Or is it possible even now?
If it supports multiboot2 with my extensions then it should work.
However, I do not think it is true because all is in development
stat
Re:
> The final goal is xen.efi binary file which could be loaded by EFI
> loader, multiboot (v1) protocol (only on legacy BIOS platforms) and
> multiboot2 protocol. This way we will have:
> - smaller Xen code base,
> - one code base for xen.gz and xen.
49 matches
Mail list logo
