public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Avi Kivity <avi@redhat.com>
To: "Michael S. Tsirkin" <mst@redhat.com>
Cc: virtualization@lists.linux-foundation.org,
	Anthony Liguori <aliguori@us.ibm.com>,
	linux-pci@vger.kernel.org, Matt Carlson <mcarlson@broadcom.com>,
	linux-kernel@vger.kernel.org,
	Jesse Barnes <jbarnes@virtuousgeek.org>,
	"Rafael J. Wysocki" <rjw@sisk.pl>,
	Kenji Kaneshige <kaneshige.kenji@jp.fujitsu.com>,
	Tejun Heo <tj@kernel.org>,
	"David S. Miller" <davem@davemloft.net>,
	Bjorn Helgaas <bjorn.helgaas@hp.com>
Subject: Re: [PATCH for-2.6.35] virtio-pci: disable msi at startup
Date: Wed, 23 Jun 2010 18:15:20 +0300	[thread overview]
Message-ID: <4C222508.2060804@redhat.com> (raw)
In-Reply-To: <20100623144307.GB30526@redhat.com>

On 06/23/2010 05:43 PM, Michael S. Tsirkin wrote:
>
>
>>   If we don't already do so, we
>> should probably FLR anything that moves when a kexec kernel starts.
>>      
> Probably only whatever we want to use. But whether this will make it
> more, or less robust, is an open question.
>    

I'm thinking of a sound card left on (maybe not something you have in 
kdump scenarios) or an industrial controller.  Those cards have side 
effects and you want to quiesce them even if you don't know what they are.

>    
>>>> Shouldn't a reset be equivalent to power cycling?
>>>>
>>>>          
>>> If we did this, driver would need to restore registers
>>> such as BAR etc.
>>>
>>>        
>> We could save/restore the registers we care about.
>>      
> It seems easier to clear registers we care about.

We know the registers we care about, we don't know the ones we don't.  
I'm talking about FLRing all cards, not just those you want to use.

>    It's also too late
> now: changing behaviour will break old drivers.
>    

Why?  the FLR is triggered by the guest kernel, so all drivers will be 
aware it was FLRed.

-- 
error compiling committee.c: too many arguments to function


  reply	other threads:[~2010-06-23 15:17 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-06-10 15:22 [PATCH for-2.6.35] virtio-pci: disable msi at startup Michael S. Tsirkin
2010-06-10 15:34 ` Jesse Barnes
2010-06-23 13:59 ` Avi Kivity
2010-06-23 13:59   ` Michael S. Tsirkin
2010-06-23 14:21     ` Avi Kivity
2010-06-23 14:43       ` Michael S. Tsirkin
2010-06-23 15:15         ` Avi Kivity [this message]
2010-06-23 15:26           ` Michael S. Tsirkin
2010-06-23 15:35             ` Avi Kivity
2010-06-23 15:43               ` Michael S. Tsirkin
2010-06-23 15:53                 ` Avi Kivity
2010-06-23 15:51               ` Jesse Barnes

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=4C222508.2060804@redhat.com \
    --to=avi@redhat.com \
    --cc=aliguori@us.ibm.com \
    --cc=bjorn.helgaas@hp.com \
    --cc=davem@davemloft.net \
    --cc=jbarnes@virtuousgeek.org \
    --cc=kaneshige.kenji@jp.fujitsu.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=mcarlson@broadcom.com \
    --cc=mst@redhat.com \
    --cc=rjw@sisk.pl \
    --cc=tj@kernel.org \
    --cc=virtualization@lists.linux-foundation.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