Re: VW ELF loader

[Alexey Kardashevskiy <aik@ozlabs.ru>]

On 06/02/2020 19:27, 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:
>>> Il mar 4 feb 2020, 00:20 Alexey Kardashevskiy <aik@ozlabs.ru> ha scritto:
>>>> Speaking seriously, what would I put into the guest?
>>>
>>> Only things that would be considered drivers. Ignore the partitions issue
>>> for now so that you can just pass the device tree services to QEMU with
>>> hypercalls.
>>
>> Urgh... first, I don't really see how you'd do that.  OF's whole
>> device model is based around the device tree.  So implementing OF
>> driver interactions would require the firmware to do a bunch of
>> internal hypercalls to do all the DT stuff, which brings us back to a
>> much more complex and active interface between firmware and hypervisor
>> than we really want.
> 
> 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);


do_driver_stuff() will require assigned PCI BARs, PCI bridge windows,
IOMMU. So QEMU or this new not-SLOF firmware will have to do this all.
This is a lot and what is exactly the benefit? My alternative does not
need drivers at all.


> 	else
> 		hypercall();
> 
> 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. > Or to put it another way, what petitboot does
> that you cannot do in your own firmware.

Petitboot has all PCI code and driver ready, it can easily boot from
even passed through PCI devices which neither SLOF nor QEMU will have
drivers for.


>> Second, drivers are kind of where we'd get the most benefit by putting
>> them in qemu: from qemu we can just talk to the device backends
>> directly so we don't need to re-abstract the differences between
>> different device models of the same type.
> 
> Of course, but drivers are easy to write.  Not as easy as s390 probably
> because you'd have to link in libfdt and so on, but between
> kvm-unit-tests and s390-ccw there's quite a bit of code can be reused.
> 
>>> You can generalize and reuse the s390 code. All you have to write is the
>>> PCI scan and virtio-pci setup.
>>
>> If we assume virtio only.
> 
> Do you actually need something else?  

spapr-vscsi and usb-storage, probably.


> The TTY can use the simple
> getchar/putchar hypercalls, and sPAPR-vSCSI clients can keep using SLOF.

If we are open to the idea of using SLOF for one thing and new small
firmware for another thing, then it would make more sense to use
petitboot instead of SLOF.


-- 
Alexey