Re: help needed with UEFI BIOS and CSM

[Roger Pau Monné via freebsd-xen]

On Mon, May 24, 2021 at 05:15:25PM +0200, lizbethmutterh...@gmail.com wrote:
> I CSMd the BIOS and so I have the start partition, although every system on 
> the 1TB hdd is UEFI (FreeBSD, too). I want to start the hypervisor kernel in 
> advance, made a kernel and builtworld but I'm unsure what to do now?

I'm afraid I'm not sure I understand what you want to achieve.

Please note that FreeBSD HEAD supports booting Xen from UEFI now also,
so you are no longer tied to using legacy BIOS.

If you want to boot Xen you need to install the xen-kernel package and
add the xen_kernel and xen_cmdline options to your loader.conf, see:

https://docs.freebsd.org/en/books/handbook/virtualization/#virtualization-host-xen

You likely also want to install the xen-tools package in order to
manage VMs.

Roger.
___
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"

help needed with UEFI BIOS and CSM

[lizbethmutterhunt]

I CSMd the BIOS and so I have the start partition, although every system on 
the 1TB hdd is UEFI (FreeBSD, too). I want to start the hypervisor kernel in 
advance, made a kernel and builtworld but I'm unsure what to do now?

Greetz, 

Lizbeth


___
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: [SUSPECTED SPAM]Re: HEADS UP: FreeBSD/Xen dom0 UEFI support

[Roger Pau Monné via freebsd-xen]

