Re: Fwd: Openindiana, using -machine pc, accel=xen in qemu - Success!

[jim burns <jim_burn@bellsouth.net>]

Pls cc: me with any replies.

On Monday, 26 September 2016, 15:27:59 EDT, jim burns wrote:
> Unless you have any other ideas, I'm giving up for now. Thanx for your help.

Things have changed on the Hipster branch of OI, giving me a new environment 
to test.

Mainly, they have ditched legacy grub in favor of a Forth based boot loader. 
Whereas I still cannot boot the grub based install dvds in xen, I can with the 
Forth based vhd. However, things are still in flux. A lot of packages on 
Hipster are changing - mostly the the python packages. Instead of being 
updated, they are being removed, then, if appropriate, treated as a new 
install.

The effect is that the boot process is unreliable. I have to retry the boot 4 
- 10 times before it stops stalling. This is true for both kvm and xen. If I 
had to guess, I'd say that the init software is having trouble bringing up the 
extra vcpus. When you do an 'xl vcpu-list ...' during a boot stall, only vcpu0 
is 'b' or 'r'; the others are 'p'. When I do boot successfully, all vcpus are 
'b' or 'r'. Once booted, the system is reliable.

As such, installing a new OI Hipster system would be a 2 step procedure - use 
kvm to install OI on the vhd, run a complete system update, then convert over 
to xen with the notes below.

One other change I made which may or not be necessary: I noticed that a lot of 
my panic / stack traces involve platform dependant kernel modules that should 
not be loaded in an hvm machine - namely xnf, and sometimes xpvd, which are 
from the para-virtualization path in OI. I uninstalled the package xvm/pv, 
which is used by Solaris' lightweight container virtualization solution - 
Zones, which removes the /platform/i86hvm directory. There is also a /
platform/i86xpv directory which is used by the now unmaintained xen drivers. I 
couldn't remove the package corresponding to that directory without removing 
the non para-virtualization drivers in /platform/i86pc, so I just renamed the 
i86xpv directory. This step has to be done every time you get an update for 
the package kernel/platform. Once things appear more solid, including booting, 
these changes can easily be reversed.

The following guest domain cfg options are different from the cfg I posted 
earlier in this thread:

vcpus=2
memory=3076
boot="cd"
xen_platform_pci=0
#viridian=1
#viridian=0
viridian=[ "all" ]
hap=1
nestedhvm=1
#pvh=1 # causes panic w/stack trace
#hdtype='ahci' # causes panic w/stack trace

The new boot loader has a sub menu for setting kernel options, like verbose. I 
noticed on occasion that the stall occurs after initializing vcpus 0 & 1, with 
vcpus=4, so I reduced the number of vcpus.

I increased memory to match my kvm options.

Instead of booting off grub on the dvd, then chaining to Forth, I eliminated 
any left over initialization problems from grub by booting directly off the 
vhd.

The value of xen_platform_pci can be 0 or 1, with no difference - except, 
curiously enough, the network card generation number changes: e1000g1 for kvm 
and xen_platform_pci=0, e1000g2 otherwise. I would have thought the -netdev 
option would have more effect than the -machine option.

All the viridian options above are equally valid. The default is viridian=1.

Tho' commented out before, hap=1 is the default if your system supports it, as 
my Haswell icore-5 does.

When adding nestedhvm=1, the cpuid option 'vmx' shows up for the first time in 
the boot log.

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