qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Paolo Bonzini <pbonzini@redhat.com>
To: David Gibson <david@gibson.dropbear.id.au>
Cc: Thomas Huth <thuth@redhat.com>,
	Alexey Kardashevskiy <aik@ozlabs.ru>,
	qemu-devel <qemu-devel@nongnu.org>,
	Cornelia Huck <conny@cornelia-huck.de>,
	Christian Borntraeger <borntraeger@de.ibm.com>,
	Stefano Garzarella <sgarzare@redhat.com>
Subject: Re: VW ELF loader
Date: Thu, 6 Feb 2020 09:27:01 +0100	[thread overview]
Message-ID: <62d62fab-46a4-240b-037b-409ba859b93d@redhat.com> (raw)
In-Reply-To: <20200205060634.GI60221@umbus.fritz.box>

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);
	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.

> 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?  The TTY can use the simple
getchar/putchar hypercalls, and sPAPR-vSCSI clients can keep using SLOF.

Paolo



  parent reply	other threads:[~2020-02-06  8:28 UTC|newest]

Thread overview: 48+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-02-01 13:39 VW ELF loader Alexey Kardashevskiy
2020-02-01 19:04 ` Paolo Bonzini
2020-02-02 11:51   ` Alexey Kardashevskiy
2020-02-02 17:38     ` Paolo Bonzini
2020-02-03  1:31       ` David Gibson
2020-02-03  1:28   ` David Gibson
2020-02-03  9:12     ` Paolo Bonzini
2020-02-03  9:50       ` David Gibson
2020-02-03 10:58       ` Alexey Kardashevskiy
2020-02-03 15:08         ` Paolo Bonzini
2020-02-03 22:36           ` Alexey Kardashevskiy
2020-02-03 22:56             ` Paolo Bonzini
2020-02-03 23:19               ` Alexey Kardashevskiy
2020-02-03 23:26                 ` Paolo Bonzini
2020-02-04  6:16                   ` Thomas Huth
2020-02-04  8:54                     ` Cornelia Huck
2020-02-04  9:20                       ` Restrictions of libnet (was: Re: VW ELF loader) Thomas Huth
2020-02-04  9:32                         ` Thomas Huth
2020-02-04  9:33                         ` Michal Suchánek
2020-02-05  5:30                         ` David Gibson
2020-02-05  6:24                           ` Thomas Huth
2020-02-10  7:55                             ` David Gibson
2020-02-10  9:39                               ` Michal Suchánek
2020-02-13  3:16                                 ` David Gibson
2020-02-04 23:18                   ` VW ELF loader Alexey Kardashevskiy
2020-02-05  6:06                   ` David Gibson
2020-02-05  9:28                     ` Cornelia Huck
2020-02-06  4:47                       ` David Gibson
2020-02-06  8:27                     ` Paolo Bonzini [this message]
2020-02-06 23:17                       ` Alexey Kardashevskiy
2020-02-06 23:45                         ` Paolo Bonzini
2020-02-10  7:30                           ` David Gibson
2020-02-10 10:37                             ` Peter Maydell
2020-02-10 11:25                             ` Paolo Bonzini
2020-02-14  3:23                               ` David Gibson
2020-02-10  7:28                       ` David Gibson
2020-02-10 11:26                         ` Paolo Bonzini
2020-02-14  4:02                           ` David Gibson
2020-02-05  5:58           ` David Gibson
2020-02-06  8:29             ` Paolo Bonzini
2020-02-06 23:23               ` Alexey Kardashevskiy
2020-02-06 23:46                 ` Paolo Bonzini
2020-02-10  0:31                   ` Alexey Kardashevskiy
2020-02-13  1:43                     ` Alexey Kardashevskiy
2020-02-13 10:17                       ` Paolo Bonzini
2020-02-14  0:01                         ` Alexey Kardashevskiy
2020-02-14  2:30                           ` David Gibson
2020-02-04  9:40   ` Christian Borntraeger

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=62d62fab-46a4-240b-037b-409ba859b93d@redhat.com \
    --to=pbonzini@redhat.com \
    --cc=aik@ozlabs.ru \
    --cc=borntraeger@de.ibm.com \
    --cc=conny@cornelia-huck.de \
    --cc=david@gibson.dropbear.id.au \
    --cc=qemu-devel@nongnu.org \
    --cc=sgarzare@redhat.com \
    --cc=thuth@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).