Re: [PATCH] selftests: KVM: Handle compiler optimizations in ucall

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 6/17/22 09:28, Andrew Jones wrote:
On Thu, Jun 16, 2022 at 09:54:16PM +0000, David Laight wrote:
From: oliver.upton@xxxxxxxxx
Sent: 16 June 2022 19:45


June 16, 2022 11:48 AM, "David Laight" <David.Laight@xxxxxxxxxx> wrote:
No wonder I was confused.
It's not surprising the compiler optimises it all away.

It doesn't seem right to be 'abusing' WRITE_ONCE() here.
Just adding barrier() should be enough and much more descriptive.

I had the same thought, although I do not believe barrier() is sufficient
on its own. barrier_data() with a pointer to uc passed through
is required to keep clang from eliminating the dead store.

A barrier() (full memory clobber) ought to be stronger than
the partial one than barrier_data() generates.

I can't quite decide whether you need a barrier() both sides
of the 'magic write'.
Plausibly the compiler could discard the on-stack data
after the barrier() and before the 'magic write'.

Certainly putting the 'magic write' inside a asm block
that has a memory clobber is a more correct solution.

Indeed, since the magic write is actually a guest MMIO write, then
it should be using writeq().

It doesn't need to use writeq() because no special precautions are needed with respect to cacheability or instruction reordering (as is the case with hardware registers).

WRITE_ONCE is okay, especially since the code never reads it (and if it did it would also use READ_ONCE).

Paolo





[Index of Archives]     [KVM ARM]     [KVM ia64]     [KVM ppc]     [Virtualization Tools]     [Spice Development]     [Libvirt]     [Libvirt Users]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite Questions]     [Linux Kernel]     [Linux SCSI]     [XFree86]

  Powered by Linux