On Fri, Feb 14, 2020 at 11:01:26AM +1100, Alexey Kardashevskiy wrote:
> 
> 
> On 13/02/2020 21:17, Paolo Bonzini wrote:
> > On 13/02/20 02:43, Alexey Kardashevskiy wrote:
> >>
> >> Ok. So, I have made a small firmware which does OF CI, loads GRUB and
> >> instantiates RTAS:
> >> https://github.com/aik/of1275
> >> Quite raw but gives the idea.
> >>
> >> It does not contain drivers and still relies on QEMU to hook an OF path
> >> to a backend. Is this a showstopper and without drivers it is no go? Thanks,
> > 
> > Yes, it's really the drivers.  Something like netboot wouldn't work for
> > example.
> > 
> > I don't have a problem with relying on QEMU for opening and closing OF
> > paths, but I really believe that read/write on ihandles should be done
> > within the firmware and not QEMU.
> 
> Moving read/write to the firmware is not a problem but there is a little
> mix up here :)
> 
> An ihandle is open from a path and nothing there suggests drivers, it is
> up to the ihandle's "read" method what happens next.
> 
> If we do PCI drivers in the firmware, then the entire ihandle (==
> "opened instance of a phandle") business goes to the firmware and we are
> slowly bringing the existing mess back again.

Right, even setting aside the specifics of how ihandles are managed,
having the device tree in qemu but device handling in firmware seems
like an even more complex interaction between qemu and firmware pieces
of the environment, which is what we've been trying to avoid here.

-- 
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