Re: [PROMOTIONAL]FreeBSD 14-CURRENT as a guest working?

[Marcin Cieslak]

On Fri, 7 May 2021, Roger Pau Monné wrote:


On Fri, May 07, 2021 at 05:12:16AM +, Marcin Cieslak wrote:

I have put FreeBSD-14.0-CURRENT-amd64-20210422-df456a1fcf7-246266.raw.xz
on an zvol and tried booting it like this:


(..)



it starts to boot but subsequently crashes with various messages related to 
network front drivers.


The following commit solves the issue in the domU:

https://cgit.freebsd.org/src/commit/?id=5d8fd932e418f03e98b3469c4088a36f0ef34ffe

I don't think there's any snapshot image with this yet.


Thank you. I plan to start building -current there so I can try to build from 
source.


I tried to collect some info but now an attempt to start it seems to bog down 
my Xen host :(
(it responds to TCP connections but SSH connections are frozen and I can't open 
new ones)


Hm, that's weird. Do you have a serial attached to the box to know
what's going on?


Unfortunately, no. I could only hit big red button via my hosting provide "Hardware 
reset" console :(
They only offer KVM when I ask for it and there is no serial console option :(

Marcin

smime.p7s
Description: S/MIME Cryptographic Signature

Name resolution from host to domUs?

[Marcin Cieslak]

This is more a question about best practice people are using...

I run Xen mainly to start a myriad of various operating systems
in my lab (Linux variants, Solaris, BSDs, Windows...).
domUs have usually zvol's allocated to them.

I assign the IPv4 addresses via a local DHCP server, all domUs have access
to two bridge interfaces (one for IPv4 with NAT, one for IPv6).

Currently I add all domU IPv4 addresses to /etc/hosts file, being
too lazy to maintain a DNS zone.

Is there any way to nicely have name-to-IP name resolution working
without doing things like DHCP+dynamic DNS on every machine?

How to find out easily the IPv4 addresses assigned to the domUs?
I understand that Xen only bridges Ethernet frames and has no
clue really what happens above that?

Marcin

smime.p7s
Description: S/MIME Cryptographic Signature

FreeBSD 14-CURRENT as a guest working?

[Marcin Cieslak]

I have put FreeBSD-14.0-CURRENT-amd64-20210422-df456a1fcf7-246266.raw.xz
on an zvol and tried booting it like this:

builder = "hvm"
name = "current0"
disk = [
'/dev/zvol/zroot/current0,raw,xvda,w'
]
boot = "c"
bios = "ovmf"
usbdevice = 'tablet'
#nographics = 1
serial = [ "/dev/nmdm0A" ]
vnc = 1
#vnclisten = '0.0.0.0'
vif = 
['bridge=bridge0,mac=00:02:04:15:fd:e1','bridge=bridge1,mac=00:02:04:15:fd:e2']
memory=8192
vcpus=6
vga = "stdvga"
videoram = 16
;xen_platform_pci=1

it starts to boot but subsequently crashes with various messages related to 
network front drivers.

I tried to collect some info but now an attempt to start it seems to bog down 
my Xen host :(
(it responds to TCP connections but SSH connections are frozen and I can't open 
new ones)

Host is FreeBSD 12.2-STABLE r369477 GENERIC

(XEN) Xen version 4.14.1 (root@) (FreeBSD clang version 10.0.1 
(g...@github.com:llvm/llvm-project.git llvmorg-10.0.1-0-gef32c611aa2)) debug=n  
Thu Mar 18 13:45:35 UTC 2021

Marcin

smime.p7s
Description: S/MIME Cryptographic Signature

Re: 12.2-STABLE r369477 dom0 creash on xen-kernel-4.14.1_1

[Marcin Cieslak]

On Sat, 20 Mar 2021, Roger Pau Monné wrote:


On Fri, Mar 19, 2021 at 11:59:49PM +, Marcin Cieslak wrote:

Unfortunately it crashes as Xen dom0 with xen-kernel-4.14.1_1


Do you have dom0=pvh set on the Xen command line? Note 4.7 used
dom0pvh=1 instead [0], so you will have to modify your loader.conf.


Thank you - that was it!


[0] 
https://docs.freebsd.org/en_US.ISO8859-1/books/handbook/virtualization-host-xen.html


I read this article but this difference escaped my attention.
I have only removed "hw.pci.mcfg=0".

Now it works fine again, big thanks for keeping Xen so well supported on 
FreeBSD!

Marcin


smime.p7s
Description: S/MIME Cryptographic Signature

12.2-STABLE r369477 dom0 creash on xen-kernel-4.14.1_1

[Marcin Cieslak]

Hello,

I have just upgrade my machine that used to ran 11.x with Xen 4.7.2_9
as dom0 for a long time.

After upgrade to 12.2-STABLE r369477, runs GENERIC kernel just fine.

Unfortunately it crashes as Xen dom0 with xen-kernel-4.14.1_1

World, kernel and Xen were built from source.

FreeBSD 12.2-STABLE r369477 GENERIC amd64
FreeBSD clang version 10.0.1 (g...@github.com:llvm/llvm-project.git 
llvmorg-10.0.1-0-gef32c611aa2)
VT(vga): resolution 640x480
CPU: Intel(R) Xeon(R) CPU E31245 @ 3.30GHz (3300.09-MHz K8-class CPU)
  Origin="GenuineIntel"  Id=0x206a7  Family=0x6  Model=0x2a  Stepping=7
  
Features=0xbfebfbff
  
Features2=0x1fbae3ff
  AMD Features=0x28100800
  AMD Features2=0x1
  Structured Extended Features3=0x9c000400
  XSAVE Features=0x1
  VT-x: PAT,HLT,MTF,PAUSE,EPT,UG,VPID
  TSC: P-state invariant, performance statistics

The main board is ASUSTek P8B WS.

According to to xen-syms.map:

0x82d0402fe9b9 t x86_64/entry.S#create_bounce_frame

0x82d0402feaee <-- rip


Marcin

dom0crash.png
Description: Binary data


smime.p7s
Description: S/MIME Cryptographic Signature

Re: cannot install FreeBSD 12.0 Xen 4.12.1 on Intel Core i7 CPU 930

[Marcin Cieslak]

On Wed, 16 Oct 2019, Stefan Parvu wrote:



Does it happen in Xen or in FreeBSD dom0 kernel?


Xen. Here:
http://www.kronometrix.org/bugs/freebsd_xen.jpg


I have Xeon E3-1234 but I run 11.2-STABLE with xen-kernel-4.7.2_9 for a very 
long time already.
I also have:

hw.pci.mcfg=0
machdep.hyperthreading_allowed=0


Should I add these to sysctl.conf ? I will try tomorrow. To me it looks 
whatever I try I cannot
get IOMMU on this hdw with FreeBSD 12 and Xen 4.12.1. I havent tried another 
FreeBSD version.


No idea, just showing what I have. Maybe totally not relevant to what you are 
having -
I am going to try 12 and Xen 4.12.1 soon.

I also don't have "iommu=required,force" in my Xen commandline:

"dom0_mem=4096M dom0_max_vcpus=1 dom0pvh=1 com1=115200,8n1 guest_loglvl=all 
loglvl=all vga=text-80x43,keep console=vga"

smime.p7s
Description: S/MIME Cryptographic Signature

Re: cannot install FreeBSD 12.0 Xen 4.12.1 on Intel Core i7 CPU 930

[Marcin Cieslak]

On Wed, 16 Oct 2019, Stefan Parvu wrote:


Hi,

I have a bit of problem, cannot install FreeBSD/Xen on a bit older hardware. 
The hardware
should support the minimal VT-D/IOMMU settings, required by Xen.

CPU: Intel(R) Core(TM) i7 CPU 930  @ 2.80GHz (2806.42-MHz K8-class CPU)
 Origin="GenuineIntel"  Id=0x106a5  Family=0x6  Model=0x1a  Stepping=5
 
Features=0xbfebfbff
 
Features2=0x98e3bd
 AMD Features=0x28100800
 AMD Features2=0x1
 VT-x: PAT,HLT,MTF,PAUSE,EPT,VPID
 TSC: P-state invariant, performance statistics

I get always a panic on CPU0 followed by a reboot. My /boot/loader.conf was set 
as:

xen_cmdline="dom0_mem=2048M dom0_max_vcpus=4 dom0=pvh console=com1,vga 
com1=115200,8n1 guest_loglvl=all loglvl=all iommu=debug,force”


Does it happen in Xen or in FreeBSD dom0 kernel?

I have Xeon E3-1234 but I run 11.2-STABLE with xen-kernel-4.7.2_9 for a very 
long time already.
I also have:

hw.pci.mcfg=0
machdep.hyperthreading_allowed=0

Marcin

smime.p7s
Description: S/MIME Cryptographic Signature

Re: Issue getting my first Xen domU up

[Marcin Cieslak]

On Tue, 5 Feb 2019, Eric Bautsch wrote:

> And yes, the qemu-dm-titania.log would have been the place to look. I feel
> pretty stupid. It says:

Don't feel stupid. I am using Xen with Dom0 on FreeBSD for months now
and I didn't know where the qemu logs go - I was able to figure out
the problem by staring at the configuration file for a long time.

Therefore your question was very helpful also for me - thanks!

Marcin

smime.p7s
Description: S/MIME Cryptographic Signature

Re: HEADS UP: merged PVHv2 support and future plans

[Marcin Cieslak]

On Thu, 19 Jul 2018, Roger Pau Monné wrote:

> On Thu, Jul 19, 2018 at 12:46:07PM +0000, Marcin Cieslak wrote:
> > On Thu, 19 Jul 2018, Roger Pau Monné wrote:
> > 
> > > Hello,
> > > 
> > > Today I've merged PVHv2 support into FreeBSD, allowing FreeBSD to be
> > > used as a PVHv2 DomU and Dom0. While it's not a huge set of changes,
> > > I would *really* appreciate if people could test the code starting
> > > from r336474 (or any later changeset).
> > 
> > Hi Roger, I am ready to test it on my (small) setup, should I keep
> > existing 4.7 running as is and just upgrade the Dom0? 
> 
> Yes, just update the FreeBSD kernel.

I can at least confirm that my box boot cleanly after the update.
Haven't tried launching any domUs yet.

Marcin

smime.p7s
Description: S/MIME Cryptographic Signature

Re: HEADS UP: merged PVHv2 support and future plans

[Marcin Cieslak]

On Thu, 19 Jul 2018, Roger Pau Monné wrote:

> Hello,
> 
> Today I've merged PVHv2 support into FreeBSD, allowing FreeBSD to be
> used as a PVHv2 DomU and Dom0. While it's not a huge set of changes,
> I would *really* appreciate if people could test the code starting
> from r336474 (or any later changeset).

Hi Roger, I am ready to test it on my (small) setup, should I keep
existing 4.7 running as is and just upgrade the Dom0? 

Or should I upgrade Xen too?

Marcin

smime.p7s
Description: S/MIME Cryptographic Signature

Re: Is it possible to run Xen in a VirtualBox VM?

[Marcin Cieslak]

On Tue, 15 May 2018, Pratyush Yadav wrote:

> On Mon, May 14, 2018 at 11:25 PM, Roger Pau Monné  
> wrote:
> > Yes, I think you will need to be able to run Xen + FreeBSD. You can
> > probably manage to complete the first part using Xen + Linux and
> > running FreeBSD as a guest, but you will need Xen + FreeBSD Dom0 for
> > the second part (adding handlers for mapping operations used by the
> > backend).
> 
> One more thing, is there any other VM like VirtualBox that can run Xen
> + FreeBSD as Dom0, or do I have to run it on a different computer.

I have solved this problem for me by renting a physical server at the hosting 
company.
But serious hacking requires having access to the physical console (most
hosting providers provide something like that).

I don't know how others are working on this? Anyone running Xen on their laptop 
for example?

Marcin

smime.p7s
Description: S/MIME Cryptographic Signature

Re: Linux domU only works with xen_platform_pci=0 ?

[Marcin Cieslak]

On Sun, 13 May 2018, Kai Otto wrote:

> Hello,
> 
> Linux only detected the harddisk with xen_platform_pci=0.
> 
> For Alpine Linux, with xen_platform_pci=1, I get the following messages
> on the console:
> 
> vbd vbd-5632: 19 xenbus_dev_probe on device/vbd/5632
> vbd vbd-5632: failed to write error node for device/vbd/5632 (19
> xenbus_dev_probe on device/vbd/5632)

I have reported this here, too:

https://lists.freebsd.org/pipermail/freebsd-xen/2017-August/003079.html

I think it is needed for some newer Linux kernels only.

I am successfully using Windows, Solaris and some other wierd HVM
guests without this option successfully. xen_platform_pci=1
seems to confuse Linux 4.* line (2.6.32 boots fine).

Marcin

smime.p7s
Description: S/MIME Cryptographic Signature

Re: Fwd: FreeBSD 11.1 xen trying to create linux domU instance

[Marcin Cieslak]

On Mon, 21 Aug 2017, James E. Pace wrote:

> zfs create -V20G -o volmode=dev pool/xen-ubuntu

This is correct.

> disk = [
> '/dev/zvol/pool/xen-ubuntu,,hda,rw',
> '/pool/Downloads/ubuntu-15.10-desktop-amd64.iso,raw,hdc:cdrom,r'
> ]

Can you try adding "raw" between commas?

http://xenbits.xen.org/docs/unstable/man/xl-disk-configuration.5.html

says "raw" is the default, though, so it shouldn't matter.

Here is my complete configuration file, sans some comments:

builder = "hvm"
name = "fedora"
disk = [
'/dev/zvol/zroot/fedora0,raw,xvda,w'
#   '/root/xen/Fedora-Server-netinst-x86_64-25-1.3.iso,raw,hdc:cdrom,r'
]
boot = "c"
bios = "ovmf"
usbdevice = 'tablet'
vnc = 1
vif = ['bridge=bridge1,mac=00:02:04:08:99:f0']
memory=2048
vcpus=2
vga = "stdvga"
videoram = 16
xen_platform_pci=0
]

As you can see I am using OVMF for booting (this currently requires
modification to the port's Makefile and recompiling, see the
archives), but I think this shouldn't matter to that type of error
you are having.

This works very well with zvols. There should be no need to
create image files. (I am using zvols for FreeBSD, fedora, RHEL
and Solaris 11.3 guests).

Marcin

smime.p7s
Description: S/MIME Cryptographic Signature

Re: Fwd: FreeBSD 11.1 xen trying to create linux domU instance

[Marcin Cieslak]

On Mon, 21 Aug 2017, James E. Pace wrote:

> Hi,
> 
> builder = "hvm"
> name = "xen-ubuntu"
> memory = 1024
> vcpus = 1
> vif = [ 'bridge=bridge0' ]
> disk = [
> '/dev/zvol/pool/xen-ubuntu,,hda,rw',
> '/pool/Downloads/ubuntu-15.10-desktop-amd64.iso,raw,hdc:cdrom,r'
> ]
> vnc = 1
> vnclisten = "0.0.0.0"
> serial = "pty"
> 
> I created the backing filesystem with:
> zfs create -V20G -o volmode=dev pool/xen-ubuntu
> 
> "xl create foo.cfg" returns fine, and "xl list" shows the instance, but the
> running instance (via vncviewer) eventually spits out:
> 
> 4.130084] vbd vbd-5632: 19 xenbus_dev_probe on device/vbd/5632
> 4.130956] vbd vbd-5632: failed to write error node for device
> device/vbd/5632 (19 xenbus_dev_probe on device/vbd/5632)
> 
> I suspect the linux kernel isn't booting because it can't figure out
> something about the zfs volume.  But I'm not sure, and I don't know how to
> work around it.

