OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

virtio-comment message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Re: [virtio-comment] [PATCH V2 2/2] virtio: introduce STOP status bit

å 2021/7/20 äå6:31, Cornelia Huck åé:
On Fri, Jul 16 2021, Jason Wang <jasowang@redhat.com> wrote:

å 2021/7/15 äå5:16, Stefan Hajnoczi åé:
devices sequentially increases migration downtime, so I think the
interface should encourage concurrently stopping multiple devices.

I think you and Cornelia discussed that an interrupt could be added to
solve this problem. That would address my concerns about the STOP bit.

The problems are:

1) if we generate an interrupt after STOP, it breaks the STOP semantic
where the device should not generate any interrupt
2) if we generate an interrupt before STOP, we may end up with race
I think not all interrupts are created equal here.

For virtqueue notification interrupts, I agree. If the device is being
stopped, no notification interrupts will be generated.

For device interrupts in the general sense, banning these would make it
impossible to implement STOP for CCW, as any channel program (be it
RESET, READ_STATUS, or any new one) is required to generate a status
pending/interrupt when it is finished.

So they are working at different levels. STOP is at the virtio level not the transport level.

For STOP, it means the device stop working at virtio level, it doesn't mean the device doesn't work at transport level. It means CCW can still have its interrupt if it's not generated from the virtiqueue or config.

So did RESET: I believe for both CCW and PCI, and virtio RESET doesn't meant a transport level reset.

I also don't see how that would
create a race condition for CCW.

Why can't we simply have an interrupt indicating completion of the STOP
request, and no further interrupts after that?

So I think we had some discussion on this. I think STOP should work as RESET.

And if we want an indication of STOP, why don't we need it for RESET?


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]