Re: NetBSD-10 PVH under xen 4.16.0 working fine, but no bootloader

[Greg Troxel <gdt%lexort.com@localhost>]

"Aaron J. Grier" <agrier%poofygoof.com@localhost> writes:

> it's an extra added step to updates, even though I do maintain both the
> dom0 and domU here at home. :)

Understood.  What I do is just load a kernel straight from my rsync of
releasedir for that arch/version, as I am building netbsd-N/$arch and
sync them to the xen dom0 anyway.   I realize that may not be what you
want, but it works for me.

> aren't the PV memory management interfaces still available in PVH?  it
> seems like there should be a grub2-pvh, but I've not been able to
> definitively nail its existance down.

I would suggest not assuming that and really looking into it.  I believe
that that the theory is that the use of hardware virtualization for page
table changes is much more efficient than the pv approach, and thus the
h part of pvh is about that, while still using pv for disk, network and
console.  Because the hvm support is limited to memory management and
not IO, the dom0 side does not need qemu and it can be be done in xen
itself.  But that's my slightly fuzzy understanding, not necessarily
100% right.

> alternately pygrub seems like it should still work for PVH, since it
> runs in the context of dom0, and I have it working for PVs with FFSv1
> roots.  I haven't dug into it too far, and suspect it may be looking for
> a PV-specific signature that isn't in the PVH kernel.

Maybe, but pygrub is as I understand it ancient and unmaintained and I
personally would not go down that path

>> You might also consider hvm mode.   In my experience, on one hardware
>> system, hvm is faster than pvh, 34s vs 46s for the standard workload
>> of compiling devel/m4.    This will use boot blocks in the domU, as if
>> it were a computer, and that's easy.  The downside is using qemu.
>>
>> Note that 'hvm' in the config leads to 'pvhvm' with a NetBSD 10
>> kernel.
>
> PVHVM being faster than PVH seems counter-intuitive. in the best case
> PVHVM seems like it should be using equivalent calls to PVH as soon it
> is out of the bootloader, and wouldn't have anything going through qemu,
> but obviously I'm making a bad assumption or don't understand the flow.
> :)

I think there is indeed fairly little in qemu, but it is different in
speed on my system (12th gen intel).  34.4s pvhvm, 46.7s pvh.  That's
for devel/m4 as
  make MAKE_JOBS=1 IGNORE_CCACHE=t package clean

PVHVM does let you have the kernel on the system, and to do that with no
extra complexity.

One should be able to make grub that works with pvh, by enabling pv ops
for disk and console but not for memory.   If you want to use pvh that
is the path I would go down, starting with reading code and talking to
upstream.