I'am using 11.1-STABLE (r321629) as Xen dom0, running under
Xen kernel 4.7.2_3.

I have sucessfully started appliances built on oldish RedHat kernels
(2.6.32-573.18.1.el6.x86_64) without any problems. 
For Fedora 25 (4.10.8-200.fc25.x86_64) I had to add

xen_platform_pci=0

to the config file to get it running.
This still seems to be needed.

My disk definition for fedora and the RedHats
looks like this:

'/dev/zvol/zroot/fedora0,raw,hda,w'

(xvda seems to work well in place of "hda" for RHEL and Fedora
as well)

Marcin



smime.p7s
Description: S/MIME Cryptographic Signature

Re: g_dev_taste: make_dev_p() failed (gp->name=ada1, error=17) - ok?

[Marcin Cieslak]

On Mon, 19 Jun 2017, Roger Pau Monné wrote:

> On Mon, Jun 05, 2017 at 01:42:23AM +0000, Marcin Cieslak wrote:
> > When starting FreeBSD domU (r319534) on 11.1-PRELEASE dom0 (same version)
> > I am guestting
> > 
> > can't re-use a leaf (led)!
> > 
> > and
> > 
> > g_dev_taste: make_dev_p() failed (gp->name=ada0, error=17)
> > 
> > messages in my dmesg.
> > 
> > The disks are attached as follows:
> > 
> > disk = [
> > '/dev/zvol/zroot/freebsd1,raw,hda,w',
> > '/dev/zvol/zroot/freebsd2,raw,hdb,w',
> > '/dev/zvol/zroot/builder0,raw,hdc,w',
> > '/dev/zvol/zroot/builder1,raw,hdd,w'
> > ]
> > 
> > are those warning messages ok?
> > 
> > dmesg output below,
> > 
> > Marcin
> > 
> > xbd1: 40960MB  at device/vbd/832 on xenbusb_front0
> > ada0 at ata0 bus 0 scbus0 target 0 lun 0
> > xbd1: ada0: attaching as ada1
> > xbd1:  ATA-7 device
> > ada0: Serial Number QM1
> > features: flush, write_barrier
> > xbd1: ada0: 16.700MB/s transferssynchronize cache commands enabled.
> >  (WDMA2, PIO 8192bytes)
> > ada0: 51200MB (104857600 512 byte sectors)
> > ada1 at ata0 bus 0 scbus0 target 1 lun 0
> > ada1:  ATA-7 device
> > xn0: ada1: Serial Number QM2
> > backend features: feature-sgada1: 16.700MB/s transfers (WDMA2, 
> > PIO 8192bytescan't re-use a leaf (led)!
> > )
> 
> That's weird, it seems that both the emulated and PV disks are being
> detected and enumerated. Can you paste your domain configuration file
> and the contents of the loader.conf file in the virtual machine?