On Sun, May 16, 2021 at 07:17:46PM -0600, Stephen Walker-Weinshenker wrote:
> > > xen_cmdline="dom0_mem=2048M dom0_max_vcpus=1 dom0=pvh com1=115200,8n1
> > > guest_loglvl=all loglvl=all console=vga,com1"
> > Can you try adding 'watchdog' to xen_cmdline and see if that forces
> > the box to reboot after it goes black?
> >
> > If Xen is able to boot, and the problem is with FreeBSD dom0 you might
> > try also adding vga=keep to xen_cmdline, that way we might get some
> > output from dom0 (if that's indeed where the issue is happening).
> >
> > > xen-kernel version = 4.14.1_1
> > > xen-tools version = 4.14.1_1
> > >
> > > Both installed from packages, rather than ports.
> > >
> > > These boxes are Intel NUCs that I normally manage over intel AMT using 
> > > mesh
> > > commander. I tried enabling the virtual serial port through AMT but no
> > > dice.
> >
> > I never tried using the AMT serial port, first thing would be to get
> > it to work with plain FreeBSD, then we can see about getting it
> > working with Xen. FWIW, a lot of the test boxes I work with use SoL,
> > and I would expect the AMT serial to work as well.
> 
> No dice on the AMT serial port, but I have been less than impressed with
> MeshCommander and AMT thus far.
> >
> > > I know the nucs have a hardware serial port, but I don't have the
> > > cable to attach to the header at the moment. I have ordered some headers
> > > and crimp pins to attach to the serial port for more debugging, but they
> > > will not get here for about a week.
> >
> > I did the original EFI work on a NUC7i7DNHE using the serial port.
> > Last time I tried HDMI worked with Xen.
> 
> I was able to get the hardware serial port working. turned out I had a typo in
> my /boot/loader.conf. Commconsole instead of comconsole. That also flagged
> a different error that revealed that vidconsole should be replaced with efi on
> UEFI systems
> >
> > > I also tried connecting directly to the NUC's HDMI port but I just got a
> > > blank screen again, after all the boot messages appeared.
> >
> > Are those messages that you see Xen boot messages or FreeBSD boot
> > messages?
> >
> > Does the box reboot itself?
> 
> No
> 
> >
> > I'm afraid we will require some more information to help diagnose
> > what's going on.
> 
> Tried adding both of the options that you mentioned above to xen_cmdline with 
> no
> appreciable difference.
> The system did not appear to attempt to reboot itself. See serial
> console output below.
> 
> After the Beastie menu, I get the following output on both HDMI and
> serial consoles,
> and then no further output on the serial console, while the HDMI
> console goes blank.
> 
> 
> Loading Xen kernel...
> /boot/xen data=0x26b9a8+0x146658 -
> Loading kernel...
> /boot/kernel/kernel size=0x1debd70
> Loading configured modules...
> /boot/entropy size=0x1000
> /etc/hostid size=0x25
> EFI framebuffer information:
> addr, size 0x40, 0x1d4c00
> dimensions 800 x 600
> stride 800
> masks  0x00ff, 0xff00, 0x00ff, 0xff00
> 
> I am happy to do additional debugging, but I personally am out of my depth 
> here.

So there doesn't seem to be any output at all from Xen.

Can you paste your full /boot/loader.conf?

Can you try to swap com1 with com2 on the xen_cmdline and see if that
makes any difference. Xen doesn't really have any logic to figure out
which is the proper serial port to use.

Also there should now be a binary xen-kernel 4.15 package, so you can
also try with that one to see if it makes a difference.

I've only been able to test multiboot2 EFI loading on a single box, so
it's possible it has some sharp edges, sorry.

Thanks, Roger.
___
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: [SUSPECTED SPAM]Re: HEADS UP: FreeBSD/Xen dom0 UEFI support

[Stephen Walker-Weinshenker]

> > xen_cmdline="dom0_mem=2048M dom0_max_vcpus=1 dom0=pvh com1=115200,8n1
> > guest_loglvl=all loglvl=all console=vga,com1"
> Can you try adding 'watchdog' to xen_cmdline and see if that forces
> the box to reboot after it goes black?
>
> If Xen is able to boot, and the problem is with FreeBSD dom0 you might
> try also adding vga=keep to xen_cmdline, that way we might get some
> output from dom0 (if that's indeed where the issue is happening).
>
> > xen-kernel version = 4.14.1_1
> > xen-tools version = 4.14.1_1
> >
> > Both installed from packages, rather than ports.
> >
> > These boxes are Intel NUCs that I normally manage over intel AMT using mesh
> > commander. I tried enabling the virtual serial port through AMT but no
> > dice.
>
> I never tried using the AMT serial port, first thing would be to get
> it to work with plain FreeBSD, then we can see about getting it
> working with Xen. FWIW, a lot of the test boxes I work with use SoL,
> and I would expect the AMT serial to work as well.

No dice on the AMT serial port, but I have been less than impressed with
MeshCommander and AMT thus far.
>
> > I know the nucs have a hardware serial port, but I don't have the
> > cable to attach to the header at the moment. I have ordered some headers
> > and crimp pins to attach to the serial port for more debugging, but they
> > will not get here for about a week.
>
> I did the original EFI work on a NUC7i7DNHE using the serial port.
> Last time I tried HDMI worked with Xen.

I was able to get the hardware serial port working. turned out I had a typo in
my /boot/loader.conf. Commconsole instead of comconsole. That also flagged
a different error that revealed that vidconsole should be replaced with efi on
UEFI systems
>
> > I also tried connecting directly to the NUC's HDMI port but I just got a
> > blank screen again, after all the boot messages appeared.
>
> Are those messages that you see Xen boot messages or FreeBSD boot
> messages?
>
> Does the box reboot itself?

No

>
> I'm afraid we will require some more information to help diagnose
> what's going on.

Tried adding both of the options that you mentioned above to xen_cmdline with no
appreciable difference.
The system did not appear to attempt to reboot itself. See serial
console output below.

After the Beastie menu, I get the following output on both HDMI and
serial consoles,
and then no further output on the serial console, while the HDMI
console goes blank.


Loading Xen kernel...
/boot/xen data=0x26b9a8+0x146658 -
Loading kernel...
/boot/kernel/kernel size=0x1debd70
Loading configured modules...
/boot/entropy size=0x1000
/etc/hostid size=0x25
EFI framebuffer information:
addr, size 0x40, 0x1d4c00
dimensions 800 x 600
stride 800
masks  0x00ff, 0xff00, 0x00ff, 0xff00

I am happy to do additional debugging, but I personally am out of my depth here.

Thank you

Stephen
___
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: [SUSPECTED SPAM]Re: HEADS UP: FreeBSD/Xen dom0 UEFI support

[Stephen Walker-Weinshenker]

On Mon, Apr 26, 2021 at 3:30 AM Roger Pau Monné 
wrote:

> On Sun, Apr 25, 2021 at 05:10:44PM -0600, Stephen Walker-Weinshenker wrote:
> > On Thu, Apr 22, 2021 at 12:58 AM Roger Pau Monné 
> > wrote:
> >
> > > On Wed, Apr 21, 2021 at 08:32:18PM -0600, Stephen Walker-Weinshenker
> wrote:
> > > > Hello Roger:
> > > >
> > > > Thank you for your work on this. I am new to Xen and FreeBSD but am
> > > willing
> > > > to help test this and get it in a release version.
> > > >
> > > > I have 3 Intel NUC 8v5PNK that I am planning on using for Xen hosts,
> but
> > > > they can only boot in UEFI mode (intel disabled BIOS booting per
> their
> > > > official documentation even though it is still an option in the BIOS
> > > > /shrug). Until this patch came along I could not get any Xen
> distribution
> > > > to boot since they all require BIOS mode.
> > > >
> > > > I have 2 of the 3 NUCS running 14.0-CURRENT at git commit
> > > > 55fc118be8f0cd20e2123cfd2728c5f32317a9fa (after your patch was
> merged)
> > > and
> > > > I have attempted to follow the instructions at
> > > >
> > >
> https://docs.freebsd.org/en_US.ISO8859-1/books/handbook/virtualization-host-xen.html
> > > > in order to get the Xen kernel booting. Unfortunately, when I
> rebooted
> > > > after making the changes, I get an error saying:
> > > >
> > > > >Loading Xen kernel...
> > > > >Failed to load Xen kernel '/boot/xen'
> > > > >can't load 'kernel'
> > > > >
> > > > >can't load 'kernel'
> > >
> > > Did you update the loader on the EFI partition?
> > >
> > > After an installworld on my box I would usually do:
> > >
> > > # mount -t msdosfs /dev/ada0p1 /mnt/
> > > # cp /boot/loader.efi /mnt/EFI/freebsd/loader.efi
> > > # umount /mnt
> > >
> > > To update the EFI loader. You might have to check the output of
> > > `efibootmgr -v`to make sure you are replacing the correct loader. I
> > > guess there must also be a way to do this with efibootmgr.
> > >
> > > For whatever reason my EFI partition nvd0p1 was already mounted at
> > /boot/efi,
> > so my copy command was
> > # cp -f /boot/loader.efi /boot/efi/efi/freebsd/loader.efi
> >
> > I did this prior to the last reboot after changing the boot config as
> > recommended by
> >
> > This fixed the issue of the xen kernel not booting on one of the boxes.
> > (did the copy prior to the final reboot) Looks like I will have to
> > reinstall the OS on the other one (not a big deal)
> >
> > Now, I am just getting a blank screen on boot. I am unable to ssh into
> the
> > Dom0 either.
>
> What's your Xen command line? (ie: xen_cmdline string in
> loader.conf)
>
> Which version of Xen are you using?
>
> Do you have serial output available on those boxes? That might help
> get some messages if everything else fails.
>
> Roger.
>

Sorry for the delay in responding. Real life took precedence over this
testing.

xen_cmdline="dom0_mem=2048M dom0_max_vcpus=1 dom0=pvh com1=115200,8n1
guest_loglvl=all loglvl=all console=vga,com1"

xen-kernel version = 4.14.1_1
xen-tools version = 4.14.1_1

Both installed from packages, rather than ports.

These boxes are Intel NUCs that I normally manage over intel AMT using mesh
commander. I tried enabling the virtual serial port through AMT but no
dice. I know the nucs have a hardware serial port, but I don't have the
cable to attach to the header at the moment. I have ordered some headers
and crimp pins to attach to the serial port for more debugging, but they
will not get here for about a week.

I also tried connecting directly to the NUC's HDMI port but I just got a
blank screen again, after all the boot messages appeared.

Thank you again.

-- 
Stephen Walker-Weinshenker
sww1...@gmail.com
___
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: [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

Re: Issue with packet framing on xnb(4) connections and NetBSD domus

[Roger Pau Monné via freebsd-xen]

On Wed, Mar 17, 2021 at 01:23:46AM -0700, Brian Buhrow wrote:
>   hello.  I've noticed that on my Xen server, running 
> FreeBSD-12.2/Xen-4.14.0, I see a lot
> of messages like the following from my NetBSD-5 and NetBSD-current domu's: 
> xennet0: discarding oversize frame (len=1518)
> 
> They happen when network traffic is heavy and when traffic is coming from a 
> physical switch in
> the same vlan as the domu's.  Since I don't think packets are  actually 
> oversized on the wire,
> the Cisco switch managing this network does not report any giant packets, I 
> think this is a
> software problem either on the NetBSD domu's, or the FreeBSD dom0.  Since 
> I've been running
> these same NetBSD domu setups on a machine where NetBSD is the dom0, I think 
> this is an issue
> with the xnb(4) or netback.c  driver.  Specifically, it looks like it 
> concatinates multiple
> packets together before notifying the domu that there is traffic available.  
> Perhaps that is by
> design, since I cannot reproduce the issue on a FreeBSD-domu running on the 
> same FreeBSD-dom0
> machine.  In either case, while things are usable, it creates a very noisy 
> log on the
> NetBSD-domu machines.  Does the xnb(4) driver forward multiple packets to the 
> domu front ends
> and set the length of the message to the sum of the lengths of all the 
> packets it's forwarding,
> leaving it to the domu front end driver to separate the packets on reception? 
>  Is there a
> parameter that can be set on a per-domu basis to say whether you want
> multiple-packets-per-transfer or not from the dom0?

I think this is an issue with FreeBSD netback as it doesn't properly
handle frontends that don't understand some of the features
implemented in the FreeBSD backend and are enabled unconditionally.

Could you paste the output of `xenstore-ls -fp` from dom0 when one of
those NetBSD domUs is running?

Thanks, Roger.
___
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: Strange error messages from xnb on dom0. What do they mean?

[Roger Pau Monné via freebsd-xen]

On Mon, Apr 26, 2021 at 11:41:13AM -0700, Brian Buhrow wrote:
>   hello.  Occasionally I see messages like the following from my 
> FreeBSD-12.2/dom0 machine.
> Is this related to the issue of the NetBSD domu's seeing bursts of oversized 
> packets, which I assume
> is caused by packets getting sent from the dom0 to the domu in batches rather 
> than one at a
> time, each with an interrupt signal, or, the xen equivalent?
> 
> On the domu's I see:
> xennet0: discarding oversize frame (len=1518)
> 
> I see the following messages on the dom0, but not necessarily at the same 
> time as the above
> messages appear in the domu's.
> 
> Any ideas?
> -thanks
> -Brian
> 
> 
> Apr 25 14:56:35 xen-lothlorien kernel: xnb(xnb_ring2pkt:1532): Unknown extra 
> info type 255.  Discarding packet
> Apr 25 14:56:35 xen-lothlorien kernel: xnb(xnb_dump_txreq:302): 
> netif_tx_request index =0
> Apr 25 14:56:35 xen-lothlorien kernel: xnb(xnb_dump_txreq:303): 
> netif_tx_request.gref  =0
> Apr 25 14:56:35 xen-lothlorien kernel: xnb(xnb_dump_txreq:304): 
> netif_tx_request.offset=0
> Apr 25 14:56:35 xen-lothlorien kernel: xnb(xnb_dump_txreq:305): 
> netif_tx_request.flags =8
> Apr 25 14:56:35 xen-lothlorien kernel: xnb(xnb_dump_txreq:306): 
> netif_tx_request.id=69
> Apr 25 14:56:35 xen-lothlorien kernel: xnb(xnb_dump_txreq:307): 
> netif_tx_request.size  =1000
> Apr 25 14:56:35 xen-lothlorien kernel: xnb(xnb_dump_txreq:302): 
> netif_tx_request index =1
> Apr 25 14:56:35 xen-lothlorien kernel: xnb(xnb_dump_txreq:303): 
> netif_tx_request.gref  =255
> Apr 25 14:56:35 xen-lothlorien kernel: xnb(xnb_dump_txreq:304): 
> netif_tx_request.offset=0
> Apr 25 14:56:35 xen-lothlorien kernel: xnb(xnb_dump_txreq:305): 
> netif_tx_request.flags =0
> Apr 25 14:56:35 xen-lothlorien kernel: xnb(xnb_dump_txreq:306): 
> netif_tx_request.id=0
> Apr 25 14:56:35 xen-lothlorien kernel: xnb(xnb_dump_txreq:307): 
> netif_tx_request.size  =0
> Apr 25 14:56:35 xen-lothlorien kernel: xnb(xnb_rxpkt2rsp:2066): Got error -1 
> for hypervisor gnttab_copy status

Those are from netback failing to recognize or process a packet.
Likely netback is being too verbose here, as those should only appear
on debug builds or with boot_verbose. It might help identify what's
going wrong between NetBSD netfront and FreeBSD netback.

Roger.
___
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: [PROMOTIONAL]FreeBSD 14-CURRENT as a guest working?

[Roger Pau Monné via freebsd-xen]

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:
> 
> 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.

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.

> 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?

Thanks, Roger.
___
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"

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

Invitation to Advanced Monitoring and Evaluation for Development Results Workshop

[Jackson From FDC-K Africa]

___
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"

Strange error messages from xnb on dom0. What do they mean?

[Brian Buhrow]

hello.  Occasionally I see messages like the following from my 
FreeBSD-12.2/dom0 machine.
Is this related to the issue of the NetBSD domu's seeing bursts of oversized 
packets, which I assume
is caused by packets getting sent from the dom0 to the domu in batches rather 
than one at a
time, each with an interrupt signal, or, the xen equivalent?

On the domu's I see:
xennet0: discarding oversize frame (len=1518)

I see the following messages on the dom0, but not necessarily at the same time 
as the above
messages appear in the domu's.

Any ideas?
-thanks
-Brian


Apr 25 14:56:35 xen-lothlorien kernel: xnb(xnb_ring2pkt:1532): Unknown extra 
info type 255.  Discarding packet
Apr 25 14:56:35 xen-lothlorien kernel: xnb(xnb_dump_txreq:302): 
netif_tx_request index =0
Apr 25 14:56:35 xen-lothlorien kernel: xnb(xnb_dump_txreq:303): 
netif_tx_request.gref  =0
Apr 25 14:56:35 xen-lothlorien kernel: xnb(xnb_dump_txreq:304): 
netif_tx_request.offset=0
Apr 25 14:56:35 xen-lothlorien kernel: xnb(xnb_dump_txreq:305): 
netif_tx_request.flags =8
Apr 25 14:56:35 xen-lothlorien kernel: xnb(xnb_dump_txreq:306): 
netif_tx_request.id=69
Apr 25 14:56:35 xen-lothlorien kernel: xnb(xnb_dump_txreq:307): 
netif_tx_request.size  =1000
Apr 25 14:56:35 xen-lothlorien kernel: xnb(xnb_dump_txreq:302): 
netif_tx_request index =1
Apr 25 14:56:35 xen-lothlorien kernel: xnb(xnb_dump_txreq:303): 
netif_tx_request.gref  =255
Apr 25 14:56:35 xen-lothlorien kernel: xnb(xnb_dump_txreq:304): 
netif_tx_request.offset=0
Apr 25 14:56:35 xen-lothlorien kernel: xnb(xnb_dump_txreq:305): 
netif_tx_request.flags =0
Apr 25 14:56:35 xen-lothlorien kernel: xnb(xnb_dump_txreq:306): 
netif_tx_request.id=0
Apr 25 14:56:35 xen-lothlorien kernel: xnb(xnb_dump_txreq:307): 
netif_tx_request.size  =0
Apr 25 14:56:35 xen-lothlorien kernel: xnb(xnb_rxpkt2rsp:2066): Got error -1 
for hypervisor gnttab_copy status
___
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: [SUSPECTED SPAM]Re: HEADS UP: FreeBSD/Xen dom0 UEFI support

[Roger Pau Monné via freebsd-xen]

On Sun, Apr 25, 2021 at 05:10:44PM -0600, Stephen Walker-Weinshenker wrote:
> On Thu, Apr 22, 2021 at 12:58 AM Roger Pau Monné 
> wrote:
> 
> > On Wed, Apr 21, 2021 at 08:32:18PM -0600, Stephen Walker-Weinshenker wrote:
> > > Hello Roger:
> > >
> > > Thank you for your work on this. I am new to Xen and FreeBSD but am
> > willing
> > > to help test this and get it in a release version.
> > >
> > > I have 3 Intel NUC 8v5PNK that I am planning on using for Xen hosts, but
> > > they can only boot in UEFI mode (intel disabled BIOS booting per their
> > > official documentation even though it is still an option in the BIOS
> > > /shrug). Until this patch came along I could not get any Xen distribution
> > > to boot since they all require BIOS mode.
> > >
> > > I have 2 of the 3 NUCS running 14.0-CURRENT at git commit
> > > 55fc118be8f0cd20e2123cfd2728c5f32317a9fa (after your patch was merged)
> > and
> > > I have attempted to follow the instructions at
> > >
> > https://docs.freebsd.org/en_US.ISO8859-1/books/handbook/virtualization-host-xen.html
> > > in order to get the Xen kernel booting. Unfortunately, when I rebooted
> > > after making the changes, I get an error saying:
> > >
> > > >Loading Xen kernel...
> > > >Failed to load Xen kernel '/boot/xen'
> > > >can't load 'kernel'
> > > >
> > > >can't load 'kernel'
> >
> > Did you update the loader on the EFI partition?
> >
> > After an installworld on my box I would usually do:
> >
> > # mount -t msdosfs /dev/ada0p1 /mnt/
> > # cp /boot/loader.efi /mnt/EFI/freebsd/loader.efi
> > # umount /mnt
> >
> > To update the EFI loader. You might have to check the output of
> > `efibootmgr -v`to make sure you are replacing the correct loader. I
> > guess there must also be a way to do this with efibootmgr.
> >
> > For whatever reason my EFI partition nvd0p1 was already mounted at
> /boot/efi,
> so my copy command was
> # cp -f /boot/loader.efi /boot/efi/efi/freebsd/loader.efi
> 
> I did this prior to the last reboot after changing the boot config as
> recommended by
> 
> This fixed the issue of the xen kernel not booting on one of the boxes.
> (did the copy prior to the final reboot) Looks like I will have to
> reinstall the OS on the other one (not a big deal)
> 
> Now, I am just getting a blank screen on boot. I am unable to ssh into the
> Dom0 either.

What's your Xen command line? (ie: xen_cmdline string in
loader.conf)

Which version of Xen are you using?

Do you have serial output available on those boxes? That might help
get some messages if everything else fails.

Roger.
___
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: [SUSPECTED SPAM]Re: HEADS UP: FreeBSD/Xen dom0 UEFI support

[Stephen Walker-Weinshenker]

On Thu, Apr 22, 2021 at 12:58 AM Roger Pau Monné 
wrote:

> On Wed, Apr 21, 2021 at 08:32:18PM -0600, Stephen Walker-Weinshenker wrote:
> > Hello Roger:
> >
> > Thank you for your work on this. I am new to Xen and FreeBSD but am
> willing
> > to help test this and get it in a release version.
> >
> > I have 3 Intel NUC 8v5PNK that I am planning on using for Xen hosts, but
> > they can only boot in UEFI mode (intel disabled BIOS booting per their
> > official documentation even though it is still an option in the BIOS
> > /shrug). Until this patch came along I could not get any Xen distribution
> > to boot since they all require BIOS mode.
> >
> > I have 2 of the 3 NUCS running 14.0-CURRENT at git commit
> > 55fc118be8f0cd20e2123cfd2728c5f32317a9fa (after your patch was merged)
> and
> > I have attempted to follow the instructions at
> >
> https://docs.freebsd.org/en_US.ISO8859-1/books/handbook/virtualization-host-xen.html
> > in order to get the Xen kernel booting. Unfortunately, when I rebooted
> > after making the changes, I get an error saying:
> >
> > >Loading Xen kernel...
> > >Failed to load Xen kernel '/boot/xen'
> > >can't load 'kernel'
> > >
> > >can't load 'kernel'
>
> Did you update the loader on the EFI partition?
>
> After an installworld on my box I would usually do:
>
> # mount -t msdosfs /dev/ada0p1 /mnt/
> # cp /boot/loader.efi /mnt/EFI/freebsd/loader.efi
> # umount /mnt
>
> To update the EFI loader. You might have to check the output of
> `efibootmgr -v`to make sure you are replacing the correct loader. I
> guess there must also be a way to do this with efibootmgr.
>
> For whatever reason my EFI partition nvd0p1 was already mounted at
/boot/efi,
so my copy command was
# cp -f /boot/loader.efi /boot/efi/efi/freebsd/loader.efi

I did this prior to the last reboot after changing the boot config as
recommended by

This fixed the issue of the xen kernel not booting on one of the boxes.
(did the copy prior to the final reboot) Looks like I will have to
reinstall the OS on the other one (not a big deal)

Now, I am just getting a blank screen on boot. I am unable to ssh into the
Dom0 either.

Thank you for your help thus far.
___
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: [SUSPECTED SPAM]Re: HEADS UP: FreeBSD/Xen dom0 UEFI support

[Roger Pau Monné via freebsd-xen]

On Wed, Apr 21, 2021 at 08:32:18PM -0600, Stephen Walker-Weinshenker wrote:
> Hello Roger:
> 
> Thank you for your work on this. I am new to Xen and FreeBSD but am willing
> to help test this and get it in a release version.
> 
> I have 3 Intel NUC 8v5PNK that I am planning on using for Xen hosts, but
> they can only boot in UEFI mode (intel disabled BIOS booting per their
> official documentation even though it is still an option in the BIOS
> /shrug). Until this patch came along I could not get any Xen distribution
> to boot since they all require BIOS mode.
> 
> I have 2 of the 3 NUCS running 14.0-CURRENT at git commit
> 55fc118be8f0cd20e2123cfd2728c5f32317a9fa (after your patch was merged) and
> I have attempted to follow the instructions at
> https://docs.freebsd.org/en_US.ISO8859-1/books/handbook/virtualization-host-xen.html
> in order to get the Xen kernel booting. Unfortunately, when I rebooted
> after making the changes, I get an error saying:
> 
> >Loading Xen kernel...
> >Failed to load Xen kernel '/boot/xen'
> >can't load 'kernel'
> >
> >can't load 'kernel'

Did you update the loader on the EFI partition?

After an installworld on my box I would usually do:

# mount -t msdosfs /dev/ada0p1 /mnt/
# cp /boot/loader.efi /mnt/EFI/freebsd/loader.efi
# umount /mnt

To update the EFI loader. You might have to check the output of
`efibootmgr -v`to make sure you are replacing the correct loader. I
guess there must also be a way to do this with efibootmgr.

Roger.
___
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: FreeBSD/Xen dom0 UEFI support

[Stephen Walker-Weinshenker]

Hello Roger:

Thank you for your work on this. I am new to Xen and FreeBSD but am willing
to help test this and get it in a release version.

I have 3 Intel NUC 8v5PNK that I am planning on using for Xen hosts, but
they can only boot in UEFI mode (intel disabled BIOS booting per their
official documentation even though it is still an option in the BIOS
/shrug). Until this patch came along I could not get any Xen distribution
to boot since they all require BIOS mode.

I have 2 of the 3 NUCS running 14.0-CURRENT at git commit
55fc118be8f0cd20e2123cfd2728c5f32317a9fa (after your patch was merged) and
I have attempted to follow the instructions at
https://docs.freebsd.org/en_US.ISO8859-1/books/handbook/virtualization-host-xen.html
in order to get the Xen kernel booting. Unfortunately, when I rebooted
after making the changes, I get an error saying:

>Loading Xen kernel...
>Failed to load Xen kernel '/boot/xen'
>can't load 'kernel'
>
>can't load 'kernel'

See screenshot at the link https://imgur.com/a/65LltnZ.

If I unload the kernel, unset xen_kernel and boot /boot/kernel/kernel I can
get back into normal freebsd and login normally.

Looking at the output of file, it appears that the xen kernel is a 32-bit
executable while kernel/kernel is 64-bit.

I have 4.14.1_1 of the xen kernel installed from pkgs.

Please let me know if you need any additional information or want me to
test something. As you can see, i am invested in this solution and would
love to get xen and UEFI and FreeBSD working seamlessly.

Thank you again


-- 
Stephen Walker-Weinshenker
sww1...@gmail.com
___
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: 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

Re: Corruption in xenstored tdb file?

[Roger Pau Monné via freebsd-xen]

On Wed, Mar 17, 2021 at 04:13:03PM -0700, Brian Buhrow wrote:
>   hello Roger.  I've successfully compiled the kernel with your patch and 
> installed it.
> Now, both the NetBSD-5 and NetBSD-current VM's boot with full working 
> networks.  
> Also, FreeBSD-12 works as a a pvh guest with full networking.
> I applied your patch to 12-stable, so if you commit this fix, if you could 
> request a pullup to
> FreeBSD-12, that would be great!

Thanks for the testing, will commit early next week. Let's see if I
have some time to look at your other issue also.

Roger.
___
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: 12.2-STABLE r369477 dom0 creash on xen-kernel-4.14.1_1

[Roger Pau Monné via freebsd-xen]

On Fri, Mar 19, 2021 at 11:59:49PM +, Marcin Cieslak wrote:
> 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

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.

Thanks, Roger.

[0] 
https://docs.freebsd.org/en_US.ISO8859-1/books/handbook/virtualization-host-xen.html
___
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"

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: Corruption in xenstored tdb file?

[Brian Buhrow]

hello Roger.  I've successfully compiled the kernel with your patch and 
installed it.
Now, both the NetBSD-5 and NetBSD-current VM's boot with full working networks. 
 
Also, FreeBSD-12 works as a a pvh guest with full networking.
I applied your patch to 12-stable, so if you commit this fix, if you could 
request a pullup to
FreeBSD-12, that would be great!
-thanks
-Brian

___
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"

Issue with packet framing on xnb(4) connections and NetBSD domus

[Brian Buhrow]

hello.  I've noticed that on my Xen server, running 
FreeBSD-12.2/Xen-4.14.0, I see a lot
of messages like the following from my NetBSD-5 and NetBSD-current domu's: 
xennet0: discarding oversize frame (len=1518)

They happen when network traffic is heavy and when traffic is coming from a 
physical switch in
the same vlan as the domu's.  Since I don't think packets are  actually 
oversized on the wire,
the Cisco switch managing this network does not report any giant packets, I 
think this is a
software problem either on the NetBSD domu's, or the FreeBSD dom0.  Since I've 
been running
these same NetBSD domu setups on a machine where NetBSD is the dom0, I think 
this is an issue
with the xnb(4) or netback.c  driver.  Specifically, it looks like it 
concatinates multiple
packets together before notifying the domu that there is traffic available.  
Perhaps that is by
design, since I cannot reproduce the issue on a FreeBSD-domu running on the 
same FreeBSD-dom0
machine.  In either case, while things are usable, it creates a very noisy log 
on the
NetBSD-domu machines.  Does the xnb(4) driver forward multiple packets to the 
domu front ends
and set the length of the message to the sum of the lengths of all the packets 
it's forwarding,
leaving it to the domu front end driver to separate the packets on reception?  
Is there a
parameter that can be set on a per-domu basis to say whether you want
multiple-packets-per-transfer or not from the dom0?

-thanks
-Brian

___
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: Corruption in xenstored tdb file?

[Brian Buhrow]

hello Roger.  I will compile a kernel with your patch and see how it 
flies.
I'm sending a second e-mail which describes a problem which I also think is 
related to the
netback code.  But, rather than cloudying this issue with other issues, I'll 
detail it on a
separate thread.
I'll let you know the results of this patch in a few days as I need to build a 
source build
freebsd host.
-thanks
-Brian

___
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: Corruption in xenstored tdb file?

[Roger Pau Monné via freebsd-xen]

On Tue, Mar 16, 2021 at 12:06:32AM -0700, Brian Buhrow wrote:
>   hello.  Following up on this further, it seems there may be a timing 
> issue related to this
> after all.  If I bring up a NetBSD-5.2 VM, the VM comes up  without a problem 
> and xennet0 works
> just as it should.  I can do this time and time again without any trouble.
> However, if I bring up a NetBSD-99.77 (current as of January 28 2021), I get 
> the behavior I
> described in the previous message.  It's obviously some kind of race 
> condition, since if I
> reboot the NetBSD-current VM several times, I can get it to come up with a 
> network interface
> occasionally.  However, not enough to make it usable.  
>   Also, since I wrote last, I updated to 12.2-release--p4, just to see if 
> that made things
> better.  It did not.  I suspect, but don't know for sure, that the issue is 
> that NetBSD-current
> is issuing commands on the xenbus faster than it did in NetBSD-5.  If that's 
> true, then I think
> the problem lies with FreeBSD, as, in my view, a VM guest shouldn't be able 
> to trigger a race
> condition in the host side of the server, which is what appears to be 
> happening here.  
>   Is there a way to get a trace of the communications between the domU's 
> and the dom0 so I
> can see the differences between what NetBSD used to do  and what it does 
> today?

So I've taken a look and it seems NetBSD now switches to the
XenbusStateInitialised state without having written some of the
configuration data required by netback. It's not clear to me whether
this is a bug in NetBSD, or a bug in FreeBSD netback. In any case
the patch below should fix it, can you apply it to your kernel
sources, recompile and test?

The above fix changes the behavior of FreeBSD netback to only try to
fetch the data when the frontend switches to the Connected state, this
seems to be inline with what Linux netback does, so in any case I
think it's a change worth making.

Thanks, Roger.
---8<---
diff --git a/sys/dev/xen/netback/netback.c b/sys/dev/xen/netback/netback.c
index 44159f60d996..29efd76430c7 100644
--- a/sys/dev/xen/netback/netback.c
+++ b/sys/dev/xen/netback/netback.c
@@ -1392,8 +1392,8 @@ xnb_frontend_changed(device_t dev, XenbusState 
frontend_state)
 
switch (frontend_state) {
case XenbusStateInitialising:
-   break;
case XenbusStateInitialised:
+   break;
case XenbusStateConnected:
xnb_connect(xnb);
break;

___
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: Corruption in xenstored tdb file?

[Brian Buhrow]

hello.  Following up on this further, it seems there may be a timing 
issue related to this
after all.  If I bring up a NetBSD-5.2 VM, the VM comes up  without a problem 
and xennet0 works
just as it should.  I can do this time and time again without any trouble.
However, if I bring up a NetBSD-99.77 (current as of January 28 2021), I get 
the behavior I
described in the previous message.  It's obviously some kind of race condition, 
since if I
reboot the NetBSD-current VM several times, I can get it to come up with a 
network interface
occasionally.  However, not enough to make it usable.  
Also, since I wrote last, I updated to 12.2-release--p4, just to see if 
that made things
better.  It did not.  I suspect, but don't know for sure, that the issue is 
that NetBSD-current
is issuing commands on the xenbus faster than it did in NetBSD-5.  If that's 
true, then I think
the problem lies with FreeBSD, as, in my view, a VM guest shouldn't be able to 
trigger a race
condition in the host side of the server, which is what appears to be happening 
here.  
Is there a way to get a trace of the communications between the domU's 
and the dom0 so I
can see the differences between what NetBSD used to do  and what it does today?

-thanks
-Brian

___
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: Corruption in xenstored tdb file?

[Brian Buhrow]

hello.  Following up on this thread, I'm still having a problem with 
starting domains
under FreebSD-12.1 as dom0 after ensuring that /var/lib/xenstoredb/tdb is 
deleted on startup.
The first domu starts just fine, an old NetBSD-5.2 domain.  the second one, 
however, a
NetBSD-current as of January 19 or so, however, starts fine but doesn't have a 
network
interface by the time it gets to multiuser mode.  The errors on the back end 
look like:

xnb(xnb_probe:1129): Claiming device 1, xnb
xnb(xnb_attach:1273): Attaching to backend/vif/10/0
xnb(xnb_frontend_changed:1397): frontend_state=Initialising, xnb_state=InitWait
xnb10.0: link state changed to DOWN
xnb10.0: link state changed to UP
xnb10.0: link state changed to DOWN
xnb10.0: promiscuous mode enabled
xnb10.0: link state changed to UP
nd6_dad_timer: cancel DAD on xnb10.0 because of ND6_IFF_IFDISABLED.
xnb(xnb_frontend_changed:1397): frontend_state=Initialised, xnb_state=InitWait
xnb1: Error 2 Unable to retrieve ring information from frontend 
/local/domain/10/device/vif/0.  Unable to connect.
xnb1: Fatal error. Transitioning to Closing State
xnb(xnb_frontend_changed:1397): frontend_state=Connected, xnb_state=Closing
xnb(xnb_connect_comms:793): rings connected!
xnb(xnb_frontend_changed:1397): frontend_state=Closed, xnb_state=Connected

In looking at the code, it looks like this is failing somewhere in xs_gather() 
in 
syskj/dev/xen/xenstore/xenstore.c

I thought it was some kind of race condition at first, because I could stop the 
domains that
didn't come up with a network interface, wait a bit, restar them and find they 
worked.  
Now, however, having upgraded to 12.1-P13, I find that I'm consistently getting 
this failure
regardless of how often I destroy and create the domain.

Any ideas on what might be going on?
-thanks
-Brian
___
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: [PROMOTIONAL]XEN with UEFI guest

[Roger Pau Monné via freebsd-xen]

On Sun, Mar 14, 2021 at 11:30:33PM +0300, Oleg Ginzburg wrote:
> Hi,
> 
> I recently tried to use the Xen dom0 through UEFI loader and, finally, it
> worked! (Thanks to Roger).
> 
> Now I try to use UEFI boot method in the guest and for some reason, the
> domain does not start.
> The documentation says that this option requires extra config params, so I
> added an option to port:
> 
> --
> root@home2:/usr/ports/sysutils/xen-tools# svnlite diff
> Index: Makefile
> ===
> --- Makefile(revision 568404)
> +++ Makefile(working copy)
> @@ -21,12 +21,14 @@
> BUILD_DEPENDS= seabios>0:misc/seabios
> RUN_DEPENDS=   seabios>0:misc/seabios
> 
> -OPTIONS_DEFINE=DOCS SPICE
> +OPTIONS_DEFINE=DOCS SPICE OVMF
> OPTIONS_DEFAULT=   DOCS
> OPTIONS_SUB=   yes
> 
> SPICE_DESC=Enable SPICE protocol for QEMU
> +OVMF_DESC= Enable OVMF support
> SPICE_CONFIGURE_WITH=  extra-qemuu-configure-args="--enable-spice"
> +OVMF_CONFIGURE_WITH=   extra-qemuu-configure-args="--enable-ovmf"

You are adding the option to the QEMU configure script instead of the
Xen one, you likely want:

OVMF_CONFIGURE_WITH=   enable-ovmf

Albeit I think that won't work out of the box because OVMF will fail
to build with llvm. So you will likely have to build ovmf separately
(like we do for seabios) using gcc and then include it here with
--with-system-ovmf=...

Thanks, Roger.
___
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"

XEN with UEFI guest

[Oleg Ginzburg]

Hi,

I recently tried to use the Xen dom0 through UEFI loader and, finally, it
worked! (Thanks to Roger).

Now I try to use UEFI boot method in the guest and for some reason, the
domain does not start.
The documentation says that this option requires extra config params, so I
added an option to port:

--
root@home2:/usr/ports/sysutils/xen-tools# svnlite diff
Index: Makefile
===
--- Makefile(revision 568404)
+++ Makefile(working copy)
@@ -21,12 +21,14 @@
BUILD_DEPENDS= seabios>0:misc/seabios
RUN_DEPENDS=   seabios>0:misc/seabios

-OPTIONS_DEFINE=DOCS SPICE
+OPTIONS_DEFINE=DOCS SPICE OVMF
OPTIONS_DEFAULT=   DOCS
OPTIONS_SUB=   yes

SPICE_DESC=Enable SPICE protocol for QEMU
+OVMF_DESC= Enable OVMF support
SPICE_CONFIGURE_WITH=  extra-qemuu-configure-args="--enable-spice"
+OVMF_CONFIGURE_WITH=   extra-qemuu-configure-args="--enable-ovmf"
SPICE_BUILD_DEPENDS=   spice-protocol>=0.12.10:devel/spice-protocol
SPICE_LIB_DEPENDS= libspice-server.so:devel/libspice-server

--

However, the guest does not start if I add the necessary option to the
configuration file:

bios='ovmf'


In addition, I do not see anything suspicious in the log:
https://pastebin.com/Ss2YK25b

Any help and tip is welcome.
___
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"

Invitation to FDC training Programme May 2021

[FDC Training]

___
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"

HEADS UP: FreeBSD/Xen dom0 UEFI support

[Roger Pau Monné via freebsd-xen]

Hello,

Since commit 97527e9c4fd37140 on main branch FreeBSD should be able to
boot and work as a Xen dom0 from UEFI.

Booting from UEFI also requires the usage of xen-kernel 4.14.1_1,
previous versions of xen-kernel won't boot correctly under UEFI.

The way to setup the system is exactly the same as when using BIOS,
xen_kernel and xen_cmdline options should be set in loader.conf, see:

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

I don't have plans to backport for 13.0, but will consider backporting
to stable/13 at a later point if there are no issues, so the
functionality could be used in 13.1.

This has been tested on a single Intel box with UEFI, some wider
testing would be appreciated.

Thanks to tsoome, imp and kib for the reviews.

Roger.
___
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"

Invitation to Research Design, mobile data collection, mapping and data analysis using NVIVO and SPSS training March 2021

[FDC Training]

___
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: Corruption in xenstored tdb file?

[Brian Buhrow]

Hello.  Yes, I think /var/run/xen or /var/run/xenstored is highly 
appropriate.
-thanks
-Brian

On Jan 29,  1:40pm, Roger Pau =?utf-8?B?TW9ubsOp?= wrote:
} Subject: Re: Corruption in xenstored tdb file?
} On Thu, Jan 28, 2021 at 05:11:04PM -0800, Brian Buhrow wrote:
} > hello.  Recently One of my FreeBSD-xen servers went down hard due to a 
power failure.
} > When it came back up, one of the domus' came up, but with no network 
interface.  Dmesg
} > messages show the following errors.  To fix the issue, I removed the 
/var/lib/xenstored/tdb
} > file and rebooted.  Before that, I couldn't get this domu to boot with a 
network interface.  My
} > question is, is it reasonable to take this action when such an error occurs 
and, further, might
} > it be better to remove that file before attempting to start xen on reboots, 
just in case
} > something didn't go down cleanly?
} 
} Yes, I think it should be placed in a directory that's cleaned on
} reboot, it's not expected that people have to go clean this
} themselves.
} 
} Do you have any recommendation where this should be placed?
} 
} /var/run/xen would seem like a suitable place.
} 
} Thanks, Roger
>-- End of excerpt from Roger Pau =?utf-8?B?TW9ubsOp?=


