Port-xen archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: NetBSD-10 PVH under xen 4.16.0 working fine, but no bootloader
On Thu, Oct 24, 2024 at 08:13:48AM -0400, Greg Troxel wrote:
> "Aaron J. Grier" <agrier%poofygoof.com@localhost> writes:
>
> > I can't figure out the right incancation for a grub2-pvh to load a
> > kernel off the VM block storage, (where to get grub2-pvh?) and ye
> > olde pygrub (which works for PV instances with ffsv1) doesn't seem
> > to work for PVH, so I'm loading the kernel directly with kernel=.
>
> Your message was a little hard to follow. I assume you are talking
> about domU pvh; dom0 is a different situation.
Yes, sorry, these are DomU PVH VMs.
> I think most people running their own systems load the kernel as
> kernel= in the xen config file. That's fine, except that if the domU
> and the dom0 are under different administrative control, the domU
> admin can't swap the kernel.
it's an extra added step to updates, even though I do maintain both the
dom0 and domU here at home. :)
> It sounds like you want to use grub or something as kernel= and have
> that load the kernel. I would suggest reading the grub code to see
> what interfaces are used in pv mode, and if you can switch to not use
> pv memory management, but only disk.
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.
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.
> 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.
:)
--
Aaron J. Grier | "Not your ordinary poofy goof." | agrier%poofygoof.com@localhost
"The price of reliability is the pursuit of the utmost simplicity. It
is a price which the very rich find most hard to pay." -- Tony Hoare
Home |
Main Index |
Thread Index |
Old Index