* virtio config access races
@ 2012-07-12 22:59 Michael S. Tsirkin
2012-07-13 3:55 ` Rusty Russell
2012-07-13 3:55 ` Rusty Russell
0 siblings, 2 replies; 3+ messages in thread
From: Michael S. Tsirkin @ 2012-07-12 22:59 UTC (permalink / raw)
To: Rusty Russell; +Cc: kvm, virtualization
It looks like there's a problem in the way virtio config currently
works: if driver reads config in probe routine, config
subsequently can change before core sets DRIVER_OK.
This will not cause an interrupt and so this event is lost.
Maybe we should document that devices should delay such
events until after DRIVER_OK?
--
MST
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: virtio config access races
2012-07-12 22:59 virtio config access races Michael S. Tsirkin
@ 2012-07-13 3:55 ` Rusty Russell
2012-07-13 3:55 ` Rusty Russell
1 sibling, 0 replies; 3+ messages in thread
From: Rusty Russell @ 2012-07-13 3:55 UTC (permalink / raw)
To: Michael S. Tsirkin; +Cc: kvm, virtualization
On Fri, 13 Jul 2012 01:59:41 +0300, "Michael S. Tsirkin" <mst@redhat.com> wrote:
> It looks like there's a problem in the way virtio config currently
> works: if driver reads config in probe routine, config
> subsequently can change before core sets DRIVER_OK.
> This will not cause an interrupt and so this event is lost.
> Maybe we should document that devices should delay such
> events until after DRIVER_OK?
The device is currently defined to be active from the time we
acknowledge the features (which means we may get a spurious interrupt
before we probe, I think). We abuse this for virtio_blk for example,
where we add_disk() inside the probe function.
Hmm, the changed interrupt is live from find_vqs, right? Perhaps we
should leave it to drivers to set that up in the right order.
Thoughts?
Rusty.
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: virtio config access races
2012-07-12 22:59 virtio config access races Michael S. Tsirkin
2012-07-13 3:55 ` Rusty Russell
@ 2012-07-13 3:55 ` Rusty Russell
1 sibling, 0 replies; 3+ messages in thread
From: Rusty Russell @ 2012-07-13 3:55 UTC (permalink / raw)
To: Michael S. Tsirkin; +Cc: virtualization, kvm
On Fri, 13 Jul 2012 01:59:41 +0300, "Michael S. Tsirkin" <mst@redhat.com> wrote:
> It looks like there's a problem in the way virtio config currently
> works: if driver reads config in probe routine, config
> subsequently can change before core sets DRIVER_OK.
> This will not cause an interrupt and so this event is lost.
> Maybe we should document that devices should delay such
> events until after DRIVER_OK?
The device is currently defined to be active from the time we
acknowledge the features (which means we may get a spurious interrupt
before we probe, I think). We abuse this for virtio_blk for example,
where we add_disk() inside the probe function.
Hmm, the changed interrupt is live from find_vqs, right? Perhaps we
should leave it to drivers to set that up in the right order.
Thoughts?
Rusty.
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2012-07-13 4:18 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2012-07-12 22:59 virtio config access races Michael S. Tsirkin
2012-07-13 3:55 ` Rusty Russell
2012-07-13 3:55 ` Rusty Russell
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.