Re: [Qemu-devel] [Qemu-ppc] [PATCH] target-ppc: ppc64 target's virtio can be either endian.

[Alexander Graf]

On 09.12.2013, at 20:44, Benjamin Herrenschmidt <address@hidden> wrote:

> On Mon, 2013-12-09 at 16:33 +0100, Alexander Graf wrote:
>> 
>> Also can't virtio_get_byteswap pass in the CPU pointer of the CPU
>> that's calling in this moment? I'm not sure how racy it is to
>> synchronize the first cpu while we're not in the first cpu's execution
>> thread.
> 
> The LPCR bit is always set on all CPUs.

Yes and no. In HV KVM, yes. With sPAPR, yes. If we want to emulate a host 
machine, LPCR is a per-core register and may be different.

But that's not the point. The point is that I don't think it's good practice to 
call cpu_synchronize_state() of a foreign cpu, since it gives me headaches to 
imagine in what twisted race conditions things could go wrong there.

What happens when the first cpu is executing code while we call the synchronize 
call? It should lock in vcpu_load(), but that means we're not stuck. So we may 
have a secondary cpu that waits for the first cpu to exit. But why would it 
exit at all? It doesn't have to. Maybe it waits inside of the guest to see the 
virtio probing complete first.

As I said, I don't even want to start imagining what can go wrong.

So instead, I'd prefer if we model it sPAPR'ish: Treat VM-wide hypercalls as 
such. Handle it in QEMU, save the "LE" state in some machine state and query it 
from there. Then we're all safe.


Alex