Sorry, missed that one.

builder = "hvm"
name = "FreeBSD"
disk = [
'/dev/zvol/zroot/freebsd1,raw,hda,w',
'/dev/zvol/zroot/freebsd2,raw,hdb,w',
'/dev/zvol/zroot/builder0,raw,hdc,w',
'/dev/zvol/zroot/builder1,raw,hdd,w'
]
boot = "c"
usbdevice = 'tablet'
#nographics = 1
#serial = [ "/dev/nmdm0A" ]
vnc = 1
#vnclisten = '0.0.0.0'
vif = ['bridge=bridge0,mac=00:02:04:08:fd:f0']
memory=4096
vcpus=4
vga = "stdvga"
videoram = 16
xen_platform_pci=0

/boot/loader.conf is

loader_logo=none
beastie_disable=yes

Looks like

xen_platform_pci=0

was a culprit (something I need to boot Fedora)

Marcin

smime.p7s
Description: S/MIME Cryptographic Signature

g_dev_taste: make_dev_p() failed (gp->name=ada1, error=17) - ok?

[Marcin Cieslak]

When starting FreeBSD domU (r319534) on 11.1-PRELEASE dom0 (same version)
I am guestting

can't re-use a leaf (led)!

and

g_dev_taste: make_dev_p() failed (gp->name=ada0, error=17)

