virtio-pci: disable msi at startup
in [Kernel]
|
From: Avi Kivity on 23 Jun 2010 11:20 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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Michael S. Tsirkin on 23 Jun 2010 11:40 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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Avi Kivity on 23 Jun 2010 11:40 On 06/23/2010 06:26 PM, Michael S. Tsirkin wrote: > > >>> >>> >>>>>> 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. > The kdump kernel may not load drivers for those extra devices. >> 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. > Well, you only need to save/restore for the devices you use. The rest you reset and forget. I don't really see why copying some config space is crazy. >>> 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. > > What's PA write? -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Jesse Barnes on 23 Jun 2010 12:00 On Wed, 23 Jun 2010 18:35:55 +0300 Avi Kivity <avi(a)redhat.com> wrote: > On 06/23/2010 06:26 PM, Michael S. Tsirkin wrote: > > > > > >>> > >>> > >>>>>> 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. > > > > The kdump kernel may not load drivers for those extra devices. FLR or another type of reset also has the nice property of bringing the device into a known state. kexec/kdump has always been vulnerable to having devices in partial states when the new kernel loads; would be good to make it more robust. > > >> 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. > > > > Well, you only need to save/restore for the devices you use. The rest > you reset and forget. > > I don't really see why copying some config space is crazy. We could push any needed save/restore of core settings and regs into the PCI core like we do for PM. That would save a bunch of driver trouble... -- Jesse Barnes, Intel Open Source Technology Center -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Michael S. Tsirkin on 23 Jun 2010 12:00 On Wed, Jun 23, 2010 at 06:35:55PM +0300, Avi Kivity wrote: > On 06/23/2010 06:26 PM, Michael S. Tsirkin wrote: >> >> >>>> >>>> >>>>>>> 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. >> > > The kdump kernel may not load drivers for those extra devices. Then we don't care about clearing them? >>> 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. >> > > Well, you only need to save/restore for the devices you use. The rest > you reset and forget. > > I don't really see why copying some config space is crazy. Maybe not crazy, but complex. Look at pci_restore_state. Anyway, if kdump wants to do this, it's a question of calling pci_reset_function. >>>> 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. >> >> > > What's PA write? thats how we reset virtio today: write 0 to PA register. > -- > error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
First
|
Prev
|
Next
|
Last
Pages: 1 2 3 Prev: [patch] change fs_struct.lock from rwlock to spinlock Next: block/io bits for 2.6.35-rc |