From: Gerd Hoffmann <kraxel@redhat.com>
To: "Marc Marí" <marc.mari.barcelo@gmail.com>
Cc: "Gabriel L. Somlo" <somlo@cmu.edu>,
qemu-devel@nongnu.org, "Kevin O'Connor" <kevin@koconnor.net>,
"Stefan Hajnoczi" <stefanha@redhat.com>,
"Paolo Bonzini" <pbonzini@redhat.com>,
"Marc Marí" <markmb@redhat.com>, Laszlo <lersek@redhat.com>
Subject: Re: [Qemu-devel] [PATCH v4] Add optionrom compatible with fw_cfg DMA version
Date: Tue, 02 Feb 2016 15:23:32 +0100 [thread overview]
Message-ID: <1454423012.9300.99.camel@redhat.com> (raw)
In-Reply-To: <20160202140733.6cef6568@crunchbang>
Hi,
> I don't remember discussing the topic of machine types when touching
> fw_cfg DMA. Which means, it probably slipped amongst the other details.
> But it is now merged and in stable, so it should probably be left as it
> is now.
We have to fix it, it breaks live migration. With fw_cfg_dma turned on
we send an extra vmstate section. qemu 2.4 (+older) will not understand
it. So we have to turn it off for those machine types.
dma_enabled property is there already, but the logic is wrong. It
defaults to false, but is flipped to true when the arch supports dma
(i.e. on x86 and arm), unconditionally. Instead it should default to
true. When set to false by the user or compat properties don't enable
fw_cfg dma (and also flip it to false when dma is not supported by the
arch).
> Should this optionrom be enabled only with the latest machine type?
The logic to pick the correct rom is fine.
cheers,
Gerd
next prev parent reply other threads:[~2016-02-02 14:23 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-01-29 11:12 [Qemu-devel] [PATCH v4] Add optionrom compatible with fw_cfg DMA version Marc Marí
2016-01-29 15:25 ` Stefan Hajnoczi
2016-02-02 11:06 ` Gerd Hoffmann
2016-02-02 12:04 ` Gerd Hoffmann
2016-02-02 13:07 ` Marc Marí
2016-02-02 14:23 ` Gerd Hoffmann [this message]
2016-02-02 15:04 ` Laszlo Ersek
2016-02-03 8:44 ` Gerd Hoffmann
2016-02-03 11:48 ` Laszlo Ersek
2016-02-03 12:57 ` Gerd Hoffmann
2016-02-02 12:58 ` Marc Marí
2016-02-03 9:47 ` Stefan Hajnoczi
2016-02-22 11:56 ` Vladimir Sementsov-Ogievskiy
2016-02-23 9:51 ` Stefan Hajnoczi
2016-03-21 11:14 ` Richard W.M. Jones
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=1454423012.9300.99.camel@redhat.com \
--to=kraxel@redhat.com \
--cc=kevin@koconnor.net \
--cc=lersek@redhat.com \
--cc=marc.mari.barcelo@gmail.com \
--cc=markmb@redhat.com \
--cc=pbonzini@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=somlo@cmu.edu \
--cc=stefanha@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).