messages in my dmesg.

The disks are attached as follows:

disk = [
'/dev/zvol/zroot/freebsd1,raw,hda,w',
'/dev/zvol/zroot/freebsd2,raw,hdb,w',
'/dev/zvol/zroot/builder0,raw,hdc,w',
'/dev/zvol/zroot/builder1,raw,hdd,w'
]

are those warning messages ok?

dmesg output below,

Marcin

xbd1: 40960MB  at device/vbd/832 on xenbusb_front0
ada0 at ata0 bus 0 scbus0 target 0 lun 0
xbd1: ada0: attaching as ada1
xbd1:  ATA-7 device
ada0: Serial Number QM1
features: flush, write_barrier
xbd1: ada0: 16.700MB/s transferssynchronize cache commands enabled.
 (WDMA2, PIO 8192bytes)
ada0: 51200MB (104857600 512 byte sectors)
ada1 at ata0 bus 0 scbus0 target 1 lun 0
ada1:  ATA-7 device
xn0: ada1: Serial Number QM2
backend features: feature-sgada1: 16.700MB/s transfers (WDMA2, 
PIO 8192bytescan't re-use a leaf (led)!
)
xbd2: ada1: 40960MB (83886080 512 byte sectors)
can't re-use a leaf (led)!
ada2 at ata1 bus 0 scbus1 target 0 lun 0
61440MB  at device/vbd/5632 on xenbusb_front0
g_dev_taste: make_dev_p() failed (gp->name=ada0, error=17)
xbd2: attaching as ada2
xbd2: ada2: features: flush, write_barrier
xbd2: synchronize cache commands enabled.
 ATA-7 device
uhub0: xbd3: 102400MB  at device/vbd/5696 on 
xenbusb_front0
ada2: Serial Number QM3
2 ports with 2 removable, self powered
g_dev_taste: make_dev_p() failed (gp->name=ada1, error=17)
xbd3: ada2: 16.700MB/s transfers (WDMA2, PIO 8192bytesattaching as ada3
)
xbd3: can't re-use a leaf (led)!
ada2: 61440MB (125829120 512 byte sectors)
features: flush, write_barrier
xbd3: g_dev_taste: make_dev_p() failed (gp->name=ada0p1, error=17)
synchronize cache commands enabled.
ada3 at ata1 bus 0 scbus1 target 1 lun 0
ada3:  ATA-7 device
ada3: Serial Number QM4
g_dev_taste: make_dev_p() failed (gp->name=ada0p2, error=17)
ada3: 16.700MB/s transfers (WDMA2, PIO 8192bytes)
ada3: 102400MB (209715200 512 byte sectors)
g_dev_taste: make_dev_p() failed (gp->name=ada0p3, error=17)
Trying to mount root from ufs:/dev/ada0p2 [rw]...
g_dev_taste: make_dev_p() failed (gp->name=ada1p1, error=17)
g_dev_taste: make_dev_p() failed (gp->name=ada2, error=17)
can't re-use a leaf (led)!
g_dev_taste: make_dev_p() failed (gp->name=ada2p1, error=17)
g_dev_taste: make_dev_p() failed (gp->name=ada3, error=17)



smime.p7s
Description: S/MIME Cryptographic Signature

Re: Testing for upcoming FreeBSD 11.1 release

[Marcin Cieslak]

On Sun, 4 Jun 2017, Marcin Cieslak wrote:

> Fedora 28 domU (...)

> Fedora needs xen_platform_pci=0 to start
> but that's unrelated (was the same with 12.0).

sorry - jumed too much into the future, this domU
is running


[root@fedora0 ~]# cat /etc/fedora-release 
Fedora release 25 (Twenty Five)
[root@fedora0 ~]# uname -a
Linux fedora0.6speed.de 4.10.8-200.fc25.x86_64 #1 SMP Fri Mar 31 13:20:22 UTC 
2017 x86_64 x86_64 x86_64 GNU/Linux
[root@fedora0 ~]#

Marcin

smime.p7s
Description: S/MIME Cryptographic Signature

Re: Testing for upcoming FreeBSD 11.1 release

[Marcin Cieslak]

On Fri, 2 Jun 2017, Roger Pau Monné wrote:

> Hello,
> 
> In order to try to avoid this happening again in 11.1, can everyone
> please test that what's in the stable/11 branch or the upcoming BETA
> builds works in their environment/use case?

Hi Roger,

I have downgraded my 12.0 dom0 to 11.1-PRERELEASE (r319534) and
I only had to rebuild xen-tools due to missing 12.0 ABIs (this is normal).

My FreeBSD 11, Windows Server 2016, Fedora 28 domU's started and seem
to be working fine. Fedora needs xen_platform_pci=0 to start
but that's unrelated (was the same with 12.0).

>From my point of view - things work as before.

Marcin

smime.p7s
Description: S/MIME Cryptographic Signature

Re: UEFI trouble with OVMF under Xen - nothing boots - SOLVED

[Marcin Cieslak]

On Sat, 1 Apr 2017, Marcin Cieslak wrote:

> On Sat, 1 Apr 2017, Marcin Cieslak wrote:
> 
> > This is a follow up to the UEFI Windows boot problems
> > reported after 4.7 got imported:
> > 
> > https://lists.freebsd.org/pipermail/freebsd-xen/2016-June/002745.html
> > 
> > I am using FreeBSD 12.0-CURRENT #6 r314708: Mon Mar  6 13:09:31 UTC 2017
> >  r...@o.saper.info:/usr/obj/usr/src/sys/GENERIC  amd64 as dom0
> > 
> > In the 4.5 times I could install and boot Windows 2016 Technical Preview 5 
> > without
> > major problems. In fact, I started using this as my default Windows
> > environment - it was working very well and very fast.
> 

