All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Michael S. Tsirkin" <mst@redhat.com>
To: Eduardo Habkost <ehabkost@redhat.com>
Cc: "Marc-André Lureau" <marcandre.lureau@redhat.com>,
	qemu-devel@nongnu.org, imammedo@redhat.com, anderson@redhat.com,
	berrange@redhat.com, lersek@redhat.com,
	"Ben Warren" <ben@skyportsystems.com>
Subject: Re: [Qemu-devel] [PATCH 1/7] vmgenid: replace x-write-pointer-available hack
Date: Mon, 3 Jul 2017 22:51:21 +0300	[thread overview]
Message-ID: <20170703224820-mutt-send-email-mst@kernel.org> (raw)
In-Reply-To: <20170703185052.GT12152@localhost.localdomain>

On Mon, Jul 03, 2017 at 03:50:52PM -0300, Eduardo Habkost wrote:
> On Mon, Jul 03, 2017 at 09:38:52PM +0300, Michael S. Tsirkin wrote:
> > On Thu, Jun 29, 2017 at 03:23:04PM +0200, Marc-André Lureau wrote:
> > > This compat property sole function is to prevent the device from being
> > > instantiated. Instead of requiring an extra compat property, check if
> > > fw_cfg has DMA enabled.
> > > 
> > > This has the additional benefit of handling other cases properly, like:
> > > 
> > >   $ qemu-system-x86_64 -device vmgenid -machine none
> > >   qemu-system-x86_64: -device vmgenid: vmgenid requires DMA write support in fw_cfg, which this machine type does not provide
> > >   $ qemu-system-x86_64 -device vmgenid -machine pc-i440fx-2.9 -global fw_cfg.dma_enabled=off
> > >   qemu-system-x86_64: -device vmgenid: vmgenid requires DMA write support in fw_cfg, which this machine type does not provide
> > >   $ qemu-system-x86_64 -device vmgenid -machine pc-i440fx-2.6 -global fw_cfg.dma_enabled=on
> > >   [boots normally]
> > > 
> > > Suggested-by: Eduardo Habkost <ehabkost@redhat.com>
> > > Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
> > 
> > It's a nice cleanup, but I suspect we need to first implement
> > a framework for initialization ordering. I don't much like it
> > that we are adding more dependencies to the current bag of hacks.
> 
> I agree we should address this, but in this case there's no need to
> introduce new mechanisms for initialization ordering if we just check
> the dependencies on machine_done notifier or acpi_setup() (which is
> called by machine_done).

I guess what should fail is attempt to register a writeable blob.
This sounds reasonable.

> -- 
> Eduardo

  reply	other threads:[~2017-07-03 19:51 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-06-29 13:23 [Qemu-devel] [PATCH 0/7] KASLR kernel dump support Marc-André Lureau
2017-06-29 13:23 ` [Qemu-devel] [PATCH 1/7] vmgenid: replace x-write-pointer-available hack Marc-André Lureau
2017-06-29 14:11   ` Michael S. Tsirkin
2017-07-02  3:09   ` Ben Warren
2017-07-03 14:48   ` Eduardo Habkost
2017-07-03 18:06   ` Laszlo Ersek
2017-07-03 18:27     ` Eduardo Habkost
2017-07-03 18:35       ` Laszlo Ersek
2017-07-03 18:21   ` Michael S. Tsirkin
2017-07-03 18:38   ` Michael S. Tsirkin
2017-07-03 18:50     ` Eduardo Habkost
2017-07-03 19:51       ` Michael S. Tsirkin [this message]
2017-06-29 13:23 ` [Qemu-devel] [PATCH 2/7] acpi: add vmcoreinfo device Marc-André Lureau
2017-07-04 22:07   ` Laszlo Ersek
2017-07-05 13:54     ` Marc-André Lureau
2017-06-29 13:23 ` [Qemu-devel] [PATCH 3/7] tests: add simple vmcoreinfo test Marc-André Lureau
2017-06-29 13:23 ` [Qemu-devel] [PATCH 4/7] dump: add vmcoreinfo ELF note Marc-André Lureau
2017-07-04 23:48   ` Laszlo Ersek
2017-07-05 21:52     ` Marc-André Lureau
2017-07-06 10:29       ` Laszlo Ersek
2017-06-29 13:23 ` [Qemu-devel] [PATCH 5/7] kdump: " Marc-André Lureau
2017-07-05  0:07   ` Laszlo Ersek
2017-07-06 10:05     ` Marc-André Lureau
2017-06-29 13:23 ` [Qemu-devel] [PATCH 6/7] scripts/dump-guest-memory.py: add vmcoreinfo Marc-André Lureau
2017-07-05  0:22   ` Laszlo Ersek
2017-07-05  9:58     ` Marc-André Lureau
2017-07-05 11:05       ` Laszlo Ersek
2017-06-29 13:23 ` [Qemu-devel] [PATCH 7/7] MAINTAINERS: add Dump maintainers Marc-André Lureau
2017-07-05  0:26   ` Laszlo Ersek
2017-07-06  9:54     ` Marc-André Lureau
2017-07-06 10:17       ` Laszlo Ersek

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=20170703224820-mutt-send-email-mst@kernel.org \
    --to=mst@redhat.com \
    --cc=anderson@redhat.com \
    --cc=ben@skyportsystems.com \
    --cc=berrange@redhat.com \
    --cc=ehabkost@redhat.com \
    --cc=imammedo@redhat.com \
    --cc=lersek@redhat.com \
    --cc=marcandre.lureau@redhat.com \
    --cc=qemu-devel@nongnu.org \
    /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.