(There are two net fixes which depend on this which will go via DaveM, so
please pull soon).
The following changes since commit 7e27d6e778cd87b6f2415515d7127eba53fe5d02:
Linus Torvalds (1):
Linux 2.6.35-rc3
are available in the git repository at:
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.
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.
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
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
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
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,
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
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
On Wed, 23 Jun 2010 18:35:55 +0300
Avi Kivity 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.
On 06/23/2010 06:43 PM, Michael S. Tsirkin wrote:
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?
We do, if the device has a side
On 06/23/2010 04:24 PM, Stefan Hajnoczi wrote:
The virtio block device holds a lock during I/O request processing.
Kicking the virtqueue while the lock is held results in long lock hold
times and increases contention for the lock.
This patch modifies virtqueue_kick() to optionally release a
Using Rusty's suggestion I've respun the patch removing the special copy
function. I've tested this patch in a guest kernel with and without qemu
supplying serial numbers for the block devices and it's working as expected.
When qemu supplies serial numbers, the correct value is supplied to
With the availablility of a sysfs device attribute for examining disk serial
numbers the ioctl is no longer needed. The user-space changes for this aren't
upstream yet so we don't have any users to worry about.
Signed-off-by: Ryan Harper ry...@us.ibm.com
---
drivers/block/virtio_blk.c | 10
Create a new attribute for virtio-blk devices that will fetch the serial number
of the block device. This attribute can be used by udev to create disk/by-id
symlinks for devices that don't have a UUID (filesystem) associated with them.
ATA_IDENTIFY strings are special in that they can be up to
On Wed, Jun 23, 2010 at 11:12 PM, Anthony Liguori anth...@codemonkey.ws wrote:
Shouldn't it be possible to just drop the lock before invoking
virtqueue_kick() and reacquire it afterwards? There's nothing in that
virtqueue_kick() path that the lock is protecting AFAICT.
No, that would lead to
16 matches
Mail list logo