So, for the archives:

I have compiled the newest OVMF git master in the DEBUG mode and found out
that under normal qemu both I/O debug port 0x402 logging or serial port logging
(depending how OVMF got compiled) do work.

I have never been getting debug output from the OVMF started by Xen.
What I didn't know is that firmware images are compiled into the hvmloader
so that just replacing the ovmf.bin DOES NOT work.

I must have had a 32-bit ovmf.bin on the filesystem when I was compiling
xen-tools; after replacing it with a 64-bit version and rebuilding
xen-tools things started to work.

Sorry for noise!

Marcin
___
freebsd-xen@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-xen
To unsubscribe, send any mail to "freebsd-xen-unsubscr...@freebsd.org"

Re: UEFI trouble with OVMF under Xen - nothing boots

[Marcin Cieslak]

On Sat, 1 Apr 2017, Marcin Cieslak wrote:

> This is a follow up to the UEFI Windows boot problems
> reported after 4.7 got imported:
> 
> https://lists.freebsd.org/pipermail/freebsd-xen/2016-June/002745.html
> 
> I am using FreeBSD 12.0-CURRENT #6 r314708: Mon Mar  6 13:09:31 UTC 2017 
> r...@o.saper.info:/usr/obj/usr/src/sys/GENERIC  amd64 as dom0
> 
> In the 4.5 times I could install and boot Windows 2016 Technical Preview 5 
> without
> major problems. In fact, I started using this as my default Windows
> environment - it was working very well and very fast.

A follow up to this:

I have tried a pure qemu installed from packages:

qemu-system-x86_64 \
-bios /usr/local/share/ovmf/ovmf.bin \
-no-shutdown \
-nodefaults -no-user-config \
-name Windows2016Pure -vnc 127.0.0.1:0,to=99 \
-display none -device VGA,vgamem_mb=16 \
-boot order=c \
-usb -usbdevice tablet -smp 2,maxcpus=2 \
-device rtl8139,id=nic0,netdev=net0,mac=00:16:3e:5d:0d:48 \
-netdev type=tap,id=net0,ifname=tap0,script=no,downscript=no \
-machine pc -m 4080 \
-drive 
file=/dev/zvol/zroot/windows0,if=ide,index=0,media=disk,format=raw,cache=writeback

and the boot process goes easily past the OVMF and continues booting,
only to fail "Inaccessible boot device" Windows message much later (probably 
because
I was using XenPV drivers there).

Marcin
___
freebsd-xen@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-xen
To unsubscribe, send any mail to "freebsd-xen-unsubscr...@freebsd.org"

UEFI trouble with OVMF under Xen - nothing boots

[Marcin Cieslak]

This is a follow up to the UEFI Windows boot problems
reported after 4.7 got imported:

https://lists.freebsd.org/pipermail/freebsd-xen/2016-June/002745.html

I am using FreeBSD 12.0-CURRENT #6 r314708: Mon Mar  6 13:09:31 UTC 2017 
r...@o.saper.info:/usr/obj/usr/src/sys/GENERIC  amd64 as dom0

In the 4.5 times I could install and boot Windows 2016 Technical Preview 5 
without
major problems. In fact, I started using this as my default Windows
environment - it was working very well and very fast.

Since 4.7 upgrade I never got Tianocore OVMF to boot - it just stops
there listing available devices:

https://marcincieslak.com/tmp/ovmf/ovmf-no-boot.png

I can browse the FS0 and there is BootX64.efi there

https://marcincieslak.com/tmp/ovmf/ovmf-files.png

(not sure if "Unsupported" message is normal, never tried this
in the days Windows was working).

The zvol contains the same Windows that used to start properly, so
I suspect the filesystems there did not get corrupt. Trying
to boot the installation ISO image ends up with a same thing.

I have tried old and new ovmf images:

https://marcincieslak.com/tmp/ovmf/ovmf.bin
can be taken from http://efi.akeo.ie/OVMF/

https://marcincieslak.com/tmp/ovmf/ovmf-new.bin
extracted from 
https://www.kraxel.org/repos/jenkins/edk2/edk2.git-0-20170328.b2579.g2ed235f.x86_64.rpm

tried 32bit and 64bit versions, both start with the same effect.

To reproduce it, modify xen-tools Makefile to add two flags to CONFIGURE_ARGS:

CONFIGURE_ARGS+=--with-extra-qemuu-configure-args="${QEMU_ARGS}" \

--with-system-seabios=${LOCALBASE}/share/seabios/bios.bin \
--enable-ovmf \
--with-system-ovmf=${LOCALBASE}/share/ovmf/ovmf.bin

Complete Makefile I am using is at

https://marcincieslak.com/tmp/ovmf/Makefile

Domain configuration file:

https://marcincieslak.com/tmp/ovmf/windows-run.cfg

builder = "hvm"
memory = 4096
vcpus = 2
name = "Windows2016"
disk = [
'/dev/zvol/zroot/windows0,raw,hda,w',
#   '/dev/zvol/zroot/vs2013,raw,hdb,w',
#'/root/win/install.iso,raw,hdc:cdrom,r'
]
boot = "c" # Boot to hard disk image
vnc = 2
#vnclisten = "0.0.0.0"
usbdevice = 'tablet'
on_poweroff = 'destroy'
on_reboot = 'restart'
#on_crash = 'restart'
on_crash = 'destroy'
acpi = 1
bios = 'ovmf'
vif = [ 'bridge=bridge0,mac=00:16:3e:5d:0d:48' ]
videoram=16
vga = "stdvga"

It does not matter if I use "hda" or "xvda"

The qemu driver domain running looks like this:

https://marcincieslak.com/tmp/ovmf/qemu-process

/usr/local/lib/xen/bin/qemu-system-i386 \
-xen-domid 30 \
-chardev 
socket,id=libxl-cmd,path=/var/run/xen/qmp-libxl-30,server,nowait \
-no-shutdown \
-mon chardev=libxl-cmd,mode=control \
-chardev 
socket,id=libxenstat-cmd,path=/var/run/xen/qmp-libxenstat-30,server,nowait \
-mon chardev=libxenstat-cmd,mode=control \
-nodefaults -no-user-config \
-name Windows2016 -vnc 127.0.0.1:0,to=99 \
-display none -device VGA,vgamem_mb=16 \
-boot order=c \
-usb -usbdevice tablet -smp 2,maxcpus=2 \
-device rtl8139,id=nic0,netdev=net0,mac=00:16:3e:5d:0d:48 \
-netdev type=tap,id=net0,ifname=xnb30.0-emu,script=no,downscript=no \
-machine xenfv -m 4080 \
-drive 
file=/dev/zvol/zroot/windows0,if=ide,index=0,media=disk,format=raw,cache=writeback

