Re: merge bouyer-xenpvh to HEAD
Chavdar Ivanov <[email protected]> Sun, 26 Apr 2020 18:06:36 +0100
| Newsgroups | gmane.os.netbsd.ports.x86-64,gmane.os.netbsd.ports.xen,gmane.os.netbsd.ports.i386 |
|---|---|
| Message-ID | <CAG0OUxh1948hna-hzBASrOytVVCphYOikg+pPk_DGaV6_X7Q1g@mail.gmail.com> |
On Sun, 26 Apr 2020 at 16:52, Manuel Bouyer <[email protected]> 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 db{0}> bt ... wskbd_translate, wskb_input, pckbd_input, intr_biglock_wrapper, Xhandle_ioapic_edge1 ... --- 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 db{0}> ... The point is, FreeBSD 12 works with platform:viridian set to True: Hyper-V Version: 0.0.0 [SP0] Features=0x870<APIC,HYPERCALL,VPINDEX,TMFREQ> PM Features=0x0 [C0] Features3=0x0 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 ecosystem. > > -- > Manuel Bouyer <[email protected]> > NetBSD: 26 ans d'experience feront toujours la difference > -- Chavdar -- ----