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
signature.asc
Description: PGP signature