[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: merge bouyer-xenpvh to HEAD
On Sun, 26 Apr 2020 at 16:52, Manuel Bouyer <bouyer%antioche.eu.org@localhost> wrote:
> On Sun, Apr 26, 2020 at 01:35:34PM +0100, Chavdar Ivanov wrote:
> > [...]
> > I presume this is the equivalent to the text file you show.
> no idea
> > I did a complete new installation of 9.99.59 under XCP-NG, in efi mode
> > with gpt labels; before rebooting I replaced the kernel with the one
> > from your repo. When platform:viridian is set, it works as fine as
> When platform:viridian Xen identifies itself as hyper-v, so PV drivers
> are not used.
Understood, everything works as before in HVM mode, when using GNERIC from HEAD.
> > ever; if I unset it, it boots, displays all the kernel configuration
> > messages in the console window and enters idle loop, never starting
> > init; one can enter the debugger here. I took screenshots of the
> > kernel configuration messages - it appears everything is recognized,
> > but it sees two disks - xbd0 and xbd1, the former containing all the
> > gpt slices reported further down. xennet0 is also reported with its
> > mac address.
> It's strange that there are 2 devices. Any what this xbd1 is ?
No, but I vaguely recall having similar problem many years ago on an
old version of Xen
> Do you have 2 ATA devices showing up when booting wuth platform:viridian
> set ?
No, there is only a single 32GB disk allocated:
# xe vm-disk-list uuid=ce92d1de-aa1d-7b4f-97d4-d56da032339c
Disk 0 VBD:
uuid ( RO) : e43f463d-688c-c586-19f0-91e3cbd1db07
vm-name-label ( RO): n999-pvhvm
userdevice ( RW): 0
Disk 0 VDI:
uuid ( RO) : 7930785d-c40e-4372-9ab1-31e4e1cfdb42
name-label ( RW): n99959-pvhvm
sr-name-label ( RO): sdb
virtual-size ( RO): 34359738368
shows the virtual block device and the associated virtual disk; I can
list their parameters, the pointers are correct.
Transcribed from the screenshot ( I miss earlier messages related to Xen):
Xensource, Inc Xen Platform Device (SCSI mass storage, revision 0.x01)
at pci0 dev 3 function 0 not configured
xbd0 at xenbus0 id 768: Xen Virtual Block Device Interface
xbd1 at xenbus0 id 5696: Xen Virtual Block Device Interface
xennet0 at xenbus0 id 0: Xen Virtual Network Interface
pool redzone disabled for 'xnfrx'
xennet0: MAC address xx:xx:xx:xx:xx:xx
baloon at xenbus0 id 0 not configured
xennet0: using RX copy mode
xbd0: 34359738368, 512 bytes/sect x 67108864 sectors
dk0 at xbd0: "....", 262144 blocks at 64, type: msdos
dk1 at xbd0: "....", 65814461 blocks at 262272, type: ffs
dk2 at xbd0: "....", 1032095 blocks at 66076367, type: swap
cd0 at atapibus0 drive 1: <QEMU DVD-ROM, QM00004, 0.10> cdrom removable
(I interrupt here with CtrlAltEsc)
Stopped in pid 0.2 (system) at netbsd:breakpoint+0x5: leave
wskbd_translate, wskb_input, pckbd_input, intr_biglock_wrapper,
--- interrupt ---
x86_stihlt() at netbsd:x86_stihlt+0x6
acpicpu_cstate_idle_enter() at netbsd:acpicpu_cstate_idle_enter+0xd1
acpicpu_cstate_idle() at netbsd:acpicpu_cstate_idle+0xba
idle_loop() at netbsd:idle_loop+0c13c
The point is, FreeBSD 12 works with platform:viridian set to True:
Hyper-V Version: 0.0.0 [SP0]
PM Features=0x0 [C0]
XEN: Hypervisor version 4.13 detected.
Hypervisor: Origin = "Microsoft Hv" <----- platform:viridian=True
by default for this vm
and further down all Xen-related devices are recognised.
It seems in the NetBSD case once the hypervisor is recognised as
Hyper-V, it stops further any attempts to discover Xen.
I realise most of the exchanges in this thread pertain to detailed
technical issues related to this implementation and apologise if I
have hijacked the topic with this XCP-NG related query. But it would
be nice to get NetBSD to run as well as it can under this platform -
while I understand your primary objective is Xen as part of the NetBSD
> Manuel Bouyer <bouyer%antioche.eu.org@localhost>
> NetBSD: 26 ans d'experience feront toujours la difference
Main Index |
Thread Index |