Nothing special in the "xl dmesg", Xen is just starting OVMF.

I don't know even where to start to troubleshoot this...
Anyway to get to the OVMF debug output, maybe?

I've tried some other UEFI non-Windows installers and all images behave
the same: no surprise, as no Windows code had a chance to run yet.

Marcin

___
freebsd-xen@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-xen
To unsubscribe, send any mail to "freebsd-xen-unsubscr...@freebsd.org"

Re: HEADS UP: Imported Xen 4.7: no blkback

[Marcin Cieslak]

On Thu, 16 Jun 2016, Roger Pau Monné wrote:

> I've just imported Xen 4.7.0-rc6 into the ports tree, could you give it a 
> try when you have a moment?

Yes, of course. A quick test shows no change - Windows get stuck
at the UEFI shell with some block devices listed (I use "hda" for
Windows), SeaBIOS cannot boot FreeBSD with "xvda". FreeBSD
works with "hda", but I have to mount "/dev/ada0p1".

Marcin
___
freebsd-xen@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-xen
To unsubscribe, send any mail to "freebsd-xen-unsubscr...@freebsd.org"

Re: HEADS UP: Imported Xen 4.7: no blkback

[Marcin Cieslak]

On Mon, 13 Jun 2016, Roger Pau Monné wrote:

> On Fri, Jun 10, 2016 at 09:38:59PM +0000, Marcin Cieslak wrote:
> > "?" does not work - it mostly causes a panic, the console is slow, but I 
> > managed
> > to switch it to /dev/ada0p2, dmesg below:
> 
> This has now been reverted, so when I import the new RC this should be fixed 
> and you won't need to change anything.

I am confused now - so with a new Xen kernel (not yet in ports) I can use
/dev/xbd* devices again? They are in fact missing - xbd driver says "attaching 
as ada0"
and I can mount it only as /dev/ada

> It seems like Windows PV drivers don't attach at all, or are you running 
> Windows without the PV drivers?

Yes, I have. Those Windows partitions used to work properly without changes
under xen 4.5. But we are too early - the problem is that even ovmf
does not se them drives now, this is before Windows boots.

> Since you mention that the console is very slow, if you run 'top' on Dom0, 
> do you see any process (eg: qemu) taking a lot of CPU time?

Yes,

 1635 root  7 1000   241M   101M RUN  7:16  91.14% 
qemu-system-i386

or more

> Also, do you see Dom0 consuming a lot of CPU if you run 'xentop'?

  Domain-0 -r446  100.04194300   25.2   no limit   n/a 
10000000  0  0  
  0

Marcin
___
freebsd-xen@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-xen
To unsubscribe, send any mail to "freebsd-xen-unsubscr...@freebsd.org"

Re: HEADS UP: Imported Xen 4.7 and blkback changes

[Marcin Cieslak]

On Thu, 9 Jun 2016, Roger Pau Monné wrote:

> On Wed, Jun 08, 2016 at 10:18:09PM +0000, Marcin Cieslak wrote:
> > On Fri, 3 Jun 2016, Roger Pau Monné wrote:
> > 
> > > Hello,
> > > 
> > > First of all, this message is only relevant to those that use FreeBSD as 
> > > Dom0 (host), not as a DomU (guest), so don't panic.
> > > 
> > > I've imported the latest Xen version (4.7-rc4) into the ports tree, it's 
> > > still not the final version, but it's quite close, so we better start 
> > > testing it to make sure it works fine with FreeBSD.
> > 
> > Thank you Roger, this is excellent. Are xen-tools-devel 4.5 now?
> > Looks confusing.
> > 
> > I have also tried building xen-tools (4.7) without python
> > and qemu configure reported this.
> 
> Python is required, you cannot get rid of it.

Strange, seems USES= python in the port's Makefile didn't work for me and
continued happily after.

Marcin

___
freebsd-xen@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-xen
To unsubscribe, send any mail to "freebsd-xen-unsubscr...@freebsd.org"

Re: HEADS UP: Imported Xen 4.7: no blkback

[Marcin Cieslak]

On Thu, 9 Jun 2016, Roger Pau Monné wrote:

> On Thu, Jun 09, 2016 at 12:16:59AM +0000, Marcin Cieslak wrote:
> > On Fri, 3 Jun 2016, Roger Pau Monné wrote:
> > 
> > > One of the more relevant changes in 4.7 regarding FreeBSD is the support 
> > > for 
> > > block hotplug scripts. This means that we now have the option to use 
> > > backends different than simple block or regular files, provided that 
> > > someone 
> > > writes the proper hotplug scripts to attach them (I've heard there are 
> > > some 
> > > iSCSI hotplug scripts around). This however requires changes in blkback, 
> > > so 
> > > if you plan to use the Xen 4.7 port, please make sure that you are 
> > > running a 
> > > kernel that contains revision r301269 (or any later version). The same 
> > > also 
> > 
> > I am running it with r301685 and the HVM guests have some trouble with
> > block devices.
> > 
> > SeaBIOS does not find /dev/zvol/zroot/freebsd1,raw,xvda,w to boot FreeBSD
> > from, after chaging to "hda" I get up to the kernel mountroot prompt
> > (Xen block devices seem to be detected in dmesg).
> 
> Yes, this is intentional, see:
> 
> https://marc.info/?l=xen-devel=144482080812353

those guests worked fine with 4.5, that's why I am surprised.

xbd0 and xbd1 show up in dmesg, mouting root from xbd0p2 fails, but 
ada0p2 seems to work.

I remember that during my previous attempts ZFS ate most of
my machine's memory (dom0 was too small I think) and the
symptom was very similar if not identical.

One thing which struck me is that I was able to fully but
one Linux HVM domU. I am also toying with OpenFirmware
which boots from floppy as a HVM guest.

> Have you checked if you need to change your /etc/fstab to correctly point 
> to the new device? Does FreeBSD correctly list the disk(s) at the mountroot 
> prompt when issuing a "?" command?

