From: Cao jin <caoj.fnst@cn.fujitsu.com>
To: Marcel Apfelbaum <marcel@redhat.com>, qemu-devel@nongnu.org
Cc: "Michael S. Tsirkin" <mst@redhat.com>,
Markus Armbruster <armbru@redhat.com>
Subject: Re: [Qemu-devel] [PATCH v5 09/11] pci bridge dev: change msi property type
Date: Tue, 17 May 2016 15:39:14 +0800 [thread overview]
Message-ID: <573ACAA2.1040107@cn.fujitsu.com> (raw)
In-Reply-To: <573878E7.7070807@redhat.com>
On 05/15/2016 09:25 PM, Marcel Apfelbaum wrote:
> On 05/06/2016 07:20 AM, Cao jin wrote:
>> From bit to enum OnOffAuto.
>>
>> cc: Michael S. Tsirkin <mst@redhat.com>
>> cc: Markus Armbruster <armbru@redhat.com>
>> cc: Marcel Apfelbaum <marcel@redhat.com>
>> Signed-off-by: Cao jin <caoj.fnst@cn.fujitsu.com>
>> ---
>>
>> Actually, I am not quite sure this device need this change, RFC.
>>
>
> Well, it already has the 'msi' property, so we may want to make it
> standard 'OnOffAuto'.
> One problem I can see is the change of semantics. Until now msi=on means
> 'auto'. From now on
> it means 'force msi=on', fail otherwise. If I got this right, old
> machines having msi=on
> will failed to start on platforms with msibroken=true, right?
Exactly, and patch 11 indeed has semantics change. According to what we
discussed before: "if user want msi=on explicitly on command line, then
msi_init`s failure should result in failing to create device", this
semantics change seems can`t be avoid.
> Maybe we should preserve the semantics for old machines? (this patch
> does not actually
> affect the semantics, but patch 11/11 should, otherwise why change it to
> OnOffAuto, right? )
IMHO, in this case, keep compat maybe a burden on us, and make
command-line confusing. See my understanding:
before:
command line format is msi=on/off, and 'on' means auto
now:
we change command line to msi=on/off/auto, and keep compat is meaning
'on' still means auto? If so, why need 'auto'
So, I am thinking, maybe we can help old machine user update their
configuration, I mean: when they set msi=on on platforms with
msibroken=true, they definitely fail, so we should give a clear hint in
error message to help them know what should do to start the machine,
like "please use msi=auto and try again"
--
Yours Sincerely,
Cao jin
next prev parent reply other threads:[~2016-05-17 7:35 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-05-06 4:20 [Qemu-devel] [PATCH v5 00/11] Add param Error ** for msi_init() Cao jin
2016-05-06 4:20 ` [Qemu-devel] [PATCH v5 01/11] fix some coding style problems Cao jin
2016-05-15 12:36 ` Marcel Apfelbaum
2016-05-06 4:20 ` [Qemu-devel] [PATCH v5 02/11] change pvscsi_init_msi() type to void Cao jin
2016-05-06 5:48 ` Cao jin
2016-05-06 4:20 ` [Qemu-devel] [PATCH v5 03/11] megasas: Fix Cao jin
2016-05-06 5:43 ` Cao jin
2016-05-15 12:37 ` Marcel Apfelbaum
2016-05-06 4:20 ` [Qemu-devel] [PATCH v5 04/11] mptsas: change .realize function name Cao jin
2016-05-06 5:53 ` Cao jin
2016-05-06 4:20 ` [Qemu-devel] [PATCH v5 05/11] usb xhci: change msi/msix property type Cao jin
2016-05-06 4:20 ` [Qemu-devel] [PATCH v5 06/11] intel-hda: change msi " Cao jin
2016-05-06 4:20 ` [Qemu-devel] [PATCH v5 07/11] mptsas: " Cao jin
2016-05-06 4:20 ` [Qemu-devel] [PATCH v5 08/11] megasas: change msi/msix " Cao jin
2016-05-06 4:20 ` [Qemu-devel] [PATCH v5 09/11] pci bridge dev: change msi " Cao jin
2016-05-15 13:25 ` Marcel Apfelbaum
2016-05-17 7:39 ` Cao jin [this message]
2016-05-17 7:38 ` Michael S. Tsirkin
2016-05-23 2:22 ` Cao jin
2016-05-23 9:55 ` Marcel Apfelbaum
2016-05-06 4:20 ` [Qemu-devel] [PATCH v5 10/11] pci core: assert ENOSPC when add capability Cao jin
2016-05-15 13:10 ` Marcel Apfelbaum
2016-05-17 3:00 ` Cao jin
2016-05-06 4:20 ` [Qemu-devel] [PATCH v5 11/11] pci: Convert msi_init() to Error and fix callers to check it Cao jin
2016-05-15 13:41 ` Marcel Apfelbaum
2016-05-17 10:08 ` Cao jin
2016-05-23 10:06 ` Marcel Apfelbaum
2016-05-23 12:51 ` Cao jin
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=573ACAA2.1040107@cn.fujitsu.com \
--to=caoj.fnst@cn.fujitsu.com \
--cc=armbru@redhat.com \
--cc=marcel@redhat.com \
--cc=mst@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 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).