On Thu, Jun 16, 2022 at 2:24 AM Cristian Marussi <cristian.marussi@xxxxxxx> wrote: > > On Wed, Jun 15, 2022 at 09:41:18AM +0800, Jason Wang wrote: > > On Wed, Jun 15, 2022 at 12:46 AM Cristian Marussi > > <cristian.marussi@xxxxxxx> wrote: > > Hi Jason, > > > > > > > On Tue, Jun 14, 2022 at 03:40:21PM +0800, Jason Wang wrote: > > > > On Mon, Jun 13, 2022 at 5:28 PM Michael S. Tsirkin <mst@xxxxxxxxxx> wrote: > > > > > > > > > > [snip] > > > > > > > > > > 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 > _______________________________________________ Virtualization mailing list Virtualization@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linuxfoundation.org/mailman/listinfo/virtualization