"?" does not work - it mostly causes a panic, the console is slow, but I managed
to switch it to /dev/ada0p2, dmesg below:

Copyright (c) 1992-2016 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
The Regents of the University of California. All rights reserved.
FreeBSD is a registered trademark of The FreeBSD Foundation.
FreeBSD 11.0-CURRENT #1 r298620: Tue Apr 26 13:21:50 UTC 2016
r...@o.saper.info:/usr/obj/usr/src/sys/GENERIC amd64
FreeBSD clang version 3.8.0 (tags/RELEASE_380/final 262564) (based on LLVM 
3.8.0)
WARNING: WITNESS option enabled, expect reduced performance.
VT(vga): text 80x25
XEN: Hypervisor version 4.7 detected.
CPU: Intel(R) Xeon(R) CPU E31245 @ 3.30GHz (3300.08-MHz K8-class CPU)
  Origin="GenuineIntel"  Id=0x206a7  Family=0x6  Model=0x2a  Stepping=7
  
Features=0x17c3fbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,ACPI,MMX,FXSR,SSE,SSE2,HTT>
  
Features2=0x9fba2203<SSE3,PCLMULQDQ,SSSE3,CX16,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,TSCDLT,AESNI,XSAVE,OSXSAVE,AVX,HV>
  AMD Features=0x28100800<SYSCALL,NX,RDTSCP,LM>
  AMD Features2=0x1
  XSAVE Features=0x1
