On 09.12.2013, at 20:44, Benjamin Herrenschmidt <b...@kernel.crashing.org> 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