___
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"

Disruptions to PVH dom0 in main and stable/13 branches

[Roger Pau Monné]

Hello,

If you are not based on the main or the stable/13 branches you can
skip the email below.

There have been some bootloader changes in main and stable/13 branches
that prevented booting a FreeBSD/Xen PVH Dom0. A fix has been committed
to main and should hopefully be backported to stable/13 in due time,
it's:

b6d85a5f51e4 stand/multiboot: adjust the protocol between loader and kernel

That however will require that you also use a Xen package version
greater or equal to 4.14.1_0. I've just added those to the ports
repository:

r563208: emulators/xen-kernel,sysutils/xen-tools: update to 4.14.1

However binary packages will take some time to appear. In the mean
time, if you wish to use a Xen dom0 please make sure to run a build of
FreeBSD that has the above commit applied, and to build the Xen
packages from the ports tree yourself (while a binary one is not
available).

Sorry for the inconvenience.
___
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: Corruption in xenstored tdb file?

[Roger Pau Monné via freebsd-xen]

On Thu, Jan 28, 2021 at 05:11:04PM -0800, Brian Buhrow wrote:
>   hello.  Recently One of my FreeBSD-xen servers went down hard due to a 
> power failure.
> When it came back up, one of the domus' came up, but with no network 
> interface.  Dmesg
> messages show the following errors.  To fix the issue, I removed the 
> /var/lib/xenstored/tdb
> file and rebooted.  Before that, I couldn't get this domu to boot with a 
> network interface.  My
> question is, is it reasonable to take this action when such an error occurs 
> and, further, might
> it be better to remove that file before attempting to start xen on reboots, 
> just in case
> something didn't go down cleanly?

Yes, I think it should be placed in a directory that's cleaned on
reboot, it's not expected that people have to go clean this
themselves.

Do you have any recommendation where this should be placed?

/var/run/xen would seem like a suitable place.

Thanks, Roger
___
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"

Corruption in xenstored tdb file?

[Brian Buhrow]

hello.  Recently One of my FreeBSD-xen servers went down hard due to a 
power failure.
When it came back up, one of the domus' came up, but with no network interface. 
 Dmesg
messages show the following errors.  To fix the issue, I removed the 
/var/lib/xenstored/tdb
file and rebooted.  Before that, I couldn't get this domu to boot with a 
network interface.  My
question is, is it reasonable to take this action when such an error occurs 
and, further, might
it be better to remove that file before attempting to start xen on reboots, 
just in case
something didn't go down cleanly?
-thanks
-Brian

Jan 28 02:07:17 xen-lothlorien kernel: xnb(xnb_frontend_changed:1397): 
frontend_state=Initialised, xnb_state=InitWait
Jan 28 02:07:17 xen-lothlorien kernel: xnb1: Error 2 Unable to retrieve ring 
information from frontend /local/domain/7/device/vif/0.  Unable to connect.
Jan 28 02:07:17 xen-lothlorien kernel: xnb1: Fatal error. Transitioning to 
Closing State
Jan 28 02:07:17 xen-lothlorien kernel: xnb(xnb_frontend_changed:1397): 
frontend_state=Connected, xnb_state=Closing
Jan 28 02:07:17 xen-lothlorien kernel: xnb(xnb_connect_comms:793): rings 
connected!
Jan 28 02:07:17 xen-lothlorien kernel: xnb(xnb_frontend_changed:1397): 
frontend_state=Closed, xnb_state=Connected
___
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"

BeeCoating "os5cuwkg"

[BeeCoating]

Dear ❤️ Do you like my photos? Click here: http://bit.do/fMWhk?mdn ❤️,

Thank you for contacting BeeCoating the largest supplier of water-based Inkjet 
self adhesive materials.

We will get back to you quickly !

All the best

-- 
This e-mail has been sent via the contact form of BeeCoating 
(http://beecoating.com)

___
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: either xen or custom

[Lizbeth Mutterhunt, PhD]

Op Dienstag, 19. Jänner 2021 18:05:25 CET schreef u:
> Adding freebsd-xen mailing list for reference.
did this, too. 
 
> On Tue, Jan 19, 2021 at 05:04:21PM +0100, Lizbeth Mutterhunt, PhD wrote:
> > Op Dienstag, 19. Jänner 2021 15:06:45 CET schreef u:
> > > On Fri, Jan 15, 2021 at 3:46 PM Lizbeth Mutterhunt, PhD
> > > 
> > >  wrote:
> > > > Op Donnerstag, 14. Jänner 2021 09:21:09 CET schreef u:
> > Hi Roger,
> > 
> > just to introduce myself a bit:
> > 
> > !!!thx for your reply and concerns!!!
> > 
> > I keep in mind that this certain kind of support isn't self-understanding
> > and will one day be to your advantage, too! For myself: I ask to much and
> > answer too little in forums, etc., as I know what to do in certain kind
> > of matters but still too lazy to give a tipp or to post a reply as many
> > others does.
> > 
> > I'm good in linux, especially Arch Linux, doing projects at the reborn
> > BeOS, Linux and now as my main system on
> > 
> > [CODE]
> > sudo sysctl hw.model hw.machine hw.ncpu
> > Wachtwoord:
> > hw.model: Intel(R) Celeron(R) CPU 867 @ 1.30GHz
> 
> So your CPU doesn't support VT-d (AKA IOMMU), and won't be able to
> run FreeBSD/Xen sadly. This is a hardware limitation and there's
> nothing that can be done. The only way to run Xen on that box is to
> use Linux in PV mode, which FreeBSD doesn't support.
no, XEN stays here at BSD! 
bhyve is this fast as tmc!
 
> You can check the CPU features at:
> 
> https://ark.intel.com/content/www/us/en/ark/products/63918/intel-celeron-pro
> cessor-867-2m-cache-1-30-ghz.html
> Search for VT-d.
this is the output for information purpose:

"Intel® Virtualization Technology for Directed I/O (VT-d) continues from the 
existing support for IA-32 (VT-x) and Itanium® processor (VT-i) virtualization 
adding new support for I/O-device virtualization. Intel VT-d can help end 
users improve security and reliability of the systems and also improve 
performance of I/O devices in virtualized environments."
 
> If you want to run FreeBSD/Xen you will need a newer CPU, sadly
> there's no way around that.
aeh! bulls*! but pitty, pitty, you can't request from an 7 year old machine 
everything you want. so heaven stays cloudy but RAPTOR9 willl do? no troubles 
with (U)EFI there?

> > > > > Do you have a serial console attached to the box so that we could
> > > > > see the log of Xen and FreeBSD booting?
> > > > 
> > > > how to? every time I boot into xen I have to zpool import -f and mount
> > > > it
> > > > from rescue CD. Is there a log from the last boot somewhere? I
> > > > duckduckgo'd a bit but couldn't find anything else than the dmesg. As
> > > > it
> > > > is not a kernel crash there's nothing in /var/crash and on /var/run I
> > > > have the running boot inside.
> > > 
> > > You would need to plug a null-modem into the serial port of your box,
> > > or alternatively use something like SoL (Serial over LAN) if your box
> > > supports it.
> > 
> > could you plz. explain this a bit more exactly? I don't have a LAN-switch
> > yet but it's planned for connecting the Raspi4 and my upcoming RAPTOR9
> > machine at easter and to have a "night-light" with blinking RX/TX - LEDS!
> > :-)
> Getting serial out of a box is the only way to diagnose early boot
> problems (ie: kernel issues). See:
> 
> https://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/serialconsole-set
> up.html
ok, this is something like ssh or things concerning booting without monitor or 
keybd, understood! 

> That way you can get the output of FreeBSD or Xen booting in text
> mode, so that you can for example paste it on an email when things go
> wrong.
> 

so heaven stays a place on earth and clouds change to violet! 

thx anyway, 
> Roger.
Lizbeth


___
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: either xen or custom

[Roger Pau Monné]

Adding freebsd-xen mailing list for reference.

On Tue, Jan 19, 2021 at 05:04:21PM +0100, Lizbeth Mutterhunt, PhD wrote:
> Op Dienstag, 19. Jänner 2021 15:06:45 CET schreef u:
> > On Fri, Jan 15, 2021 at 3:46 PM Lizbeth Mutterhunt, PhD
> > 
> >  wrote:
> > > Op Donnerstag, 14. Jänner 2021 09:21:09 CET schreef u:
> Hi Roger, 
> 
> just to introduce myself a bit:
> 
> !!!thx for your reply and concerns!!! 
> 
> I keep in mind that this certain kind of support isn't self-understanding and 
> will one day be to your advantage, too! For myself: I ask to much and answer 
> too little in forums, etc., as I know what to do in certain kind of matters 
> but still too lazy to give a tipp or to post a reply as many others does. 
> 
> I'm good in linux, especially Arch Linux, doing projects at the reborn BeOS, 
> Linux and now as my main system on 
> 
> [CODE]
> sudo sysctl hw.model hw.machine hw.ncpu
> Wachtwoord: 
> hw.model: Intel(R) Celeron(R) CPU 867 @ 1.30GHz

So your CPU doesn't support VT-d (AKA IOMMU), and won't be able to
run FreeBSD/Xen sadly. This is a hardware limitation and there's
nothing that can be done. The only way to run Xen on that box is to
use Linux in PV mode, which FreeBSD doesn't support.

You can check the CPU features at:

https://ark.intel.com/content/www/us/en/ark/products/63918/intel-celeron-processor-867-2m-cache-1-30-ghz.html

Search for VT-d.

If you want to run FreeBSD/Xen you will need a newer CPU, sadly
there's no way around that.

> > > > Do you have a serial console attached to the box so that we could
> > > > see the log of Xen and FreeBSD booting?
> > > 
> > > how to? every time I boot into xen I have to zpool import -f and mount it
> > > from rescue CD. Is there a log from the last boot somewhere? I
> > > duckduckgo'd a bit but couldn't find anything else than the dmesg. As it
> > > is not a kernel crash there's nothing in /var/crash and on /var/run I
> > > have the running boot inside.
> 
> > You would need to plug a null-modem into the serial port of your box,
> > or alternatively use something like SoL (Serial over LAN) if your box
> > supports it.
> 
> could you plz. explain this a bit more exactly? I don't have a LAN-switch yet 
> but it's planned for connecting the Raspi4 and my upcoming RAPTOR9 machine at 
> easter and to have a "night-light" with blinking RX/TX - LEDS! :-)

Getting serial out of a box is the only way to diagnose early boot
problems (ie: kernel issues). See:

https://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/serialconsole-setup.html

That way you can get the output of FreeBSD or Xen booting in text
mode, so that you can for example paste it on an email when things go
wrong.

Roger.
___
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: Re: either xen or custom

[Roger Pau Monné]

On Fri, Jan 15, 2021 at 3:46 PM Lizbeth Mutterhunt, PhD
 wrote:
