All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sergio Lopez <slp@redhat.com>
To: Gerd Hoffmann <kraxel@redhat.com>
Cc: ehabkost@redhat.com, maran.wilson@oracle.com, mst@redhat.com,
	qemu-devel@nongnu.org, pbonzini@redhat.com, rth@twiddle.net
Subject: Re: [Qemu-devel] [PATCH v2 4/4] hw/i386: Introduce the microvm machine type
Date: Tue, 02 Jul 2019 10:42:01 +0200	[thread overview]
Message-ID: <878stgygiu.fsf@redhat.com> (raw)
In-Reply-To: <20190702081733.ff6cboiddln5wmti@sirius.home.kraxel.org>

[-- Attachment #1: Type: text/plain, Size: 1169 bytes --]


Gerd Hoffmann <kraxel@redhat.com> writes:

>   Hi,
>
>> Microvm only supports booting PVH-enabled Linux ELF images. Booting
>> other PVH-enabled kernels may be possible, but due to the lack of ACPI
>> and firmware, we're relying on the command line for specifying the
>> location of the virtio-mmio transports. If there's an interest on
>> using this machine type with other kernels, we'll try to find some
>> kind of middle ground solution.
>
> Can we get rid of the kernel command line hacking please?
> The virtio-mmio devices should be discoverable somehow.
>
> Device tree (as suggested by paolo) would work.
> Custom acpi device (simliar to fw_cfg) is another option.
> I'd tend to pick acpi, I wouldn't be surprised if we'll
> need acpi anyway at some point.
>
> Maybe even do both, then switch at runtime depending on -no-acpi
> (simliar to arm/aarch64).

Microvm tries to do things in the cheapest possible way. As I said the
other email, I'm not opposed to support qboot (which will probably imply
ACPI and/or device tree), as long it's optional, and the "cheap" way is
still present.

Otherwise, let's just drop microvm and stick with Q35 + qboot.

Sergio.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

  reply	other threads:[~2019-07-02  8:43 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-07-01 14:47 [Qemu-devel] [PATCH v2 0/4] Introduce the microvm machine type Sergio Lopez
2019-07-01 14:47 ` [Qemu-devel] [PATCH v2 1/4] hw/virtio: Factorize virtio-mmio headers Sergio Lopez
2019-07-01 14:47 ` [Qemu-devel] [PATCH v2 2/4] hw/i386: Add an Intel MPTable generator Sergio Lopez
2019-07-02  8:02   ` Gerd Hoffmann
2019-07-02  8:37     ` Sergio Lopez
2019-07-02  9:33       ` Gerd Hoffmann
2019-07-01 14:47 ` [Qemu-devel] [PATCH v2 3/4] hw/i386: Factorize PVH related functions Sergio Lopez
2019-07-01 14:47 ` [Qemu-devel] [PATCH v2 4/4] hw/i386: Introduce the microvm machine type Sergio Lopez
2019-07-02  8:17   ` Gerd Hoffmann
2019-07-02  8:42     ` Sergio Lopez [this message]
2019-07-02 10:16       ` Gerd Hoffmann
2019-07-02 10:52         ` Sergio Lopez
2019-07-02 11:50           ` Gerd Hoffmann
2019-07-02 14:06           ` Paolo Bonzini
2019-07-02 14:41             ` Sergio Lopez
2019-07-18 14:34               ` Sergio Lopez
2019-07-18 15:48                 ` Paolo Bonzini
2019-07-19 10:30                   ` Sergio Lopez
2019-07-19 11:49                     ` Paolo Bonzini
2019-07-02  8:19   ` Stefano Garzarella
2019-07-02  8:47     ` Sergio Lopez
2019-07-02 10:37       ` Paolo Bonzini
2019-07-02 11:16         ` Sergio Lopez
2019-07-01 18:32 ` [Qemu-devel] [PATCH v2 0/4] " no-reply
2019-07-01 19:06 ` no-reply

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=878stgygiu.fsf@redhat.com \
    --to=slp@redhat.com \
    --cc=ehabkost@redhat.com \
    --cc=kraxel@redhat.com \
    --cc=maran.wilson@oracle.com \
    --cc=mst@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=rth@twiddle.net \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.