Re: VW ELF loader

[David Gibson <david@gibson.dropbear.id.au>]

[-- Attachment #1: Type: text/plain, Size: 3556 bytes --]

On Mon, Feb 10, 2020 at 12:26:07PM +0100, Paolo Bonzini wrote:
> On 10/02/20 08:28, David Gibson wrote:
> > On Thu, Feb 06, 2020 at 09:27:01AM +0100, Paolo Bonzini wrote:
> >> On 05/02/20 07:06, David Gibson wrote:
> >>> On Tue, Feb 04, 2020 at 12:26:32AM +0100, Paolo Bonzini wrote:
> >> I'm really sorry if what I am saying is stupid; but I was thinking of a
> >> firmware entrypoint like
> >>
> >> 	if (op == "read" || op == "write")
> >> 		do_driver_stuff(op);
> >> 	else
> >> 		hypercall();
> > 
> > Um... I'm not really clear on where you're imagining this going.  In
> > the OF model, device operations are done by "opening" a device tree
> > node then executing methods on it, so you can't really even get to
> > this point without a bunch of DT stuff.
> 
> Could you delegate that part to QEMU, as in the v6 patches?  The
> firmware would record the path<->ihandle association on open and close,
> and then you can use that when GRUB does "read" and "write" to invoke
> the appropriate driver.
> 
> >> This is not even close to pseudocode, but hopefully enough to give the
> >> idea.  Perhaps what I don't understand is why you can't start the
> >> firmware with r3 pointing to the device tree, and stash it for when you
> >> leave control to GRUB.
> > 
> > Again, I'm not even really sure what you mean by this.  We already
> > enter SLOF with r3 pointing to a device tree.  I'm not sure what
> > stashing it would accomplish.  GRUB as it stands expects an OF style
> > entry point though, not a flat tree style entry point.
> 
> Again, sorry if what I'm saying makes little sense.  The terminology is
> certainly off.  What I mean is:
> 
> - read the device tree, instantiate all PCI and virtio drivers
> 
> - keep the device tree around for use while GRUB is running
> 
> - find and invoke GRUB
> 
> - on the OF entry point, wrap open and close + handle the disk and
> network entry points, and pass everything else to QEMU.
> 
> >> The TTY can use the simple
> >> getchar/putchar hypercalls,
> > 
> > Yes... though if people attach a graphical console they might be
> > pretty surprised that they don't get anything on there.
> 
> They wouldn't with Alexey's code either, would they?  And it would be
> yet another QEMU backend to hook into, while with firmware it would be
> lots of code to write but super-boring and something that has been done
> countless times.

That's a fair point.

> > We can possibly ignore the spapr virtual devices.  They seemed like
> > they'd be important for people transitioning from guests under
> > PowerVM, but honestly I'm not sure they've ever been used much.
> > 
> > We do support emulated (or passthrough) PCI devices.  I don't know if
> > they're common enough that we need boot support for them.  Netboot
> > from a vfio network adaptor might be something people want.
> 
> Can you get that with SLOF?

I think yes, if your passthrough device is one of the small number
supported by SLOF.

> > USB storage is also a fairly likely candidate, and that would add a
> > *lot* of extra complexity, since we'd need both the HCD and storage
> > drivers.
> 
> Any reason to make it USB and not a virtio-blk device?  (On x86 these
> days you only add USB storage disks to a VM in order to get drivers to
> Windows).

Hm, yeah, maybe.

-- 
David Gibson			| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au	| minimalist, thank you.  NOT _the_ _other_
				| _way_ _around_!
http://www.ozlabs.org/~dgibson

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]