>
> Op Donnerstag, 14. Jänner 2021 09:21:09 CET schreef u:
> > On Sun, Dec 13, 2020 at 12:11:40AM +0100, lizbethmutterh...@gmail.com wrote:
> > > to make a long story short: either I get a lock (hard to avoid, not to be
> > > unlimited with ulimit -l unlimited) or a boot of xen and a blank screen
> > > with reboot after a 10 seconds with vga=current.
> >
> > Hello,
> Hello Roger,
>
> > Sorry for the delay on the reply. I'm afraid I will need more info in
> > order to help diagnose your issue.
> no matter, was occupied other ways; using VirtualBox at the moment, slow and
> the hypervisor tends to make long waiting-times...
>
> > How do you get the lock that you mention? Is it booting Xen, or just
> > plain FreeBSD?
> It's booting XEN, but not the CURRENT-kernel afterwards or it boots the
> CURRENT but not xen. I have in /boot/loader.conf
>
> xen_kernel="/boot/xen"
> xen_cmdline="dom0_mem=4048M dom0_max_vcpus=4 dom0=pvh com1=115200,8n1
> guest_loglvl=all loglvl=all"
> iommu="force,no-intremap"

The iommu=... option should either be inside the xen_cmdline or
removed, it's not an option of loader.conf.

> if_tap_load="YES"
> console=vga,com1

console= should also be inside the xen_cmdline= option, not here as a
separate line here.

Your xen_cmdline should be:

xen_cmdline="dom0_mem=4048M dom0_max_vcpus=4 dom0=pvh com1=115200,8n1
guest_loglvl=all loglvl=all console=vga,com1 noreboot"

Note it's all a single line.

> boot_multicons="YES"
> boot_serial="YES"
> console="comconsole,vidconsole"
> vmm_load="YES"
> vga=current
>
> and in /etc/rc.conf:
>
> xencommons_enable="YES"
> cloned_interfaces="bridge0"
> ifconfig_bridge0="addm bge0 SYNCDHCP"
> ifconfig_bge0="up"
>
> sudo ulimit -l
> unlimited
>
> sudo uname -a
> FreeBSD freeBSD-CURRENT 13.0-CURRENT FreeBSD 13.0-CURRENT #5 r368997: Tue Jan
> 12 13:46:33 CET 2021 lizbeth@freeBSD-CURRENT:/usr/obj/usr/src/amd64.amd64/
> sys/LIZBETH  amd64
>
> it's a no-debug kernel!
>
> /etc/ttys
> xc0 "/usr/libexec/getty Pc" xterm   on  secure
>
>
> when booting without XEN I get the following with 'xl dmesg'
>
> xencall: error: Could not obtain handle on privileged command interface /dev/
> xen/privcmd: No such file or directory
> libxl: error: libxl.c:102:libxl_ctx_alloc: cannot open libxc handle: No such
> file or directory
> cannot init xl context

Right, without booting as Xen dom0 /dev/xen/privcmd is simply not there.

> a normal boot without xen is on pastebin (VERBOSE_SYSINIT=2)
>
> https://pastebin.com/RN1SYXdW
>
>
> > Do you have a serial console attached to the box so that we could
> > see the log of Xen and FreeBSD booting?
> how to? every time I boot into xen I have to zpool import -f and mount it from
> rescue CD. Is there a log from the last boot somewhere? I duckduckgo'd a bit
> but couldn't find anything else than the dmesg. As it is not a kernel crash
> there's nothing in /var/crash and on /var/run I have the running boot inside.

You would need to plug a null-modem into the serial port of your box,
or alternatively use something like SoL (Serial over LAN) if your box
supports it.

