All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Michael S. Tsirkin" <mst@redhat.com>
To: Avi Kivity <avi@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:26:33 +0300	[thread overview]
Message-ID: <20100623152633.GC30526@redhat.com> (raw)
In-Reply-To: <4C222508.2060804@redhat.com>

On Wed, Jun 23, 2010 at 06:15:20PM +0300, Avi Kivity wrote:
> 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.

clearing bus master should be enough for that.
we still run the risk of hanging the kernel if the
device is hung, though.

>>    
>>>>> 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.   

If/when we use more registers, we can update driver to clear them on start.

> I'm talking about FLRing all cards, not just those you want to use.

reset using FLR/PM is complex because of the need to save/restore
config space. Doing this on a crashing kernel sounds scary.

>>    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.

Not for FLR. Too late to reset on PA write.

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

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

Thread overview: 24+ 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-10 15:34 ` Jesse Barnes
2010-06-23 13:59 ` Avi Kivity
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:21       ` Avi Kivity
2010-06-23 14:43       ` Michael S. Tsirkin
2010-06-23 15:15         ` Avi Kivity
2010-06-23 15:26           ` Michael S. Tsirkin [this message]
2010-06-23 15:35             ` Avi Kivity
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:53                 ` Avi Kivity
2010-06-23 15:43               ` Michael S. Tsirkin
2010-06-23 15:51               ` Jesse Barnes
2010-06-23 15:51               ` Jesse Barnes
2010-06-23 15:26           ` Michael S. Tsirkin
2010-06-23 15:15         ` Avi Kivity
2010-06-23 14:43       ` Michael S. Tsirkin
2010-06-23 13:59   ` Michael S. Tsirkin
  -- strict thread matches above, loose matches on Subject: below --
2010-06-10 15:22 Michael S. Tsirkin

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=20100623152633.GC30526@redhat.com \
    --to=mst@redhat.com \
    --cc=aliguori@us.ibm.com \
    --cc=avi@redhat.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=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 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.