On Thu, Jun 16, 2022 at 2:24 AM Cristian Marussi
[off-list ref] wrote:

On Wed, Jun 15, 2022 at 09:41:18AM +0800, Jason Wang wrote:

quoted

On Wed, Jun 15, 2022 at 12:46 AM Cristian Marussi
[off-list ref] wrote:

Hi Jason,

quoted

quoted

On Tue, Jun 14, 2022 at 03:40:21PM +0800, Jason Wang wrote:

quoted

On Mon, Jun 13, 2022 at 5:28 PM Michael S. Tsirkin [off-list ref] wrote:

quoted

[snip]

quoted

quoted

quoted

quoted

 arm_scmi

It looks to me the singleton device could be used by SCMI immediately after

        /* Ensure initialized scmi_vdev is visible */
        smp_store_mb(scmi_vdev, vdev);

So we probably need to do virtio_device_ready() before that. It has an
optional rx queue but the filling is done after the above assignment,
so it's safe. And the callback looks safe is a callback is triggered
after virtio_device_ready() buy before the above assignment.

I wanted to give it a go at this series testing it on the context of
SCMI but it does not apply

- not on a v5.18:

17:33 $ git rebase -i v5.18
17:33 $ git am ./v6_20220527_jasowang_rework_on_the_irq_hardening_of_virtio.mbx
Applying: virtio: use virtio_device_ready() in virtio_device_restore()
Applying: virtio: use virtio_reset_device() when possible
Applying: virtio: introduce config op to synchronize vring callbacks
Applying: virtio-pci: implement synchronize_cbs()
Applying: virtio-mmio: implement synchronize_cbs()
error: patch failed: drivers/virtio/virtio_mmio.c:345
error: drivers/virtio/virtio_mmio.c: patch does not apply
Patch failed at 0005 virtio-mmio: implement synchronize_cbs()

- neither on a v5.19-rc2:

17:33 $ git rebase -i v5.19-rc2
17:35 $ git am ./v6_20220527_jasowang_rework_on_the_irq_hardening_of_virtio.mbx
Applying: virtio: use virtio_device_ready() in virtio_device_restore()
error: patch failed: drivers/virtio/virtio.c:526
error: drivers/virtio/virtio.c: patch does not apply
Patch failed at 0001 virtio: use virtio_device_ready() in
virtio_device_restore()
hint: Use 'git am --show-current-patch=diff' to see the failed patch
When you have resolved this problem, run "git am --continue".

... what I should take as base ?

It should have already been included in rc2, so there's no need to
apply patch manually.

I tested this series as included in v5.19-rc2 (WITHOUT adding a virtio_device_ready
in SCMI virtio as you mentioned above ... if I got it right) and I have NOT seen any
issue around SCMI virtio using my usual test setup (using both SCMI vqueues).

No anomalies even when using SCMI virtio in atomic/polling mode.

Adding a virtio_device_ready() at the end of the SCMI virtio probe()
works fine either, it does not make any difference in my setup.
(both using QEMU and kvmtool with this latter NOT supporting
 virtio_V1...not sure if it makes a difference but I thought was worth
 mentioning)

Thanks a lot for the testing.

We want to prevent malicious hypervisors from attacking us. So more questions:

Assuming we do:

virtio_device_ready();
/* Ensure initialized scmi_vdev is visible */
smp_store_mb(scmi_vdev, vdev);

This means we allow the callbacks (scmi_vio_complete) to be called
before smp_store_mb(). We need to make sure the callbacks are robust.
And this looks fine since we have the check of
scmi_vio_channel_acquire() and if the notification is called before
smp_store_mb(), the acquire will fail.

If we put virtio_device_ready() after smp_store_mb() like:

/* Ensure initialized scmi_vdev is visible */
smp_store_mb(scmi_vdev, vdev);
virtio_device_ready();

If I understand correctly, there will be a race since the SCMI may try
to use the device before virtio_device_ready(), this violates the
virtio spec somehow.

Thanks

Thanks,
Cristian