> Maybe you tell me how to show the log from the serial console; btw, I tried
> both ways, only serial, only bios or both --- no matter, xen's booting,
> screen's blanking for the "normal" kernel but nothing happens but a sudden
> reboot. Is it on the /var/* somewhere when booting from resucue?

There won't be any logs from Xen in the disk, because Xen has no
access to the disk at all.

When booting with Xen, do you see any error message on the screen?

I've added noreboot to the Xen command line above so that you can
maybe take a photo of the crash message if there's any?

Roger.
___
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"

Fwd: Re: either xen or custom

[Lizbeth Mutterhunt, PhD]

Op Donnerstag, 14. Jänner 2021 09:21:09 CET schreef u:
> On Sun, Dec 13, 2020 at 12:11:40AM +0100, lizbethmutterh...@gmail.com wrote:
> > to make a long story short: either I get a lock (hard to avoid, not to be
> > unlimited with ulimit -l unlimited) or a boot of xen and a blank screen
> > with reboot after a 10 seconds with vga=current.
>
> Hello,
Hello Roger, 

> Sorry for the delay on the reply. I'm afraid I will need more info in
> order to help diagnose your issue.
no matter, was occupied other ways; using VirtualBox at the moment, slow and 
the hypervisor tends to make long waiting-times... 

> How do you get the lock that you mention? Is it booting Xen, or just
> plain FreeBSD?
It's booting XEN, but not the CURRENT-kernel afterwards or it boots the 
CURRENT but not xen. I have in /boot/loader.conf

xen_kernel="/boot/xen"
xen_cmdline="dom0_mem=4048M dom0_max_vcpus=4 dom0=pvh com1=115200,8n1 
guest_loglvl=all loglvl=all"
iommu="force,no-intremap"
if_tap_load="YES"
console=vga,com1
boot_multicons="YES"
boot_serial="YES"
console="comconsole,vidconsole"
vmm_load="YES"
vga=current

and in /etc/rc.conf:

xencommons_enable="YES"
cloned_interfaces="bridge0"
ifconfig_bridge0="addm bge0 SYNCDHCP"
ifconfig_bge0="up"

sudo ulimit -l
unlimited

sudo uname -a
FreeBSD freeBSD-CURRENT 13.0-CURRENT FreeBSD 13.0-CURRENT #5 r368997: Tue Jan 
12 13:46:33 CET 2021 lizbeth@freeBSD-CURRENT:/usr/obj/usr/src/amd64.amd64/
sys/LIZBETH  amd64

it's a no-debug kernel!

/etc/ttys
xc0 "/usr/libexec/getty Pc" xterm   on  secure


when booting without XEN I get the following with 'xl dmesg'

xencall: error: Could not obtain handle on privileged command interface /dev/
xen/privcmd: No such file or directory
libxl: error: libxl.c:102:libxl_ctx_alloc: cannot open libxc handle: No such 
file or directory
cannot init xl context

a normal boot without xen is on pastebin (VERBOSE_SYSINIT=2)

https://pastebin.com/RN1SYXdW


> Do you have a serial console attached to the box so that we could
> see the log of Xen and FreeBSD booting?
how to? every time I boot into xen I have to zpool import -f and mount it from 
rescue CD. Is there a log from the last boot somewhere? I duckduckgo'd a bit 
but couldn't find anything else than the dmesg. As it is not a kernel crash 
there's nothing in /var/crash and on /var/run I have the running boot inside. 
Maybe you tell me how to show the log from the serial console; btw, I tried 
both ways, only serial, only bios or both --- no matter, xen's booting, 
screen's blanking for the "normal" kernel but nothing happens but a sudden 
reboot. Is it on the /var/* somewhere when booting from resucue? btw, the 
current images from beginning 2021 don't boot, turning root sign but blank 
screen, no boot menue but steady access to USB-stick. 

I thought that the XEN-log should be somewhere in the boot-directory but it's 
empty but asking for IUMMO support when using both consoles, when serializing 
xen boots successfully but rebooting afterwards. 


 
> Thanks, Roger.
I have to tell you thank you. 

byebye, 

lizbeth--- Begin Message ---
Op Donnerstag, 14. Jänner 2021 09:21:09 CET schreef u:
> On Sun, Dec 13, 2020 at 12:11:40AM +0100, lizbethmutterh...@gmail.com wrote:
> > to make a long story short: either I get a lock (hard to avoid, not to be
> > unlimited with ulimit -l unlimited) or a boot of xen and a blank screen
> > with reboot after a 10 seconds with vga=current.
> 
> Hello,
Hello Roger, 

> Sorry for the delay on the reply. I'm afraid I will need more info in
> order to help diagnose your issue.
no matter, was occupied other ways; using VirtualBox at the moment, slow and 
the hypervisor tends to make long waiting-times... 

> How do you get the lock that you mention? Is it booting Xen, or just
> plain FreeBSD?
It's booting XEN, but not the CURRENT-kernel afterwards or it boots the 
CURRENT but not xen. I have in /boot/loader.conf

xen_kernel="/boot/xen"
xen_cmdline="dom0_mem=4048M dom0_max_vcpus=4 dom0=pvh com1=115200,8n1 
guest_loglvl=all loglvl=all"
iommu="force,no-intremap"
if_tap_load="YES"
console=vga,com1
boot_multicons="YES"
boot_serial="YES"
console="comconsole,vidconsole"
vmm_load="YES"
vga=current

and in /etc/rc.conf:

xencommons_enable="YES"
cloned_interfaces="bridge0"
ifconfig_bridge0="addm bge0 SYNCDHCP"
ifconfig_bge0="up"

sudo ulimit -l
unlimited

sudo uname -a
FreeBSD freeBSD-CURRENT 13.0-CURRENT FreeBSD 13.0-CURRENT #5 r368997: Tue Jan 
12 13:46:33 CET 2021 lizbeth@freeBSD-CURRENT:/usr/obj/usr/src/amd64.amd64/
sys/LIZBETH  amd64

it's a no-debug kernel!

/etc/ttys
xc0 "/usr/libexec/getty Pc" xterm   on  secure


when booting without XEN I get the following with 'xl dmesg'

xencall: error: Could not obtain handle on privileged command interface /dev/
xen/privcmd: No such file or directory
libxl: error: libxl.c:102:libxl_ctx_alloc: cannot open libxc handle: No such 
file or directory
cannot init xl context

a normal boot without xen is on pastebin 

Re: Failed to load Xen, kernel '/boot/xen'

[Kevin G. Eliuk]

On 2021-01-14 12:19 a.m., Roger Pau Monné wrote:

On Tue, Jan 12, 2021 at 11:12:15AM -0800, Kevin G. Eliuk wrote:

It's kind of hard to tell what's going on without you providing almost
any info, but are you maybe booting using UEFI?

Oops a newbie mistake

Roger.



I was able to get things working by wiping the drive and re-installing 
FreeBSD 12 and selecting to encrypt the zfs file system.



Original message:

I had a working Xen Dom0 host running on a system which had been sitting 
idle for a while.  I had forgotten the passphrase for the encrypted 
drive so I did a reinstall to get back to work with it.


After the install and reboot I followed the instructions (multiple 
times) from FreeBSD as a Xen-Host.  but every reboot I have to unset the 
xen_kernel configuration because I get the following.


Loading Xen kernel
Failed to load Xen, kernel '/boot/xen'
can't load 'kernel'

I'm stumped.  Thanks for any help or suggestions for next steps.

   *# uname -a*
   FreeBSD freexen 12.2-RELEASE FreeBSD 12.2-RELEASE r366954 GENERIC  amd64
   --
   *# pkg info | grep xen*
   xen-kernel-4.14.0  Hypervisor using a microkernel design
   xen-tools-4.14.0_1 Xen management tools
   *# dmesg*
   ---<>---
   Copyright (c) 1992-2020 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 12.2-RELEASE r366954 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) Core(TM) i7-4790 CPU @ 3.60GHz (3591.76-MHz K8-class CPU)
  Origin="GenuineIntel"  Id=0x306c3  Family=0x6  Model=0x3c  Stepping=3
  
Features=0xbfebfbff
  
Features2=0x7ffafbff
  AMD Features=0x2c000800
  AMD Features2=0x21
  Structured Extended 
Features=0x27ab
  Structured Extended 
Features3=0x9c000600
  XSAVE Features=0x1
  VT-x: PAT,HLT,MTF,PAUSE,EPT,UG,VPID
  TSC: P-state invariant, performance statistics
   real memory  = 34359738368 (32768 MB)
   avail memory = 33264410624 (31723 MB)
   Event timer "LAPIC" quality 600
   ACPI APIC Table: 
   FreeBSD/SMP: Multiprocessor System Detected: 8 CPUs
   FreeBSD/SMP: 1 package(s) x 4 core(s) x 2 hardware threads
   random: unblocking device.
   ioapic0  irqs 0-23 on motherboard
   Launching APs: 1 7 6 2 3 4 5
   Timecounter "TSC-low" frequency 1795880018 Hz quality 1000
   random: entropy device external interface
   kbd1 at kbdmux0
   000.23 [4336] netmap_init   netmap: loaded module
   [ath_hal] loaded
   module_register_init: MOD_LOAD (vesa, 0x81115e40, 0) error 19
   random: registering fast source Intel Secure Key RNG
   random: fast provider: "Intel Secure Key RNG"
   nexus0
   efirtc0:  on motherboard
   efirtc0: registered as a time-of-day clock, resolution 1.00s
   vtvga0:  on motherboard
   cryptosoft0:  on motherboard
   acpi0:  on motherboard
   acpi0: Power Button (fixed)
   can't fetch resources for \134_SB_.PCI0.LPCB.LDRC - 
AE_AML_INVALID_RESOURCE_TYPE
   cpu0:  on acpi0
   hpet0:  iomem 0xfed0-0xfed003ff on acpi0
   Timecounter "HPET" frequency 14318180 Hz quality 950
   Event timer "HPET" frequency 14318180 Hz quality 550
   atrtc0:  port 0x70-0x77 irq 8 on acpi0
   atrtc0: registered as a time-of-day clock, resolution 1.00s
   Event timer "RTC" frequency 32768 Hz quality 0
   attimer0:  port 0x40-0x43,0x50-0x53 irq 0 on acpi0
   Timecounter "i8254" frequency 1193182 Hz quality 0
   Event timer "i8254" frequency 1193182 Hz quality 100
   Timecounter "ACPI-fast" frequency 3579545 Hz quality 900
   acpi_timer0: <24-bit timer at 3.579545MHz> port 0x408-0x40b on acpi0
   pcib0:  port 0xcf8-0xcff on acpi0
   pci0:  on pcib0
   vgapci0:  port 0xf000-0xf03f mem 
0xf780-0xf7bf,0xe000-0xefff irq 16 at device 2.0 on pci0
   vgapci0: Boot video device
   hdac0:  mem 0xf7c34000-0xf7c37fff irq 16 at 
device 3.0 on pci0
   xhci0:  mem 0xf7c2-0xf7c2 irq 
16 at device 20.0 on pci0
   xhci0: 32 bytes context size, 64-bit DMA
   usbus0: waiting for BIOS to give up control
   xhci_interrupt: host controller halted
   xhci0: Port routing mask set to 0x
   usbus0 on xhci0
   usbus0: 5.0Gbps Super Speed USB v3.0
   pci0:  at device 22.0 (no driver attached)
   uart2:  port 0xf0e0-0xf0e7 mem 
0xf7c3e000-0xf7c3efff irq 19 at device 22.3 on pci0
   uart2: Using 1 MSI message
   em0:  port 0xf080-0xf09f mem 
0xf7c0-0xf7c1,0xf7c3d000-0xf7c3dfff irq 20 at device 25.0 on pci0
   em0: Using 1024 TX descriptors and 1024 RX descriptors
   em0: Using an MSI interrupt
   em0: Ethernet address: c4:34:6b:58:35:fa
   em0: netmap queues/slots: TX 1/1024, RX 1/1024
   ehci0:  mem 0xf7c3c000-0xf7c3c3ff 
irq 16 at device 26.0 on pci0
   usbus1: EHCI version 1.0
   usbus1 on ehci0
   usbus1: 

Re: Failed to load Xen, kernel '/boot/xen'

[Kevin G. Eliuk]

On 2021-01-14 12:19 a.m., Roger Pau Monné wrote:

On Tue, Jan 12, 2021 at 11:12:15AM -0800, Kevin G. Eliuk wrote:

It's kind of hard to tell what's going on without you providing almost
any info, but are you maybe booting using UEFI?

Roger.


Booting with Legacy boot set in the BIOS.

After exhausting all could think of with BIOS settings and boot 
configurations I wiped the drive and re-installed selecting encryption 
in the ZFS options.  I booted and tested as shown in the handbook.


Thanks for the reply.

Regards,

Kevin Eliuk

___
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: either xen or custom

[Roger Pau Monné via freebsd-xen]

On Sun, Dec 13, 2020 at 12:11:40AM +0100, lizbethmutterh...@gmail.com wrote:
> to make a long story short: either I get a lock (hard to avoid, not to be 
> unlimited with ulimit -l unlimited) or a boot of xen and a blank screen with 
> reboot after a 10 seconds with vga=current. 

Hello,

Sorry for the delay on the reply. I'm afraid I will need more info in
order to help diagnose your issue.

How do you get the lock that you mention? Is it booting Xen, or just
plain FreeBSD?

Do you have a serial console attached to the box so that we could
see the log of Xen and FreeBSD booting?

Thanks, Roger.
___
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: Failed to load Xen, kernel '/boot/xen'

[Roger Pau Monné via freebsd-xen]

On Tue, Jan 12, 2021 at 11:12:15AM -0800, Kevin G. Eliuk wrote:

It's kind of hard to tell what's going on without you providing almost
any info, but are you maybe booting using UEFI?

Roger.
___
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: Failed to load Xen, kernel '/boot/xen'

[Kevin G. Eliuk]

___
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"

Failed to load Xen, kernel '/boot/xen'

[Kevin G. Eliuk]

___
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"

Invitation to GIS for Monitoring and Evaluation training JAN 2021

[FDC Training]

___
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"

either xen or custom

[lizbethmutterhunt]

to make a long story short: either I get a lock (hard to avoid, not to be 
unlimited with ulimit -l unlimited) or a boot of xen and a blank screen with 
reboot after a 10 seconds with vga=current. 


___
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: ZFS corruption using zvols as backingstore for hvm VM's

[Roger Pau Monné via freebsd-xen]

On Wed, Nov 18, 2020 at 11:58:27AM -0800, Brian Buhrow wrote:
>   hello Roger.  Sorry for the confusion.  I've been running NetBSD, or
> trying to, in both PV and HVM modes.  Here is a mesage I sent to the
> port-...@netbsd.org mailing list a few days ago, detailing what I found
> with running NetBSD in any mode under Xen as a domu.  Unfortunately, I
> don't think I can provide a trace  of a crash to the xen server when the

OK, I'm not really able to reproduce this myself, so if you get those
crashes again can you please make sure you have a serial attached to
the box so that you can provide some trace?

> HVM host misbehaves because I've had to move on in my work to get things
> working and I found a working combination of  NetBSD and ZFS that let's me
> proceed.  I've seen some discussion in the Xen documentation that suggests
> one can run a Xen dom0 in a domu guest, allowing for sand box testing of
> what you're describing without having to devote hardware to the issue.  Am
> I correct in this and where might I find instructions on how to do it?

You can test a nested PV dom0, but not a nested PVH dom0, which is
what FreeBSD uses to run as dom0.

> 
> In any case, here's what I found.

Thanks, I'm sure this will e helpful to others.

Roger.
___
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: ZFS corruption using zvols as backingstore for hvm VM's

[Brian Buhrow]

hello Roger.  Sorry for the confusion.  I've been running NetBSD, or
trying to, in both PV and HVM modes.  Here is a mesage I sent to the
port-...@netbsd.org mailing list a few days ago, detailing what I found
with running NetBSD in any mode under Xen as a domu.  Unfortunately, I
don't think I can provide a trace  of a crash to the xen server when the
HVM host misbehaves because I've had to move on in my work to get things
working and I found a working combination of  NetBSD and ZFS that let's me
proceed.  I've seen some discussion in the Xen documentation that suggests
one can run a Xen dom0 in a domu guest, allowing for sand box testing of
what you're describing without having to devote hardware to the issue.  Am
I correct in this and where might I find instructions on how to do it?

In any case, here's what I found.
-thanks
-Brian

From: Brian Buhrow 
Date: Mon, 16 Nov 2020 14:59:48 -0800
Subject: Re: Panic: HYPERVISOR_mmu_update failed on old NetBSD-5.2 domU
Cc: port-...@netbsd.org, buh...@nfbcal.org

hello Greg.  thanks for the pointers on Xen changes over the years and
the reasons for the changes.  After a lot more testing, thought and cvs
diffing, here is the state of the world, as I understand it, for the
record.

NetBSD-5/i386 won't run under Xen-4.12 or newer, possibly older
versions of Xen, I didn't test, because it still has calls to
xpq_queue_flush and the like which were used in pre-xen3 days.  I believe,
through code inspection, but didn't test, that this is also true of
NetBSD-6/i386 and NetBSD-7/i386.  

My next thought was to use NetBSD-5 in HVM mode, but it turns out this
is a show stopper for versions of NetBSD all the way through -current as of
May 24, 2020, see the link below, due to a cascade of bugs in the piixide(4)
emulator in Qemu and NetBSD-s inability to deal with partial success in
writing to disks on that chip set.  This failure is what causes the
original disk corruption I wrote about at the beginning of this thread.  As
an alternative, I tried enabling the SCSI LSI emulator in Qemu, but this
doesn't work because our esiop(4) driver doesn't play well with the
emulated LSI chips in Qemu.  No disk corruption, just timeouts when writing
to attached emulated sd(4) devices.  So, NetBSD as an HVM guest is pretty
much a bust!

Fortunately, there is a solution.  NetBSD-5.2/amd64 DOMU's work fine
under Xen-4.12 and above.  So, I'll run the 64-bit amd-64 base, with a
32-bit pkgsrc set of packages to allow me to migrate my busy, working
machine, to newere hardware as a VM, thereby giving me the ability to build
a replacement installation for this machine and begin building a new
environment without interrupting service on the old one.  I have several
instances of 64-bit kernels runing with 64-bit base and 32-bit pkgsrc
packages running successfully, so, while it's not ideal, it works quite
well and gives me space to think about how to move to NetBSD-9 and beyond.


Thanks again for the ideas and, hopefully, someone will find this
summary useful.
-Brian

http://mail-index.NetBSD.org/source-changes/2020/05/24/msg117668.html


___
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: ZFS corruption using zvols as backingstore for hvm VM's

[Roger Pau Monné via freebsd-xen]

On Thu, Nov 12, 2020 at 09:18:59PM -0800, Brian Buhrow wrote:
>   hello Roger.  thanks for engaging with me on this issue.  I think
> I've made progress on the issue and have a better handle on what's going
> wrong.  There seem to be a cascade of bugs here, which I'll try to
> enumerate.  
> 
> 1.  The disk corruption issue seems to be a bug in qemu whereby the
> emulated IDE disk controller issues partial writes instead of full writes
> or no writes with appropriate failure to the disk.  The IDE driver in
> NetBSD-5.2 doesn't play well with this behavior, in fact, NetBSD until May
> of 2020, doesn't play well with this behavior
> See: 
> http://mail-index.NetBSD.org/source-changes/2020/05/24/msg117668.html

Oh great, so it's something specific to NetBSD. This means you are
running NetBSD in HVM mode?

> 2.  This causes memory corruption in the OS itself, which can trigger a xen
> server crash!  (In my view, no matter how badly behaved the guest OS is, it
> shouldn't be able to bring down the xen server.)

Right, we really need the trace from this crash. Do you have a serial
hooked up to the box so that you can provide the panic message?

> 3.  Running NetBSD-5.2/i386 as a domu, which works flawlessly under xen3, 
> gets a 
> panic: HYPERVISOR_mmu_update failed

This would imply that you are running NetBSD in PV mode, in which case
it won't be using the emulated hard disk drive, and hence the commit
you referenced above would be unrelated. Can you assert whether you
are running NetBSD in PV or HVM mode?

>   I suspect this can be worked around using some of the command line
> options under Xen, xpti=true,domu=false, perhaps?  
> Are there others I should consider?

Maybe. I think you should report this to xen-devel and NetBSD/Xen
mailing lists, with a full trace of the crash and the guest config
file.

Roger.
___
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: ZFS corruption using zvols as backingstore for hvm VM's

[Roger Pau Monné via freebsd-xen]

On Wed, Nov 11, 2020 at 01:13:18AM -0800, Brian Buhrow wrote:
>   hello.  Following up on my own message, I believe I've run into a
> serious problem that exists on FreeBSD-xen with FreeBSD-12.1P10 and
> Xen-4.14.0.  Just in case I was running into an old bug with yesterday's
> post, I updated to xen-4.14.0 and Qemu-5.0.0.  the problem was still there,
> i.e. when writing to a second virtual hard drive on an hvm domu, the drive
> becomes corrupted.  Again, zpool scrub shows no errors.

Are you using volmode=dev when creating the zvol?

# zfs create -V16G -o volmode=dev zroot/foo

This is require when using zvol with bhyve, but shouldn't' be required
for Xen since the lock the guest disks from the kernel so GEOM cannot
taste them.

>   So, I decided it might be some sort of memory error.  I wrote a memory
> test program, shown below, and ran it on my hvm domu.  It not only
> crashed the domu itself, it crashed the entire xen server!  There are some
> dmesg messages that happened before the xen server crash, shown below, which
> suggest a serious problem.  In my view, no matter how badly the domu hvm
> host behaves, it shouldn't be able to crash the xen server itself!  The
> domu is running NetBSD-5.2, an admittedly old version of the operating
> system, but I'm running a fleet of these  machines, both on real hardware
> and on older versions of xen with no stability issues whatsoever!  And, as
> I say, I shouldn't be able to wipe out the xen server from an hvm domu, no
> matter what I do!

Can you please paste the config file of the domain?

> 
>   The memory test program takes one argument, the amount of RAM, 
> in
> megabytes, you want it to test.  It then allocates that memory, and
> sequentially walks through that memory over and over again, writing to it
> and reading from it, checking to make sure the data read matches the data
> written.  this has the effect of causing the resident set size of the
> program to grow slowly over time, as it works.  It was originally written
> to test the paging efficiency of a system, but I modified it to actually
> test the memory along the way.
>   to reproduce the issue, perform the following steps:
> 
> 1.  Set up an hvm host, I think FreeBSD as a domu hvm host will work fine.
> Use zfs zvols as the backingstore for the virtual disk(s) for your host.
> 
> 2.  Compile this program for that host and run it as follows:
> ./testmem 1000
> This should ask the program to allocate 1G of memory and then walk through
> and test it.  It will report each megabyte of memory it's written and
> tested.  My test hvm had 4G of RAM as it was a 32-bit  OS running on the
> domu.  Nothing else was running on either the xen server or the domu host.
> I'm not sure exactly how far the program got in its memory walk before
> things went south, but I think it touched about 100 megabytes of its 1000
> megabyte allocation.
> My program was not running as root, so it had no special privileges, even
> on the domu host.  
> 
>   I'm not sure if the problem is with qemu, xen, or some  combination of
> the two.  
> 
>   It would be great if someone could reproduce this issue and maybe shed
> a bit more light on what's going on.
> 
> -thanks
> -Brian
> 
> 
> 
> Nov 11 00:28:54 xen-lothlorien kernel: xnb(xnb_ring2pkt:1534): Unknown extra 
> info type 255.  Discarding packet
> Nov 11 00:28:54 xen-lothlorien kernel: xnb(xnb_dump_txreq:304): 
> netif_tx_request index =0
> Nov 11 00:28:54 xen-lothlorien kernel: xnb(xnb_dump_txreq:305): 
> netif_tx_request.gref  =0
> Nov 11 00:28:54 xen-lothlorien kernel: xnb(xnb_dump_txreq:306): 
> netif_tx_request.offset=0
> Nov 11 00:28:54 xen-lothlorien kernel: xnb(xnb_dump_txreq:307): 
> netif_tx_request.flags =8
> Nov 11 00:28:54 xen-lothlorien kernel: xnb(xnb_dump_txreq:308): 
> netif_tx_request.id=69
> Nov 11 00:28:54 xen-lothlorien kernel: xnb(xnb_dump_txreq:309): 
> netif_tx_request.size  =1000
> Nov 11 00:28:54 xen-lothlorien kernel: xnb(xnb_dump_txreq:304): 
> netif_tx_request index =1
> Nov 11 00:28:54 xen-lothlorien kernel: xnb(xnb_dump_txreq:305): 
> netif_tx_request.gref  =255
> Nov 11 00:28:54 xen-lothlorien kernel: xnb(xnb_dump_txreq:306): 
> netif_tx_request.offset=0
> Nov 11 00:28:54 xen-lothlorien kernel: xnb(xnb_dump_txreq:307): 
> netif_tx_request.flags =0
> Nov 11 00:28:54 xen-lothlorien kernel: xnb(xnb_dump_txreq:308): 
> netif_tx_request.id=0
> Nov 11 00:28:54 xen-lothlorien kernel: xnb(xnb_dump_txreq:309): 
> netif_tx_request.size  =0
> Nov 11 00:28:54 xen-lothlorien kernel: xnb(xnb_rxpkt2rsp:2068): Got error -1 
> for hypervisor gnttab_copy status
> Nov 11 00:28:54 xen-lothlorien kernel: xnb(xnb_ring2pkt:1534): Unknown extra 
> info type 255.  Discarding packet
> Nov 11 00:28:54 xen-lothlorien kernel: xnb(xnb_dump_txreq:304): 
> netif_tx_request index =0
> Nov 11 00:28:54 xen-lothlorien kernel: xnb(xnb_dump_txreq:305): 
> netif_tx_request.gref  =0
> Nov 11 00:28:54 xen-lothlorien kernel: 

Re: ZFS corruption using zvols as backingstore for hvm VM's

[Brian Buhrow]

hello.  Following up on my own message, I believe I've run into a
serious problem that exists on FreeBSD-xen with FreeBSD-12.1P10 and
Xen-4.14.0.  Just in case I was running into an old bug with yesterday's
post, I updated to xen-4.14.0 and Qemu-5.0.0.  the problem was still there,
i.e. when writing to a second virtual hard drive on an hvm domu, the drive
becomes corrupted.  Again, zpool scrub shows no errors.
So, I decided it might be some sort of memory error.  I wrote a memory
test program, shown below, and ran it on my hvm domu.  It not only
crashed the domu itself, it crashed the entire xen server!  There are some
dmesg messages that happened before the xen server crash, shown below, which
suggest a serious problem.  In my view, no matter how badly the domu hvm
host behaves, it shouldn't be able to crash the xen server itself!  The
domu is running NetBSD-5.2, an admittedly old version of the operating
system, but I'm running a fleet of these  machines, both on real hardware
and on older versions of xen with no stability issues whatsoever!  And, as
I say, I shouldn't be able to wipe out the xen server from an hvm domu, no
matter what I do!

The memory test program takes one argument, the amount of RAM, 
in
megabytes, you want it to test.  It then allocates that memory, and
sequentially walks through that memory over and over again, writing to it
and reading from it, checking to make sure the data read matches the data
written.  this has the effect of causing the resident set size of the
program to grow slowly over time, as it works.  It was originally written
to test the paging efficiency of a system, but I modified it to actually
test the memory along the way.
to reproduce the issue, perform the following steps:

1.  Set up an hvm host, I think FreeBSD as a domu hvm host will work fine.
Use zfs zvols as the backingstore for the virtual disk(s) for your host.

2.  Compile this program for that host and run it as follows:
./testmem 1000
This should ask the program to allocate 1G of memory and then walk through
and test it.  It will report each megabyte of memory it's written and
tested.  My test hvm had 4G of RAM as it was a 32-bit  OS running on the
domu.  Nothing else was running on either the xen server or the domu host.
I'm not sure exactly how far the program got in its memory walk before
things went south, but I think it touched about 100 megabytes of its 1000
megabyte allocation.
My program was not running as root, so it had no special privileges, even
on the domu host.  

I'm not sure if the problem is with qemu, xen, or some  combination of
the two.  

It would be great if someone could reproduce this issue and maybe shed
a bit more light on what's going on.

-thanks
-Brian



Nov 11 00:28:54 xen-lothlorien kernel: xnb(xnb_ring2pkt:1534): Unknown extra 
info type 255.  Discarding packet
Nov 11 00:28:54 xen-lothlorien kernel: xnb(xnb_dump_txreq:304): 
netif_tx_request index =0
Nov 11 00:28:54 xen-lothlorien kernel: xnb(xnb_dump_txreq:305): 
netif_tx_request.gref  =0
Nov 11 00:28:54 xen-lothlorien kernel: xnb(xnb_dump_txreq:306): 
netif_tx_request.offset=0
Nov 11 00:28:54 xen-lothlorien kernel: xnb(xnb_dump_txreq:307): 
netif_tx_request.flags =8
Nov 11 00:28:54 xen-lothlorien kernel: xnb(xnb_dump_txreq:308): 
netif_tx_request.id=69
Nov 11 00:28:54 xen-lothlorien kernel: xnb(xnb_dump_txreq:309): 
netif_tx_request.size  =1000
Nov 11 00:28:54 xen-lothlorien kernel: xnb(xnb_dump_txreq:304): 
netif_tx_request index =1
Nov 11 00:28:54 xen-lothlorien kernel: xnb(xnb_dump_txreq:305): 
netif_tx_request.gref  =255
Nov 11 00:28:54 xen-lothlorien kernel: xnb(xnb_dump_txreq:306): 
netif_tx_request.offset=0
Nov 11 00:28:54 xen-lothlorien kernel: xnb(xnb_dump_txreq:307): 
netif_tx_request.flags =0
Nov 11 00:28:54 xen-lothlorien kernel: xnb(xnb_dump_txreq:308): 
netif_tx_request.id=0
Nov 11 00:28:54 xen-lothlorien kernel: xnb(xnb_dump_txreq:309): 
netif_tx_request.size  =0
Nov 11 00:28:54 xen-lothlorien kernel: xnb(xnb_rxpkt2rsp:2068): Got error -1 
for hypervisor gnttab_copy status
Nov 11 00:28:54 xen-lothlorien kernel: xnb(xnb_ring2pkt:1534): Unknown extra 
info type 255.  Discarding packet
Nov 11 00:28:54 xen-lothlorien kernel: xnb(xnb_dump_txreq:304): 
netif_tx_request index =0
Nov 11 00:28:54 xen-lothlorien kernel: xnb(xnb_dump_txreq:305): 
netif_tx_request.gref  =0
Nov 11 00:28:54 xen-lothlorien kernel: xnb(xnb_dump_txreq:306): 
netif_tx_request.offset=0
Nov 11 00:28:54 xen-lothlorien kernel: xnb(xnb_dump_txreq:307): 
netif_tx_request.flags =8
Nov 11 00:28:54 xen-lothlorien kernel: xnb(xnb_dump_txreq:308): 
netif_tx_request.id=69
Nov 11 00:28:54 xen-lothlorien kernel: xnb(xnb_dump_txreq:309): 
netif_tx_request.size  =1000
Nov 11 00:28:54 xen-lothlorien kernel: xnb(xnb_dump_txreq:304): 
netif_tx_request index =1
Nov 11 00:28:54 xen-lothlorien kernel: xnb(xnb_dump_txreq:305): 
netif_tx_request.gref  =255
Nov 11 00:28:54 xen-lothlorien 

Re: ZFS corruption using zvols as backingstore for hvm VM's

[Brian Buhrow]

hello.   I'm running, or attempting to run, FreeBSD-12.1 with xen-4.12
with HVM machines, using Zvols as backingstore for the virtual disks.  I'm
running into an issue where after I write to the disk with the VM, 
filesystems on the disk become corrupted, including corruption of the disk
label and partition table.  zpool status shows no errors, even  after I
perform a scrub.   ZFS might be a coincidence and it may be a problem with
Xen or Qemu, which is why I'm writing here.  To do my install, I configured
two disks for my VM, one to use as a boot/root disk and the other to build
the system I'm virtualizing.  Interestingly enough, I do not see corruption
on the virtual boot disk, only on the secondary disk.  My config is shown
below.
The VM is a NetBSD-5.2 system.  I'm running many 5.2 systems, both as
real hardware and as virtual machines without trouble, so there is
something about this setup that's the problem, as opposed to the OS in the
vm.  The dmesg for the VM is shown below as well.  Are secondary disks as
rw disks not supported?

-thanks
-Brian

Copyright (c) 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005,
2006, 2007, 2008, 2009, 2010
The NetBSD Foundation, Inc.  All rights reserved.
Copyright (c) 1982, 1986, 1989, 1991, 1993
The Regents of the University of California.  All rights reserved.

NetBSD 5.2_STABLE (ALTQ) #0: Fri Feb  8 01:00:12 PST 2019
buh...@lothlorien.nfbcal.org:/usr/src/sys/arch/i386/compile/ALTQ
total memory = 3839 MB
avail memory = 3761 MB
timecounter: Timecounters tick every 1.000 msec
timecounter: Timecounter "i8254" frequency 1193182 Hz quality 100
Xen HVM domU (4.12.1)
PCI BIOS rev. 2.1 found at 0xfd1c8
pcibios: config mechanism [1][x], special cycles [x][x], last bus 0
PCI IRQ Routing Table rev. 1.0 found at 0xf5d20, size 128 bytes (6 entries)
PCI Interrupt Router at 000:01:0 (Intel 82371FB (PIIX) PCI-ISA Bridge 
compatible)
mainbus0 (root)
cpu0 at mainbus0 apid 0: Intel 686-class, 3093MHz, id 0x206a7
cpu1 at mainbus0 apid 2: Intel 686-class, 3093MHz, id 0x206a7
ioapic0 at mainbus0 apid 1: pa 0xfec0, version 11, 48 pins
acpi0 at mainbus0: Intel ACPICA 20080321
acpi0: X/RSDT: OemId <   Xen, HVM,>, AslId 
acpi0: SCI interrupting at int 9
acpi0: fixed-feature power button present
acpi0: fixed-feature sleep button present
timecounter: Timecounter "ACPI-Safe" frequency 3579545 Hz quality 900
ACPI-Safe 32-bit timer
hpet0 at acpi0 (HPET, PNP0103-0): mem 0xfed0-0xfed003ff
timecounter: Timecounter "hpet0" frequency 6250 Hz quality 2000
attimer1 at acpi0 (TMR, PNP0100): io 0x40-0x43 irq 0
pcppi1 at acpi0 (SPKR, PNP0800): io 0x61
midi0 at pcppi1: PC speaker (CPU-intensive output)
spkr0 at pcppi1
sysbeep0 at pcppi1
pckbc1 at acpi0 (PS2M, PNP0F13) (aux port): irq 12
pckbc2 at acpi0 (PS2K, PNP0303) (kbd port): io 0x60,0x64 irq 1
FDC0 (PNP0700) [PC standard floppy disk controller] at acpi0 not configured
UAR1 (PNP0501) [16550A-compatible COM port] at acpi0 not configured
apm0 at acpi0: Power Management spec V1.2
attimer1: attached to pcppi1
pckbd0 at pckbc2 (kbd slot)
pckbc2: using irq 1 for kbd slot
wskbd0 at pckbd0 mux 1
pms0 at pckbc2 (aux slot)
pckbc2: using irq 12 for aux slot
wsmouse0 at pms0 mux 0
pci0 at mainbus0 bus 0: configuration mode 1
pci0: i/o space, memory space enabled, rd/line, rd/mult, wr/inv ok
pchb0 at pci0 dev 0 function 0
pchb0: Intel 82441FX (PMC) PCI and Memory Controller (rev. 0x02)
pcib0 at pci0 dev 1 function 0
pcib0: Intel 82371SB (PIIX3) PCI-ISA Bridge (rev. 0x00)
piixide0 at pci0 dev 1 function 1
piixide0: Intel 82371SB IDE Interface (PIIX3) (rev. 0x00)
piixide0: bus-master DMA support present
piixide0: primary channel wired to compatibility mode
piixide0: primary channel interrupting at ioapic0 pin 14
atabus0 at piixide0 channel 0
piixide0: secondary channel wired to compatibility mode
piixide0: secondary channel interrupting at ioapic0 pin 15
atabus1 at piixide0 channel 1
piixpm0 at pci0 dev 1 function 3
piixpm0: Intel 82371AB (PIIX4) Power Management Controller (rev. 0x03)
timecounter: Timecounter "piixpm0" frequency 3579545 Hz quality 1000
piixpm0: 24-bit timer
piixpm0: SMBus disabled
XenSource, Inc. Xen Platform Device (undefined subclass 0x80, revision 0x01) at 
pci0 dev 2 function 0 not configured
vga1 at pci0 dev 3 function 0: Cirrus Logic CL-GD5446 (rev. 0x00)
wsdisplay0 at vga1 kbdmux 1
wsmux1: connecting to wsdisplay0
wskbd0: connecting to wsdisplay0
drm at vga1 not configured
wm0 at pci0 dev 4 function 0: Intel i82540EM 1000BASE-T Ethernet, rev. 3
wm0: interrupting at ioapic0 pin 32
wm0: 32-bit 33MHz PCI bus
wm0: 64 word (6 address bits) MicroWire EEPROM
wm0: Ethernet address 00:4e:46:42:42:ce
makphy0 at wm0 phy 1: Marvell 88E1011 Gigabit PHY, rev. 0
makphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
isa0 at pcib0
com0 at isa0 port 0x3f8-0x3ff irq 4: ns16550a, working fifo
com0: console
isapnp0 at isa0 port 0x279: ISA Plug 'n Play device support
npx0 at isa0 port 

Re: UEFI and FreeBSD/Xen-12.1/4.12

[Roger Pau Monné via freebsd-xen]

On Sun, Nov 08, 2020 at 11:46:34PM -0800, Brian Buhrow wrote:
>   hello.  I'm trying to get an installation of FreeBSD-12.1 / xen 4.12
> running an Intel DQ67SW motherboard with 4 8TB disks attached to it up and
> running.   Everything seems to work fine, except that the BIOS will not
> boot from the hard drives in legacy mode on its own.  If I manually select
> a disk from the boot menu, FreeBSD and Xen load  as they should.  The Intel
> site says that booting from disks larger than 2TB is only supported if UEFI
> booting is enabled.  It's my understanding that Freebsd-Xen will not run
> if one doesn't boot in legacy mode.
>   Any suggestions on how to work around this conflict?  Is it now
> possible to boot FreeBSD as Dom0 in UEFI boot mode?

In order to boot FreeBSD/Xen dom0 using UEFI we need to add support
for the multiboot2 [0] boot protocol, so that the FreeBSD loader can do
the handoff to the Xen kernel. We currently only have multiboot1
implemented in the FreeBSD loader, and hence we are limited to legacy
(BIOS) boot.

I've been meaning to fix this and add support for multiboot2, but so
far I haven't got the time to actually do the work. If someone is
interested in working on this I'm happy to help, but it does require
someone that's slightly familiar with the loader.

Roger.

[0] https://www.gnu.org/software/grub/manual/multiboot2/multiboot.html
___
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 and FreeBSD/Xen-12.1/4.12

[Brian Buhrow]

hello.  I'm trying to get an installation of FreeBSD-12.1 / xen 4.12
running an Intel DQ67SW motherboard with 4 8TB disks attached to it up and
running.   Everything seems to work fine, except that the BIOS will not
boot from the hard drives in legacy mode on its own.  If I manually select
a disk from the boot menu, FreeBSD and Xen load  as they should.  The Intel
site says that booting from disks larger than 2TB is only supported if UEFI
booting is enabled.  It's my understanding that Freebsd-Xen will not run
if one doesn't boot in legacy mode.
Any suggestions on how to work around this conflict?  Is it now
possible to boot FreeBSD as Dom0 in UEFI boot mode?

-thanks
-Brian

___
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"

IBM Watson, MS Azure Users Records

[Kate Horst]

Hi,



I would like to know if you are interested in acquiring IBM Watson Users 
Records for your marketing and sales needs?



We also have: Microsoft Azure, TensorFlow, AWS, ServiceNow, OpenShift, VMware 
Tanzu, Kubernetes and many more.



Data Fields: Name, Company's Name, Phone Number, Fax Number, Job Title, Email 
address, Complete Mailing Address, SIC code, Company revenue, size, Web address 
etc.



Data can be customized based upon your requirement (e.g. Job title, Verticals, 
Geography etc.)



Looking forward to hear from you.



Regards,

Kate Horst

Demand Generation Head



If you wish not to receive marketing emails please response "Remove"
___
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"

Szkolenie z angielskiego

[Aleksandra Musiał via freebsd-xen]

Dzień dobry,

czy byliby Państwo zainteresowani poszerzeniem umiejętności językowych wśród 
współpracowników?

Reprezentuję szkołę językową, która już od 25 lat organizuje profesjonalne 
szkolenia z języka angielskiego dla firm. Już ponad 300 partnerów biznesowych 
korzysta z opracowanej przez nas strategii rozwoju językowego. 

Zajęcia prowadzą lektorzy z doświadczeniem w języku biznesowym zarówno w trybie 
stacjonarnym, jak i online. Zakres spotkań odpowiednio dopasowujemy do branży, 
stanowisk uczestników i zakresów ich obowiązków. 
 
Gwarantujemy elastyczność czasową oraz próbne spotkanie z lektorem, co pomoże 
ustalić potrzeby językowe i jasno sprecyzować cel. 

Jako autoryzowany ośrodek Cambridge zapewniamy możliwość certyfikacji 
kompetencji językowych w ramach Autoryzowanego Centrum Egzaminacyjnego 
Cambridge English  Language  Assessment.

Jeśli są Państwo zainteresowani rozważeniem naszej propozycji, proszę o 
informację zwrotną.


Z pozdrowieniami
Aleksandra Musiał 
Project Manager
___
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"

Disinfectant

[William Jones via freebsd-xen]

Good morning,

looking for companies interested in raising additional capital by diversifying 
their offer in soaps, liquids and gels for hand disinfection and cosmetics for 
body and hair care.

The distribution of innovative products corresponding to the current 
preferences of customers in the field of hygiene and preventive healthcare 
allows our partners to gain new markets and achieve better economic results.

In addition to products with bactericidal action, our range includes shower 
gels, shampoos and hair conditioners, as well as efficient, concentrated 
detergents.

The versatility (suitable for all skin types) combined with an affordable price 
means that customers make an informed choice of a product among others 
available on the market.

Are you interested in cooperation?


William Jones
___
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"

Notification: 4 undelivered mails are pending

[freebsd.org via freebsd-xen]

___
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"

Notification: 4 undelivered mails are pending

[freebsd.org via freebsd-xen]

___
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"

Fax #3771672 prepared, a feedback needed

[Coffield Iglesias via freebsd-xen]

Invoicing terminable statement #84691

Regards,
Coffield Iglesias
___
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"

Faxing documents #692899

[Christianson Fitzwater via freebsd-xen]

Full equipment invoice #14864

Password for this document: 709384

Best regards,
Christianson Fitzwater
___
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"

[Bug 249123] PVH domU not migrating from one XEN host to another

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=249123

Roger Pau Monné  changed:

   What|Removed |Added

 CC||roy...@freebsd.org

--- Comment #1 from Roger Pau Monné  ---
(In reply to Pierre-Philipp Braun from comment #0)
Thanks for the report, latest -RELEASE versions (11 and 12) should be fine as
are tested by the Xen test system and migrate correctly, see:

http://logs.test-lab.xenproject.org/osstest/logs/153813/

Grep for the *freebsd* tests. I will look at what's going on with -CURRENT.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
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"

[Bug 249123] PVH domU not migrating from one XEN host to another

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=249123

Mark Linimon  changed:

   What|Removed |Added

   Assignee|b...@freebsd.org|x...@freebsd.org

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
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"

[no subject]

[camryn . reese]

Hi,

Are looking for a customer bases of your Competitors Installed Base which
you to reach niche target and also helps you to grab new clients for your
latest service and products?

*We also have an exclusive database of:*

1.   Cloud Service Providers- CSPs

2.   Independent Software Vendors- ISVs

3.   System Integrators- SIs and more

4.   Managed Service Providers- MSPs

5.   Managed Security Service Providers- MSSPs and more

Data can be customized based upon your requirement (e.g. Job title,
Verticals, Geography etc.)

*Data Fields we provide*: Name, Company's Name, Phone Number, Fax Number,
Job Title, Email address, Complete Mailing Address, SIC code, Company
revenue, size, Web address etc.

Please feel free to get back to me with your target criteria if your
criteria is different from the above mentioned applications let me know we
have close to 5000+ technology
installations.



*Best Regards,*

*Cynthia Overly*

*Marketing Executive*



Note: This email is not expected to be a spam. It would be ideal if you
acknowledge our conciliatory sentiments and answer in the subject taking
with leave off to be expelled from our Mailing list. Why not try it/us out?
___
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: The vnclisten parameter is ignored with hvm domains under xen-4.12.1 and FreeBSD-12.0

[Brian Buhrow]

hello Roger.  Yes, I think an improvement to the xl.cfg man page would
be helpful.  Your additional notes clarifying my message are also useful in
helping to craft what that modified man page might look like.  In
particular, the section of the man page that says that vnc parameters wil
be picked up by hvm guests implies that they'll be picked up from within
the vfb spec.  that's simply not the case.  And, as you point out, it's
possible, though not probable, to have both an emulated graphics card on an
hvm guest and a pv graphics card on a hvm guest, both potentially sending
their vnc output to different IP addresses.  That's not at all clear from
the man page as I read it.
I'll try to come up with some potential language and send it along to
you and this list.  If you think it helps, then it could be submitted as an
upstream patch.

-thanks
-Brian

On Aug 31,  9:55am, Roger Pau =?utf-8?B?TW9ubsOp?= wrote:
} Subject: Re: The vnclisten parameter is ignored with hvm domains under xen
} On Fri, Aug 28, 2020 at 02:11:07PM -0700, Brian Buhrow wrote:
} > hello Roger.  thanks for the quick reply.  I think, after a careful
} > read of the xl.cfg man page plus a careful reading of the xen-tools source
} > code, I've figured out the issue.  I'm sending the solution here so folks
} > will have it in the future.
} > 
} > If one is configuring an hvm guest, any vfb specifications  in the domain
} > configuration are ignored.
} 
} Let me clarify this a bit. vfb is a para-virtualized frame buffer, so
} it needs a specific Xen vfb driver in the guest for it to be able to
} use the device (ie: it's not an emulated graphics card).
} 
} > Instead, the parameters that normally get placed
} > in a vfb stanza must be placed as top level configuration items.  For
} > example:
} > 
} > For a PV guest:
} > vfb = [ 'vnc=1,vnclisten=10.14.200.200' ]
} > 
} > Translates to, for an hvm guest:
} > 
} > vnc = 1
} > vnclisten = "10.14.200.200"
} 
} OTOH, the global vnc parameter is indeed exclusive to HVM guests and
} is related to the emulated graphics card device.
} 
} You could have a HVM guest making use of both the emulated graphics
} card (the global vnc parameter) and nmultiple para-virtualized vfb
} framebuffers, but those would be different outputs (like having more
} than one graphics card on a physical box).
} 
} You cannot however make use of the global vnc parameter for PV guests,
} as they have no emulated graphics card.
} 
} > 
} > The xl.cfg man page doesn't say that in order for the vnc parameters to be
} > picked up for hvm guests with emulated graphics cards, those parameters
} > need to be specified as top level parameters in the config file.  It took
} > reading the source code of the xen-tools xl code to figure that out.
} 
} Sorry, I understand this is quite confusing. Do you think the man page
} could be modified to make this easier to understand and create less
} confusion?
} 
} I'm quite sure the community would be happy to take a patch in order
} to clarify stuff.
} 
} Thanks, Roger.
>-- End of excerpt from Roger Pau =?utf-8?B?TW9ubsOp?=


___
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: The vnclisten parameter is ignored with hvm domains under xen-4.12.1 and FreeBSD-12.0

[Roger Pau Monné via freebsd-xen]

On Fri, Aug 28, 2020 at 02:11:07PM -0700, Brian Buhrow wrote:
>   hello Roger.  thanks for the quick reply.  I think, after a careful
> read of the xl.cfg man page plus a careful reading of the xen-tools source
> code, I've figured out the issue.  I'm sending the solution here so folks
> will have it in the future.
> 
> If one is configuring an hvm guest, any vfb specifications  in the domain
> configuration are ignored.

Let me clarify this a bit. vfb is a para-virtualized frame buffer, so
it needs a specific Xen vfb driver in the guest for it to be able to
use the device (ie: it's not an emulated graphics card).

> Instead, the parameters that normally get placed
> in a vfb stanza must be placed as top level configuration items.  For
> example:
> 
> For a PV guest:
> vfb = [ 'vnc=1,vnclisten=10.14.200.200' ]
> 
> Translates to, for an hvm guest:
> 
> vnc = 1
> vnclisten = "10.14.200.200"

OTOH, the global vnc parameter is indeed exclusive to HVM guests and
is related to the emulated graphics card device.

You could have a HVM guest making use of both the emulated graphics
card (the global vnc parameter) and nmultiple para-virtualized vfb
framebuffers, but those would be different outputs (like having more
than one graphics card on a physical box).

You cannot however make use of the global vnc parameter for PV guests,
as they have no emulated graphics card.

> 
> The xl.cfg man page doesn't say that in order for the vnc parameters to be
> picked up for hvm guests with emulated graphics cards, those parameters
> need to be specified as top level parameters in the config file.  It took
> reading the source code of the xen-tools xl code to figure that out.

Sorry, I understand this is quite confusing. Do you think the man page
could be modified to make this easier to understand and create less
confusion?

I'm quite sure the community would be happy to take a patch in order
to clarify stuff.

Thanks, Roger.
___
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: The vnclisten parameter is ignored with hvm domains under xen-4.12.1 and FreeBSD-12.0

[Brian Buhrow]

hello Roger.  thanks for the quick reply.  I think, after a careful
read of the xl.cfg man page plus a careful reading of the xen-tools source
code, I've figured out the issue.  I'm sending the solution here so folks
will have it in the future.

If one is configuring an hvm guest, any vfb specifications  in the domain
configuration are ignored.  Instead, the parameters that normally get placed
in a vfb stanza must be placed as top level configuration items.  For
example:

For a PV guest:
vfb = [ 'vnc=1,vnclisten=10.14.200.200' ]

Translates to, for an hvm guest:

vnc = 1
vnclisten = "10.14.200.200"

The xl.cfg man page doesn't say that in order for the vnc parameters to be
picked up for hvm guests with emulated graphics cards, those parameters
need to be specified as top level parameters in the config file.  It took
reading the source code of the xen-tools xl code to figure that out.

-thanks
-Brian

___
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: The vnclisten parameter is ignored with hvm domains under xen-4.12.1 and FreeBSD-12.0

[Roger Pau Monné via freebsd-xen]

On Fri, Aug 28, 2020 at 08:47:41AM -0700, Brian Buhrow wrote:
>   hello.  I'm trying to configure an hvm domain with a vnc listener  on
> one of the dom0's network addresses, rather than 127.0.0.1.  
> 
> If I use a line like: 
> vfb = [ 'type=vnc,vnc=1,vnclisten=10.14.200.200' ]

type=vnc doesn't seem to be a known option according to the xl.cfg man
page [0].

> 
> in the config file, I still get a vnc listener on 127.0.0.1, rather than
> 10.14.200.200.

Do you also have a VNC sever without using vfb enabled? (ie: the
global xl.cfg vnc option). It might be useful if you post the full
xl.cfg maybe.

> 
>   A google search suggests this is somewhat of a known problem, but I
> don't see a patch in the upstream version of xen-tools that addresses it.
> Is there an easy fix for this issue, or perhaps I need to do what I want in
> a different way?

I think you will likely get more information by posting to xen-devel
directly, as this doesn't seem related to FreeBSD.

Roger.

[0] https://xenbits.xen.org/docs/4.12-testing/man/xl.cfg.5.html
___
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"

The vnclisten parameter is ignored with hvm domains under xen-4.12.1 and FreeBSD-12.0

[Brian Buhrow]

hello.  I'm trying to configure an hvm domain with a vnc listener  on
one of the dom0's network addresses, rather than 127.0.0.1.  

If I use a line like: 
vfb = [ 'type=vnc,vnc=1,vnclisten=10.14.200.200' ]

in the config file, I still get a vnc listener on 127.0.0.1, rather than
10.14.200.200.

A google search suggests this is somewhat of a known problem, but I
don't see a patch in the upstream version of xen-tools that addresses it.
Is there an easy fix for this issue, or perhaps I need to do what I want in
a different way?

-thanks
-Brian

___
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"

[Bug 188261] [xen] FreeBSD DomU PVHVM guests cannot 'route' traffic for other Xen PV guests on same Dom0 Host.

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=188261

--- Comment #43 from Roger Pau Monné  ---
(In reply to Ricardo from comment #42)
No, those patches have not been committed to FreeBSD upstream, partly to my
lack of nagging, partly because I wasn't sure this was the best way to fix it
(as I'm not an expert on the networking subsystem).

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
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"

[Bug 188261] [xen] FreeBSD DomU PVHVM guests cannot 'route' traffic for other Xen PV guests on same Dom0 Host.

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=188261

--- Comment #42 from Ricardo  ---
Thank you very much for your replies Roger.
I will try to take it to the Netgate/pfSense community and see if they can help
me from there!

So from what I understand this issue was never officially fixed?

Cheers

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
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"

[Bug 188261] [xen] FreeBSD DomU PVHVM guests cannot 'route' traffic for other Xen PV guests on same Dom0 Host.

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=188261

--- Comment #41 from Roger Pau Monné  ---
(In reply to Ricardo from comment #40)
Oh, I'm afraid I don't know how to apply those against a pfesne build. With
plain FreeBSD you would checkout the source from svn or git (see
https://www.freebsd.org/doc/handbook/svn.html) and you would then build a new
kernel with the patches applied
(https://www.freebsd.org/doc/handbook/makeworld.html).

You will have to ask the pfsense community how to apply those patches and
rebuild the pfsense kernel.

Roger.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
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"

[Bug 188261] [xen] FreeBSD DomU PVHVM guests cannot 'route' traffic for other Xen PV guests on same Dom0 Host.

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=188261

--- Comment #40 from Ricardo  ---
Hi Roger thank you so much for the quick reply!!

So looking for where to apply the patch I don't have the directory /sys and
/usr/src/sys is empty/doesn't exist.

Tried to find it but without success:

[admin@pfs-fw01]/: find / -iname 'ip_fastfwd.c'
[admin@pfs-fw01]/:

pfSense 2.4.5-RELEASE-p1 (amd64) 
built on Tue Jun 02 17:51:17 EDT 2020 
FreeBSD 11.3-STABLE

Thank you!!

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
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"

[Bug 188261] [xen] FreeBSD DomU PVHVM guests cannot 'route' traffic for other Xen PV guests on same Dom0 Host.

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=188261

--- Comment #39 from Roger Pau Monné  ---
(In reply to Ricardo from comment #38)
Hello,

I've looked into it in the past, but I'm not a networking expert, and properly
solving those issues requires a very good understanding of the network
subsystem, as I think some modifications to common code are required. When
trying to solve this I've made the following patches:

https://reviews.freebsd.org/D6611
https://reviews.freebsd.org/D6612

(this last one might not be required:)

https://reviews.freebsd.org/D6656

I'm afraid those patches are old, so they might not apply cleanly. Let me know
if you can apply and give them a try, and whether they fix anything.

Roger.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
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"

[Bug 243993] FreeBSD as Guest with 5+ with xnb(4) devices panic on call to sysctl -a in strlen

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=243993

Mark Johnston  changed:

   What|Removed |Added

 CC||kak...@freebsd.org,
   ||ma...@freebsd.org

--- Comment #2 from Mark Johnston  ---
I believe this has since been fixed.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
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"

網路行銷軟體：功能如此強大,使用卻如此簡單h8s6my048

[全自動行銷軟體 .]

網路行銷軟體：功能如此強大,使用卻如此簡單h8s6my048 


儴年S儘牌E剢局O 
僌傷搜亩纓尋倵蹄引侮頹擎侯團排便亭名俀昔軟俐西體俏瞬、偎優部乴殿落啇肥格冱侯發击鈎文咺莫軟偖巒體匪輩、偻闌點列疏擊哆晦增伹橇加厨冕搜侅爾尋侊閣流俰盾量伻肯軟仕羚體兴汁、信夥e偨乏d呎斑m儼奢全候嘯球僭綿發厚祭信咉酌軟亐沮體厒脾、刯炭全众男球厱臆網唔署路倶綁資凭桔料书卑蒐仗帚集刷娩軟劧糧體厖淡、
 來茵G倠迹o创樣o丵旗g侲渡l哔霖e叕媳快亴膜速倚蘸進呫箭第乃腿一儎粳頁動砒軟倉哲體
https://j．mp/2B3EvHw
___
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"

Quarantine notification - freebsd.org

[freebsd . org]

___
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: FreeBSD 12.1 hypervisor management tools

[David P. Discher]

This pop’ed up in my inbox when I was searching for something else … but by 
far, your best solution will be XOA

 - https://xen-orchestra.com

Not specifically “not” freebsd … it’s complicated enough to deploy via NPM or 
yarn or whatever - I’d recommend starting with their appliance.  I’m running 
XCP-ng, with XOA control.  You can have multiple XOAs controller your clusters, 
so you can run their linux packaged VM, while working on getting it to run 
under freebsd, if desired. 

All the other tool listed in this thread are incomplete and when I was last 
evaluating, about 6 month ago, where missing too many key features.

I am not using FreeBSD as Dom0 - but using it as the backing NAS OS. And 
running a mix of CentOS and FreeBSD VMs.  A few years  ago, I test FreeBSD Dom0 
… and still needed a lot of work to be production ready … as I the other thread 
in Xen in Feb 2020, from Brian … 'abysmal network performance’ … and I believe 
disk IO was piss poor too.

If you are all FreeBSD, or mostly FreeBSD VMs … bhyve and vm-bhyve are nice, 
but no GUI. (if you don’t require more than 1Gbps network performance ).  There 
was some, somewhat secret work on full VPS (virtual private server) kernel 
work, that got near (90-95%) theoretical hardware performance on Disk and Net 
IO, but I’m not sure if that was every merged or released publicly.   It was 
planned to be publicly merged … but not sure where that project went. (This 
work be helpful for Xen too ??) 

I also implemented iSCSI + FreeNAS API into vm-bhyve a few years ago,

 - https://github.com/daviddpd/vm-bhyve/blob/freenas-iscsi/README-ISCSI.md  

(make sure you are on the freenas-iscsi branch) - and the corresponding API ...

 - https://github.com/daviddpd/ixnas-api

But these are a few years out of date and may need work.  Though, in the 
bhyve+iSCSI - the awesome thing is that each virtual disk was a raw block 
device mapped to the VM, as a iSCSI LUN, provisioned as a ZFS zvol (on the 
remote NAS via the API). “Cloning” is done on the ZFS side.  With Xen+XOA, the 
only two SR (storage repositories) are NFS and iSCSI+LVM.  And each hypervisor 
makes a single NFS or iSCSI mount.  Then each Virtual disk is managed as a .vhd 
on NFS.  With iSCSI+LVM, then the iSCSI LUN is managed with LVM, and formatted 
with ext3(4?) or xfs, and the .vhd is keep as a file in that logical volume. 
Thin provisioning not available with iSCSI on XOA/XCP. Thin 
provisioning/snapshots on NFS done with features of .vhd in XOA/XCP. With my 
iSCSI+vm-bhyve, then thin provisioning, snapshots and cloning are done in ZFS, 
on the NAS side, not in the Dom0. 

These are the only supported options in XOA - though Xen can likely do other 
things, they are implemented for easy of use in the Web UI.  Ideally I’d love 
to implement my iSCSI+ZFS for Xen and into XOA. 

--
David P. Discher 
https://davidpdischer.com/


> On Jan 4, 2020, at 9:32 AM, Stefan Parvu  wrote:
> 
> Hi,
> 
> We got a new server, where we plan to install FreeBSD 12.1 amd64 and use Xen. 
> Is there anything we could use as GUI management tools for Xen on FreeBSD ?
> 
> Im looking for some graphical user interface management software to allow 
> different people to create/manage 
> different VMs on top of Xen/FreeBSD. 
> 
> Thanks,
> 
> Stefan Parvu
> spa...@kronometrix.org
> 
> 
> 
> ___
> 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"

___
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: Slow networking speeds with Freebsd 12.0 and Xen-4.12.1, freebsd-12.0 as dom0

[Roger Pau Monné]

On Fri, Feb 14, 2020 at 10:15:48AM -0800, Brian Buhrow wrote:
>   hello.  Ok.  Perhaps I spoke too soon!  the domu I was testing with,
> which is an entirely pv guest, performs fine with FreeBSD.  However, if I
> take an hvm guest and run that using Intel E1000 emulation, my performance
> drops back to 70 mbits/sec or so of throughput.  For HVM guests, what kind
> of network performance should I expect?

That's hard to tell. My recommendation would be to try to install PV
drivers to HVM guests if possible in order to get better performance.
Performance of emulated nics is always going to be worse.

Is the QEMU process in dom0 consuming lots of CPU when using the
emulated nic?

> I've been running pv guests for
> years, but don't have much experience with hvm guests.  
> -thanks

Guests using PV devices (that applies to HVM/PVH guests also) should
always get better IO performance than those using emulated devices.

Thanks, Roger.
___
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: Slow networking speeds with Freebsd 12.0 and Xen-4.12.1, freebsd-12.0 as dom0

[Brian Buhrow]

hello.  Ok.  Perhaps I spoke too soon!  the domu I was testing with,
which is an entirely pv guest, performs fine with FreeBSD.  However, if I
take an hvm guest and run that using Intel E1000 emulation, my performance
drops back to 70 mbits/sec or so of throughput.  For HVM guests, what kind
of network performance should I expect?  I've been running pv guests for
years, but don't have much experience with hvm guests.  
-thanks

___
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: Slow networking speeds with Freebsd 12.0 and Xen-4.12.1, freebsd-12.0 as dom0

[Brian Buhrow]

hello Roger.  In building the tests for this e-mail, I think I
discovered the problem.  For the FreeBSD installation, I had guest_loglvl=all
loglvl=all on the xen command line.  When I turned that off and re-ran my
tests, the network performance on the FreeBSD system matches that of the
NetBSD system.  My apologies for the noise.
I'll perform some more tests and see how things progress.  I'm guessing,
however, that all will be well.
-thanks
-Brian

___
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: Slow networking speeds with Freebsd 12.0 and Xen-4.12.1, freebsd-12.0 as dom0

[Roger Pau Monné]

On Thu, Feb 13, 2020 at 06:58:53PM -0800, Brian Buhrow wrote:
>   Hello.  I'm noticing that network performance on guest VN's whether
> they're pv or hvm is very slow when using FreeBSD-12.0 as dom0 as compared
> with older versions of Xen and NetBSD as dom0.  For example, 
> I have the following two comparisons, both with the same domu running:
> 
> FreeBSD-12.0/Xen 4.12.1, 60 mbits/sec from the vm in question.

So I've done a small test and using a FreeBSD dom0 with a FreeBSD domU
in HVM mode and I get:

# iperf -c 192.168.1.150

Client connecting to 192.168.1.150, TCP port 5001
TCP window size:  113 KByte (default)

[  3] local 192.168.1.101 port 12224 connected with 192.168.1.150 port 5001
[ ID] Interval   Transfer Bandwidth
[  3]  0.0-10.0 sec   302 MBytes   253 Mbits/sec

This is using my macbook as an iperf server with a USB-ethernet
adapter (so not professional grade hardware at all).

I'm quite sure speed could be better, we certainly have quite a lot of
room for improvement regarding netfront/netback on FreeBSD, as no one
looked at it for quite some time.

Which OS are you using on the domU?

Can you paste the output of ifconfig from the domU? (I'm mostly
interested in knowing which features the domU is attempting to use)

Thanks, Roger.
___
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"

Slow networking speeds with Freebsd 12.0 and Xen-4.12.1, freebsd-12.0 as dom0

[Brian Buhrow]

Hello.  I'm noticing that network performance on guest VN's whether
they're pv or hvm is very slow when using FreeBSD-12.0 as dom0 as compared
with older versions of Xen and NetBSD as dom0.  For example, 
I have the following two comparisons, both with the same domu running:

FreeBSD-12.0/Xen 4.12.1, 60 mbits/sec from the vm in question.

NetBSD-5.2/xen 3.3, 781 mbits/sec with the same vm as above.

The NetBSD installation is running single CPU for the dom0, with 4GB of
RAM, as opposed to FreeBSD, which is running 8GB of RAM and 4 CPU's.
By contrast, disk performance under FreeBSD using zfs zvols' as virtual
disks is quite fast.  

As a work around, I tried turning on msi interrupt handling on dom0 on
FreeBSD, using msi=false on the xen command line at boot time, but that
only resulted in a panic from FreeBSD because it couldn't get enough disk
interrupts to mount the root filesystem.

Has anyone else noticed this abysmal network performance with
FreeBSD-12 as dom0?
If so, has anyone come up with fixes?
-thanks
-Brian

___
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"

[Bug 243993] FreeBSD as Guest with 5+ with xnb(4) devices panic on call to sysctl -a in strlen

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=243993

Roger Pau Monné  changed:

   What|Removed |Added

 CC||roy...@freebsd.org

--- Comment #1 from Roger Pau Monné  ---
(In reply to dpd from comment #0)
I'm afraid I'm not able to reproduce using Open Source Xen (and the xl
tolstack). I've created a guest with 7 vifs, using the following config file:

---
# cat freebsd.cfg
memory=512
vcpus=2
name="freebsd"

type="hvm"

disk = [
  'format=raw,vdev=xvda,access=rw,target=/root/FreeBSD-12.0-CURRENT-amd64.raw',
]

vif = [
 'mac=00:16:3E:74:3d:76,bridge=bridge0',
 'mac=00:16:3E:74:3d:77,bridge=bridge0',
 'mac=00:16:3E:74:3d:78,bridge=bridge0',
 'mac=00:16:3E:74:3d:79,bridge=bridge0',
 'mac=00:16:3E:74:3d:7a,bridge=bridge0,type=vif',
 'mac=00:16:3E:74:3d:7b,bridge=bridge0,type=vif',
 'mac=00:16:3E:74:3d:7c,bridge=bridge0,type=vif',
]

vnc=1
vnclisten="0.0.0.0"

serial='pty'

on_crash="preserve"
---

I've tested with 13.0-CURRENT and 12.1-RELEASE and haven't been able to
reproduce using either a FreeBSD or a Linux dom0:

---
root@freebsd:~ # uname -a
FreeBSD freebsd 12.1-RELEASE FreeBSD 12.1-RELEASE r354233 GENERIC  amd64
root@freebsd:~ # ifconfig -a
lo0: flags=8049 metric 0 mtu 16384
options=680003
inet6 ::1 prefixlen 128
inet6 fe80::1%lo0 prefixlen 64 scopeid 0x1
inet 127.0.0.1 netmask 0xff00
groups: lo
nd6 options=23
xn0: flags=8843 metric 0 mtu 1500
options=503
ether 00:16:3e:74:3d:70
inet6 fe80::216:3eff:fe74:3d70%xn0 prefixlen 64 scopeid 0x2
inet 10.71.57.46 netmask 0xf800 broadcast 10.71.63.255
media: Ethernet manual
status: active
nd6 options=23
xn1: flags=8843 metric 0 mtu 1500
options=503
ether 00:16:3e:74:3d:71
inet6 fe80::216:3eff:fe74:3d71%xn1 prefixlen 64 scopeid 0x3
inet 10.71.57.156 netmask 0xf800 broadcast 10.71.63.255
media: Ethernet manual
status: active
nd6 options=23
xn2: flags=8843 metric 0 mtu 1500
options=503
ether 00:16:3e:74:3d:72
inet6 fe80::216:3eff:fe74:3d72%xn2 prefixlen 64 scopeid 0x4
inet 10.71.57.165 netmask 0xf800 broadcast 10.71.63.255
media: Ethernet manual
status: active
nd6 options=23
xn3: flags=8843 metric 0 mtu 1500
options=503
ether 00:16:3e:74:3d:73
inet6 fe80::216:3eff:fe74:3d73%xn3 prefixlen 64 scopeid 0x5
inet 10.71.57.178 netmask 0xf800 broadcast 10.71.63.255
media: Ethernet manual
status: active
nd6 options=23
xn4: flags=8843 metric 0 mtu 1500
options=503
ether 00:16:3e:74:3d:74
inet6 fe80::216:3eff:fe74:3d74%xn4 prefixlen 64 scopeid 0x6
inet 10.71.57.184 netmask 0xf800 broadcast 10.71.63.255
media: Ethernet manual
status: active
nd6 options=23
xn5: flags=8843 metric 0 mtu 1500
options=503
ether 00:16:3e:74:3d:75
inet6 fe80::216:3eff:fe74:3d75%xn5 prefixlen 64 scopeid 0x7
inet 10.71.57.187 netmask 0xf800 broadcast 10.71.63.255
media: Ethernet manual
status: active
nd6 options=23
xn6: flags=8843 metric 0 mtu 1500
options=503
ether 00:16:3e:74:3d:76
inet6 fe80::216:3eff:fe74:3d76%xn6 prefixlen 64 scopeid 0x8
inet 10.71.57.189 netmask 0xf800 broadcast 10.71.63.255
media: Ethernet manual
status: active
nd6 options=23
root@freebsd:~ # sysctl -a >/dev/null
root@freebsd:~ # echo $?
0
---

Do you have any custom patches to FreeBSD?

Can you get me an xl config file out of your XCP-ng configuration?

I'm afraid I'm not familiar with XCP-ng, and hence you would have to provide me
with a xl config file in order to reproduce and figure out what's going on.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
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"

[Bug 243993] FreeBSD as Guest with 5+ with xnb(4) devices panic on call to sysctl -a in strlen

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=243993

Mark Linimon  changed:

   What|Removed |Added

   Assignee|b...@freebsd.org|x...@freebsd.org
   Keywords||panic

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
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"

xen-kernel 4.12.1 unsupported amd family !? FreeBSD

[davidheinrichplanner via freebsd-xen]

Hi Royger,

i want to inform you by freshports page but i forgett my pw and reset 
doesnt work :(.


first one i don't know which one must be informed about this problem 
(you or direct xen project, xen team by freebsd?). I have a amd epyc 
system with two cpus. And xen tell me its a unsupported amd family. How 
can be fix this problem?


its a supermicro board H11DSi-NT. (infos about it see attachment).

Best

 David


hostb0@pci0:0:0:0:  class=0x06 card=0x14501022 chip=0x14501022 rev=0x00 
hdr=0x00
vendor = 'Advanced Micro Devices, Inc. [AMD]'
device = 'Family 17h (Models 00h-0fh) Root Complex'
class  = bridge
subclass   = HOST-PCI
none0@pci0:0:0:2:   class=0x080600 card=0x14511022 chip=0x14511022 rev=0x00 
hdr=0x00
vendor = 'Advanced Micro Devices, Inc. [AMD]'
device = 'Family 17h (Models 00h-0fh) I/O Memory Management Unit'
class  = base peripheral
subclass   = IOMMU
hostb1@pci0:0:1:0:  class=0x06 card=0x chip=0x14521022 rev=0x00 
hdr=0x00
vendor = 'Advanced Micro Devices, Inc. [AMD]'
device = 'Family 17h (Models 00h-1fh) PCIe Dummy Host Bridge'
class  = bridge
subclass   = HOST-PCI
pcib1@pci0:0:1:1:   class=0x060400 card=0x14531022 chip=0x14531022 rev=0x00 
hdr=0x01
vendor = 'Advanced Micro Devices, Inc. [AMD]'
device = 'Family 17h (Models 00h-0fh) PCIe GPP Bridge'
class  = bridge
subclass   = PCI-PCI
hostb2@pci0:0:2:0:  class=0x06 card=0x chip=0x14521022 rev=0x00 
hdr=0x00
vendor = 'Advanced Micro Devices, Inc. [AMD]'
device = 'Family 17h (Models 00h-1fh) PCIe Dummy Host Bridge'
class  = bridge
subclass   = HOST-PCI
hostb3@pci0:0:3:0:  class=0x06 card=0x chip=0x14521022 rev=0x00 
hdr=0x00
vendor = 'Advanced Micro Devices, Inc. [AMD]'
device = 'Family 17h (Models 00h-1fh) PCIe Dummy Host Bridge'
class  = bridge
subclass   = HOST-PCI
hostb4@pci0:0:4:0:  class=0x06 card=0x chip=0x14521022 rev=0x00 
hdr=0x00
vendor = 'Advanced Micro Devices, Inc. [AMD]'
device = 'Family 17h (Models 00h-1fh) PCIe Dummy Host Bridge'
class  = bridge
subclass   = HOST-PCI
hostb5@pci0:0:7:0:  class=0x06 card=0x chip=0x14521022 rev=0x00 
hdr=0x00
vendor = 'Advanced Micro Devices, Inc. [AMD]'
device = 'Family 17h (Models 00h-1fh) PCIe Dummy Host Bridge'
class  = bridge
subclass   = HOST-PCI
pcib2@pci0:0:7:1:   class=0x060400 card=0x14541022 chip=0x14541022 rev=0x00 
hdr=0x01
vendor = 'Advanced Micro Devices, Inc. [AMD]'
device = 'Family 17h (Models 00h-0fh) Internal PCIe GPP Bridge 0 to Bus 
B'
class  = bridge
subclass   = PCI-PCI
hostb6@pci0:0:8:0:  class=0x06 card=0x chip=0x14521022 rev=0x00 
hdr=0x00
vendor = 'Advanced Micro Devices, Inc. [AMD]'
device = 'Family 17h (Models 00h-1fh) PCIe Dummy Host Bridge'
class  = bridge
subclass   = HOST-PCI
pcib3@pci0:0:8:1:   class=0x060400 card=0x14541022 chip=0x14541022 rev=0x00 
hdr=0x01
vendor = 'Advanced Micro Devices, Inc. [AMD]'
device = 'Family 17h (Models 00h-0fh) Internal PCIe GPP Bridge 0 to Bus 
B'
class  = bridge
subclass   = PCI-PCI
intsmb0@pci0:0:20:0:class=0x0c0500 card=0x790b15d9 chip=0x790b1022 rev=0x59 
hdr=0x00
vendor = 'Advanced Micro Devices, Inc. [AMD]'
device = 'FCH SMBus Controller'
class  = serial bus
subclass   = SMBus
isab0@pci0:0:20:3:  class=0x060100 card=0x790e15d9 chip=0x790e1022 rev=0x51 
hdr=0x00
vendor = 'Advanced Micro Devices, Inc. [AMD]'
device = 'FCH LPC Bridge'
class  = bridge
subclass   = PCI-ISA
hostb7@pci0:0:24:0: class=0x06 card=0x chip=0x14601022 rev=0x00 
hdr=0x00
vendor = 'Advanced Micro Devices, Inc. [AMD]'
device = 'Family 17h (Models 00h-0fh) Data Fabric: Device 18h; Function 
0'
class  = bridge
subclass   = HOST-PCI
hostb8@pci0:0:24:1: class=0x06 card=0x chip=0x14611022 rev=0x00 
hdr=0x00
vendor = 'Advanced Micro Devices, Inc. [AMD]'
device = 'Family 17h (Models 00h-0fh) Data Fabric: Device 18h; Function 
1'
class  = bridge
subclass   = HOST-PCI
hostb9@pci0:0:24:2: class=0x06 card=0x chip=0x14621022 rev=0x00 
hdr=0x00
vendor = 'Advanced Micro Devices, Inc. [AMD]'
device = 'Family 17h (Models 00h-0fh) Data Fabric: Device 18h; Function 
2'
class  = bridge
subclass   = HOST-PCI
hostb10@pci0:0:24:3:class=0x06 card=0x chip=0x14631022 rev=0x00 
hdr=0x00
vendor = 'Advanced Micro Devices, Inc. [AMD]'
device = 'Family 17h (Models 00h-0fh) Data Fabric: Device 18h; Function 
3'
class  = bridge
subclass   = HOST-PCI
hostb11@pci0:0:24:4:class=0x06 card=0x chip=0x14641022 

Re: FreeBSD 12.1 hypervisor management tools

[Stefan Parvu]

here, some ideas:

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=243395 

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=243397 
 


Stefan Parvu
spa...@kronometrix.org



> On 14. Jan 2020, at 16.42, Stefan Parvu  wrote:
> 
>> The first step should be to report those errors, and figure out
>> whether someone has interest in getting libvirt working on FreeBSD/Xen
>> and maintaining it in a sane state. If there's no interest we should
>> drop the Xen option from the libvirt port to not give users false
>> expectations.
> 
> Right. Makes sense. I will handle that in next days and make a short report 
> about it.
> If libvirt is not an option I would still like to see how Xen compares with 
> bhyve and kvm
> for some of our applications and usage. 
> 
> Stefan
> ___
> 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"

___
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: FreeBSD 12.1 hypervisor management tools

[Stefan Parvu]

> The first step should be to report those errors, and figure out
> whether someone has interest in getting libvirt working on FreeBSD/Xen
> and maintaining it in a sane state. If there's no interest we should
> drop the Xen option from the libvirt port to not give users false
> expectations.

Right. Makes sense. I will handle that in next days and make a short report 
about it.
If libvirt is not an option I would still like to see how Xen compares with 
bhyve and kvm
for some of our applications and usage. 

Stefan
___
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: FreeBSD 12.1 hypervisor management tools

[Roger Pau Monné]

On Tue, Jan 14, 2020 at 12:47:54AM +0200, Stefan Parvu wrote:
> >> 
> >> libvirtd, virt-manager: no go.
> >> 
> >> * I had to rebuild libvirtd with Xen support
> >> 
> >> * got occasional core dumps from libvirt
> > 
> > Can you report those? (ie: send the dumps here so they can be analyzed
> > and either fixed or forwarded to the appropriate upstream project)
> 
> 
> sure. I should put a list of defects. I need to repeat these. 
> 
> I was in hurry to check on the overall state of the project. But Im curious: 
> has 
> anyone at least tried, meaning really to use virt-manager for Xen on FreeBSD ?

I don't use libvirt at all, so I never tried it myself. I know it
works on Linux and is tested as part of the Xen CI loop, see the
-libvirt jobs in any Xen CI loop output:

http://logs.test-lab.xenproject.org/osstest/logs/146050/

So whatever is broken it's likely to be FreeBSD specific and will
require someone from the FreeBSD community to diagnose and propose
fixes.

The first step should be to report those errors, and figure out
whether someone has interest in getting libvirt working on FreeBSD/Xen
and maintaining it in a sane state. If there's no interest we should
drop the Xen option from the libvirt port to not give users false
expectations.

Thanks, Roger
___
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: Xen performance on FreeBSD vs Linux

[Roger Pau Monné]

On Mon, Jan 13, 2020 at 02:51:16PM +0100, Juergen Gotteswinter wrote:
> Am So., 12. Jan. 2020 um 20:07 Uhr schrieb Stefan Parvu <
> spa...@kronometrix.org>:
> 
> > >
> > > Also a FreeBSD dom0 can only work in PVH mode, which is faster for
> > > certain operations like page table modifications, but it's slower for
> > > others, like issuing hypercalls, when compared to a PV dom0.
> > >
> > > I don't have figures at hand now, but guest creation is likely slower
> > > on a FreeBSD PVH dom0 than on a Linux PV dom0, and that's because
> > > hypercalls are more expensive on PVH than on PV (has nothing to do
> > > whether Linux or FreeBSD is used).
> >
> > right. thanks a lot for pointers. A bit confusing is that I see mentioned
> > around that Xen of FreeBSD is experimental. Is this true ?
> >
> > I will have 2 servers to test Xen and Bhyve on FreeBSD 12.1 and check how
> > well the hypervisors work for different guest from Linux, BSD and Windows.
> >
> > Im more interested on bhyve vs Xen on FreeBSd than Linux. We will keep
> > FreeBSD as our main virtualization platform.
> >
> > Stefan
> 
> 
> FreeBSD as Dom0 feels (at least ~6 month ago) really somehow experimental
> compared to my linux experience.

Hello,

Can you give us more details regarding this comment, and what did you
feel was missing or could be improved compared to Linux?

Thanks, Roger.
___
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: Xen performance on FreeBSD vs Linux

[Roger Pau Monné]

On Sun, Jan 12, 2020 at 09:07:32PM +0200, Stefan Parvu wrote:
> > 
> > Also a FreeBSD dom0 can only work in PVH mode, which is faster for
> > certain operations like page table modifications, but it's slower for
> > others, like issuing hypercalls, when compared to a PV dom0.
> > 
> > I don't have figures at hand now, but guest creation is likely slower
> > on a FreeBSD PVH dom0 than on a Linux PV dom0, and that's because
> > hypercalls are more expensive on PVH than on PV (has nothing to do
> > whether Linux or FreeBSD is used).
> 
> right. thanks a lot for pointers. A bit confusing is that I see mentioned 
> around that Xen of FreeBSD is experimental. Is this true ? 

PVH dom0 support in Xen is experimental, the FreeBSD PVH bits are
mostly stable and I wouldn't expect many changes there except from
bug fixes. The PVH guest ABI is also stable since quite some time
ago.

Thanks, Roger.
___
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: FreeBSD 12.1 hypervisor management tools

[Roger Pau Monné]

On Sun, Jan 12, 2020 at 09:12:01PM +0200, Stefan Parvu wrote:
> > 
> > Okay, so there are some options. Will have a look on virt-manager and cbsd. 
> 
> 
> libvirtd, virt-manager: no go.
> 
> * I had to rebuild libvirtd with Xen support
> 
> * got occasional core dumps from libvirt

Can you report those? (ie: send the dumps here so they can be analyzed
and either fixed or forwarded to the appropriate upstream project)

Without us getting detailed bug reports it's very likely that this is
not going to improve.

> 
> * virt-manager is useless, cannot be used to create a simple guests from 
> debian to centos or freebsd
>
> * got all sorts of errors from virt-manager, which does not let me create or 
> boot the guest after configuration  

This should also be properly reported, what did you try, what did you
expect and what did happen instead.

Again, without getting reports it's not likely that this is going to
improve. I'm adding the FreeBSD libvirt maintainer so he is aware.

Thanks, Roger.
___
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: Xen performance on FreeBSD vs Linux

[Juergen Gotteswinter]

Am So., 12. Jan. 2020 um 20:07 Uhr schrieb Stefan Parvu <
spa...@kronometrix.org>:

> >
> > Also a FreeBSD dom0 can only work in PVH mode, which is faster for
> > certain operations like page table modifications, but it's slower for
> > others, like issuing hypercalls, when compared to a PV dom0.
> >
> > I don't have figures at hand now, but guest creation is likely slower
> > on a FreeBSD PVH dom0 than on a Linux PV dom0, and that's because
> > hypercalls are more expensive on PVH than on PV (has nothing to do
> > whether Linux or FreeBSD is used).
>
> right. thanks a lot for pointers. A bit confusing is that I see mentioned
> around that Xen of FreeBSD is experimental. Is this true ?
>
> I will have 2 servers to test Xen and Bhyve on FreeBSD 12.1 and check how
> well the hypervisors work for different guest from Linux, BSD and Windows.
>
> Im more interested on bhyve vs Xen on FreeBSd than Linux. We will keep
> FreeBSD as our main virtualization platform.
>
> Stefan


FreeBSD as Dom0 feels (at least ~6 month ago) really somehow experimental
compared to my linux experience. i would go the bhyve route if your
hardware supports the required cpu features.
___
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: FreeBSD 12.1 hypervisor management tools

[Stefan Parvu]

> 
> Okay, so there are some options. Will have a look on virt-manager and cbsd. 


libvirtd, virt-manager: no go.

* I had to rebuild libvirtd with Xen support

* got occasional core dumps from libvirtd 

* virt-manager is useless, cannot be used to create a simple guests from debian 
to centos or freebsd

* got all sorts of errors from virt-manager, which does not let me create or 
boot the guest after configuration  

* probable easier is just to stick with xl cli 

cbsd: havent tried yet.

Thanks,
Stefan
___
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: bridge0 settings for VMs

[Stefan Parvu]

> Just remove SYNCDHCP


Cheers. That was working fine. 

Stefan
___
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: bridge0 settings for VMs

[Miroslav Lachman]

Stefan Parvu wrote on 2020/01/10 10:31:

Hi,

Under the documentation [1] there are pointers about how one would define an 
interface for all domUs.
Now the documentation says:

# sysrc cloned_interfaces="bridge0"
# sysrc ifconfig_bridge0="addm em0 SYNCDHCP"
# sysrc ifconfig_em0=“up”

where em0 is the main interface.

Now I have  server which has a functional em1 interface running and configured. 
I want to define a bridge0 interface for all domains, but not to use DHCP, 
because I dont have a DHCP server on that network.

Any ideas how shall I configure the bridge0 interface using 
ifconfig_bridge0=“..."


Just remove SYNCDHCP

For example:

cloned_interfaces="bridge0 tap0"
ifconfig_bridge0="addm bge0 up addm tap0 up"

It will create bridge0 with bge0 and tap0 as a members.

bridge0: flags=8843 metric 0 mtu 
1500

ether 02:71:2c:00:ca:00
nd6 options=9
groups: bridge
id 00:00:00:00:00:00 priority 32768 hellotime 2 fwddelay 15
maxage 20 holdcnt 6 proto rstp maxaddr 2000 timeout 1200
root id 00:00:00:00:00:00 priority 32768 ifcost 0 port 0
member: tap0 flags=143
ifmaxaddr 0 port 5 priority 128 path cost 200
member: bge0 flags=143
ifmaxaddr 0 port 1 priority 128 path cost 55

Kind regards
Miroslav Lachman
___
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: Xen performance on FreeBSD vs Linux

[Roger Pau Monné]

On Mon, Jan 06, 2020 at 12:43:51PM +0200, Stefan Parvu wrote:
> Hi,
> 
> How Xen hypervisor compares in terms of performance (guest) on FreeBSD vs 
> Linux
> , using ZFS or UFS ?

There are several factors to take into account here.

On FreeBSD the hypervisor is built with clang, while on Linux it's
usually built with gcc, and hence different optimizations will be
used.

Also a FreeBSD dom0 can only work in PVH mode, which is faster for
certain operations like page table modifications, but it's slower for
others, like issuing hypercalls, when compared to a PV dom0.

I don't have figures at hand now, but guest creation is likely slower
on a FreeBSD PVH dom0 than on a Linux PV dom0, and that's because
hypercalls are more expensive on PVH than on PV (has nothing to do
whether Linux or FreeBSD is used).

> Are there any benchmarks or tests regarding this ?

I don't think so, but I think they will be useful if someone has the
time to perform them :).

Thanks, Roger.
___
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"