qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: VW ELF loader


From: David Gibson
Subject: Re: VW ELF loader
Date: Wed, 5 Feb 2020 17:06:34 +1100

On Tue, Feb 04, 2020 at 12:26:32AM +0100, Paolo Bonzini wrote:
> Il mar 4 feb 2020, 00:20 Alexey Kardashevskiy <address@hidden> 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.

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.

> Netboot's dhcp/tftp/ip/ipv6 client? It is going to be another SLOF,
> > smaller but adhoc with only a couple of people knowing it.

Netboot I will grant is a pretty thorny problem, whichever way we
tackle it.

> 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.  In any case it sounds like the s390 code is
actually based on the SLOF code anyway.

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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]