Hypervisor: Origin = "XenVMMXenVMM"
real memory  = 2130706432 (2032 MB)
avail memory = 2018213888 (1924 MB)
Event timer "LAPIC" quality 400
ACPI APIC Table: 
WARNING: L1 data cache covers less APIC IDs than a core
0 < 1
WARNING: L2 data cache covers less APIC IDs than a core
0 < 1
WARNING: L3 data cache covers less APIC IDs than a core
0 < 1
FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs
FreeBSD/SMP: 1 package(s) x 2 core(s)
random: unblocking device.
ioapic0: Changing APIC ID to 1
MADT: Forcing active-low polarity and level trigger for SCI
ioapic0  irqs 0-47 on motherboard
random: entropy device external interface
kbd1 at kbdmux0
netmap: loaded module
module_register_init: MOD_LOAD (vesa, 0x80f0ffb0, 0) error 19
vtvga0:  on motherboard
cryptosoft0:  on motherboard
acpi0:  on motherboard
acpi0: Power Button (fixed)
acpi0: Sleep Button (fixed)
cpu0:  on acpi0
cpu1:  on acpi0
hpet0:  iomem 0xfed0-0xfed003ff on acpi0
Timecounter "HPET" frequency 6250 Hz quality 950
attimer0:  port 0x40-0x43 irq 0 on acpi0
Timecounter "i8254" frequency 1193182 Hz quality 0
Event timer "i8254" frequency 1193182 Hz quality 100
atrtc0:  port 0x70-0x71 irq 8 on acpi0
Event timer "RTC" frequency 32768 Hz quality 0
Timecounter "ACPI-fast" frequency 3579545 Hz quality 900
acpi_timer0: <32-bit timer at 3.579545MHz> port 0xb008-0xb00b on acpi0
pcib0:  port 0xcf8-0xcff on acpi0
pci0:  on pcib0
isab0:  at device 1.0 on pci0
isa0:  on isab0
atapci0:  port 
0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xc200-0xc20f at device 1.1 on pci0
ata0:  at channel 0 on atapci0
ata1:  at channel 1 on atapci0
pci0:  at device 1.3 (no driver attach

Re: HEADS UP: Imported Xen 4.7: no blkback

[Marcin Cieslak]

On Fri, 3 Jun 2016, Roger Pau Monné wrote:

> One of the more relevant changes in 4.7 regarding FreeBSD is the support for 
> block hotplug scripts. This means that we now have the option to use 
> backends different than simple block or regular files, provided that someone 
> writes the proper hotplug scripts to attach them (I've heard there are some 
> iSCSI hotplug scripts around). This however requires changes in blkback, so 
> if you plan to use the Xen 4.7 port, please make sure that you are running a 
> kernel that contains revision r301269 (or any later version). The same also 

I am running it with r301685 and the HVM guests have some trouble with
block devices.

SeaBIOS does not find /dev/zvol/zroot/freebsd1,raw,xvda,w to boot FreeBSD
from, after chaging to "hda" I get up to the kernel mountroot prompt
(Xen block devices seem to be detected in dmesg).

What used to be Windows 2016 domU with /dev/zvol/zroot/windows0,raw,hda,w
ends up in the Tianocore UEFI shell. Block devices seem to be available,
I can even list the fs0: partition, but no booting further possible.

Marcin

# more freebsd.cfg 
builder = "hvm"
name = "FreeBSD"
disk = [
'/dev/zvol/zroot/freebsd1,raw,xvda,w',
'/dev/zvol/zroot/freebsd2,raw,xvdb,w'
]
boot = "c"
#usbdevice = 'tablet'
#nographics = 1
serial = [ "file:/tmp/boot.log" ]
vnc = 1
#vnclisten = '0.0.0.0'
vif = ['bridge=bridge0,mac=00:02:04:08:fd:f0']
memory=2048
vcpus=1
vga = "cirrus"
videoram = 16

# more windows-run.cfg 
builder = "hvm"
memory = 4096
vcpus = 2
name = "Windows2016"
disk = [
'/dev/zvol/zroot/windows0,raw,hda,w',
'/dev/zvol/zroot/vs2013,raw,hdb,w',
#'/root/win/install.iso,raw,hdc:cdrom,r'
]
boot = "c" # Boot to hard disk image
vnc = 2
#vnclisten = "0.0.0.0"
usbdevice = 'tablet'
on_poweroff = 'destroy'
on_reboot = 'restart'
#on_crash = 'restart'
on_crash = 'destroy'
acpi = 1
bios = 'ovmf'
vif = [ 'bridge=bridge0,mac=00:16:3e:5d:0d:48' ]
videoram=16
vga = "stdvga"
___
freebsd-xen@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-xen
To unsubscribe, send any mail to "freebsd-xen-unsubscr...@freebsd.org"

Re: HEADS UP: Imported Xen 4.7 and blkback changes - domU respawning on_crash

[Marcin Cieslak]

On Wed, 8 Jun 2016, Marcin Cieslak wrote:

> On Fri, 3 Jun 2016, Roger Pau Monné wrote:
> 
> > Hello,
> > 
> > First of all, this message is only relevant to those that use FreeBSD as 
> > Dom0 (host), not as a DomU (guest), so don't panic.
> > 
> > I've imported the latest Xen version (4.7-rc4) into the ports tree, it's 
> > still not the final version, but it's quite close, so we better start 
> > testing it to make sure it works fine with FreeBSD.

One issue maybe unrelated to FreeBSD:

This domain:

builder = "hvm"
memory = 4096
vcpus = 2
name = "Windows2016"
disk = [
'/dev/zvol/zroot/windows0,raw,hda,w',
'/dev/zvol/zroot/vs2013,raw,hdb,w',
#'/root/win/install.iso,raw,hdc:cdrom,r'
]
boot = "c" # Boot to hard disk image
vnc = 2
#vnclisten = "0.0.0.0"
usbdevice = 'tablet'
on_poweroff = 'destroy'
on_reboot = 'restart'
on_crash = 'restart'
acpi = 1
bios = 'ovmf'
vif = [ 'bridge=bridge0,mac=00:16:3e:5d:0d:48' ]
videoram=16
vga = "stdvga"

crashes because I didn't have ovmf image:

(d203) HVM Loader
(d203) Detected Xen v4.7.0-rc
(d203) Xenbus rings @0xfeffc000, event channel 1
(d203) Unknown BIOS ovmf, no ROM image found
(d203) *** HVMLoader bug at hvmloader.c:229
(d203) *** HVMLoader crashed.

But I seem unable to kill it with "xl destroy" - it keeps
respawning again:

Windows2016211  4079 1 --p---   0.0
Windows2016213  4096 1 --psc-   0.0
(disappears)
Windows2016221  4096 1 --psc-   0.0
(null) 221   147 1 --psc-   0.0
...
...

I have finally managed to snatch it by issuing this a few times, after
changing the "on_crash" to 'destroy':

# xl config-update Windows2016 xen/windows-run.cfg
WARNING: xl now has better capability to manage domain configuration, avoid 
using this command when possible
setting dom243 configuration


Marcin
___
freebsd-xen@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-xen
To unsubscribe, send any mail to "freebsd-xen-unsubscr...@freebsd.org"

Getting more than 800x600 on the HVM console?

[Marcin Cieslak]

Despite having

memory = 4096
videoram=16
vga = "stdvga"

in my Windows hvm domU configuration my Xen console is always
stuck on 800x600. (FreeBSD's VGA console is 640x480 even).

Windows detects it as Microsoft Basic Display Adapter
with the usual Bochs PCI IDs 0x1234/0x.
The resolution is 800x600, grayed out, with 32bpp.
It also says it has "2039MB Total Available Video Memory"
which is also "2039MB Shared System Memory".

Not sure it's FreeBSD specific, but all advice
online tells me to set "videoram".

Any hints?

Marcin
___
freebsd-xen@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-xen
To unsubscribe, send any mail to "freebsd-xen-unsubscr...@freebsd.org"

Re: Leftover (null) domUs

[Marcin Cieslak]

On Thu, 26 May 2016, Roger Pau Monné wrote:

> On Mon, May 23, 2016 at 07:38:42PM +0000, Marcin Cieslak wrote:
> > Hello,
> > 
> > sometimes (rarely) zombie domains are left over after "xl destroy":
> > 
> > # xl list
> > NameID   Mem VCPUs  State   Time(s)
> > Domain-0 0  3270 1 r-   
> > 28887.1
> > (null)   7 0 1 --ps-d 
> > 769.7
> > (null)  34 0 2 --p--d   
> > 5.3
> > 
> > both are HVMs runing on r299012, (#7 was HVM FreeBSD guest, #34 Windows 
> > 2016 Server).
> > 
> > Recent "xl dmesg entries":
> > 
> > (XEN) mm.c:2010:d0v0 Error pfn 12b0a5: rd=8304122e4000, 
> > od=, caf=180, taf=0001
> > (XEN) mm.c:2010:d0v0 Error pfn 12b0a4: rd=8304122e4000, 
> > od=, caf=180, taf=0001
> > (XEN) mm.c:2010:d0v0 Error pfn 12b0a3: rd=8304122e4000, 
> > od=, caf=180, taf=0001
> > (XEN) mm.c:2010:d0v0 Error pfn 12b0a2: rd=8304122e4000, 
> > od=, caf=180, taf=0001
> 
> Right, can you paste the output of the 'g' debug key when you have only 
> domains in such state?

Thanks, didn't know that one. Will try the next time it happens, fortunately
not very often.

Marcin
___
freebsd-xen@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-xen
To unsubscribe, send any mail to "freebsd-xen-unsubscr...@freebsd.org"

Leftover (null) domUs

[Marcin Cieslak]

Hello,

sometimes (rarely) zombie domains are left over after "xl destroy":

# xl list
NameID   Mem VCPUs  State   Time(s)
Domain-0 0  3270 1 r-   28887.1
(null)   7 0 1 --ps-d 769.7
(null)  34 0 2 --p--d   5.3

both are HVMs runing on r299012, (#7 was HVM FreeBSD guest, #34 Windows 2016 
Server).

Recent "xl dmesg entries":

(XEN) mm.c:2010:d0v0 Error pfn 12b0a5: rd=8304122e4000, 
od=, caf=180, taf=0001
(XEN) mm.c:2010:d0v0 Error pfn 12b0a4: rd=8304122e4000, 
od=, caf=180, taf=0001
(XEN) mm.c:2010:d0v0 Error pfn 12b0a3: rd=8304122e4000, 
od=, caf=180, taf=0001
(XEN) mm.c:2010:d0v0 Error pfn 12b0a2: rd=8304122e4000, 
od=, caf=180, taf=0001

Trying to kill them again with xl destroy causes:

# xl destroy 7
libxl: error: libxl_dm.c:1602:kill_device_model: unable to find device model 
pid in /local/domain/7/image/device-model-pid
libxl: error: libxl.c:1615:libxl__destroy_domid: libxl__destroy_device_model 
failed for 7
libxl: info: libxl.c:1698:devices_destroy_cb: forked pid 18500 for destroy of 
domain 7

Marcin
___
freebsd-xen@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-xen
To unsubscribe, send any mail to "freebsd-xen-unsubscr...@freebsd.org"