|
From: | Cao jin |
Subject: | Re: [Qemu-devel] [PATCH v5 09/11] pci bridge dev: change msi property type |
Date: | Tue, 17 May 2016 15:39:14 +0800 |
User-agent: | Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 |
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 <address@hidden> cc: Markus Armbruster <address@hidden> cc: Marcel Apfelbaum <address@hidden> Signed-off-by: Cao jin <address@hidden> --- 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
[Prev in Thread] | Current Thread | [Next in Thread] |