Prev: [patch] change fs_struct.lock from rwlock to spinlock
Next: block/io bits for 2.6.35-rc
From: Jesse Barnes on 10 Jun 2010 11:40
On Thu, 10 Jun 2010 18:22:52 +0300
"Michael S. Tsirkin" <mst(a)redhat.com> wrote:

> virtio-pci resets the device at startup by writing to the status
> register, but this does not clear the pci config space,
> specifically msi enable status which affects register
> layout.
>
> This breaks things like kdump when they try to use e.g. virtio-blk.
>
> Fix by forcing msi off at startup. Since pci.c already has
> a routine to do this, we export and use it instead of duplicating code.
>
> Signed-off-by: Michael S. Tsirkin <mst(a)redhat.com>
> Tested-by: Vivek Goyal <vgoyal(a)redhat.com>
> Cc: Jesse Barnes <jbarnes(a)virtuousgeek.org>
> Cc: linux-pci(a)vger.kernel.org
> ---

Yeah, looks fine.

Acked-by: Jesse Barnes <jbarnes(a)virtuousgeek.org>

--
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 10:10
On Wed, Jun 23, 2010 at 04:59:11PM +0300, Avi Kivity wrote:
> On 06/10/2010 06:22 PM, Michael S. Tsirkin wrote:
>> virtio-pci resets the device at startup by writing to the status
>> register, but this does not clear the pci config space,
>> specifically msi enable status which affects register
>> layout.
>>
>> This breaks things like kdump when they try to use e.g. virtio-blk.
>>
>> Fix by forcing msi off at startup. Since pci.c already has
>> a routine to do this, we export and use it instead of duplicating code.
>>
>>
>
> Why doesn't a device reset result in msi being cleared?

This is not a standard function reset. This is virtio specific
command. So it only clears virtio registers.

> Shouldn't a reset be equivalent to power cycling?

If we did this, driver would need to restore registers
such as BAR etc.

> --
> 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 10:10
On 06/10/2010 06:22 PM, Michael S. Tsirkin wrote:
> virtio-pci resets the device at startup by writing to the status
> register, but this does not clear the pci config space,
> specifically msi enable status which affects register
> layout.
>
> This breaks things like kdump when they try to use e.g. virtio-blk.
>
> Fix by forcing msi off at startup. Since pci.c already has
> a routine to do this, we export and use it instead of duplicating code.
>
>

Why doesn't a device reset result in msi being cleared?

Shouldn't a reset be equivalent to power cycling?

--
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 10:30
On 06/23/2010 04:59 PM, Michael S. Tsirkin wrote:
>
>> Why doesn't a device reset result in msi being cleared?
>>
> This is not a standard function reset. This is virtio specific
> command. So it only clears virtio registers.
>

I see. We should implement FLR in qemu. If we don't already do so, we
should probably FLR anything that moves when a kexec kernel starts.

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

--
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 10:50
On Wed, Jun 23, 2010 at 05:21:37PM +0300, Avi Kivity wrote:
> On 06/23/2010 04:59 PM, Michael S. Tsirkin wrote:
>>
>>> Why doesn't a device reset result in msi being cleared?
>>>
>> This is not a standard function reset. This is virtio specific
>> command. So it only clears virtio registers.
>>
>
> I see. We should implement FLR in qemu.

We can do this. Or PM reset. however ...

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

>>> 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. It's also too late
now: changing behaviour will break old drivers.

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