On Tue, Jul 09, 2019 at 07:34:26PM +0800, Wei Wang wrote: > > But what about the counter scheduling rules; > > The counter is emulated independent of the lbr emulation. > > what happens when a CPU > > event claims the LBR before the task event can claim it? CPU events have > > precedence over task events. > > I think the precedence (cpu pined and task pined) is for the counter > multiplexing, > right? No; for all scheduling. The order is: CPU-pinned Task-pinned CPU-flexible Task-flexible The way you created the event it would land in 'task-flexible', but even if you make it task-pinned, a CPU (or CPU-pinned) event could claim the LBR before your fake event. > For the lbr feature, could we thought of it as first come, first served? > For example, if we have 2 host threads who want to use lbr at the same time, > I think one of them would simply fail to use. > > So if guest first gets the lbr, host wouldn't take over unless some > userspace command (we added to QEMU) is executed to have the vCPU > actively stop using lbr. Doesn't work that way. Say you start KVM with LBR emulation, it creates this task event, it gets the LBR (nobody else wants it) and the guest works and starts using the LBR. Then the host creates a CPU LBR event and the vCPU suddenly gets denied the LBR and the guest no longer functions correctly. Or you should fail to VMENTER, in which case you starve the guest, but at least it doesn't malfunction.
