On Mon, 2023-09-18 at 14:26 +0100, Paul Durrant wrote: > On 18/09/2023 14:21, David Woodhouse wrote: > > On Mon, 2023-09-18 at 11:21 +0000, Paul Durrant wrote: > > > From: Paul Durrant <pdurrant@xxxxxxxxxx> > > > > > > If the vCPU id is set and the shared_info is mapped using HVA then we can > > > infer that KVM has the ability to use a default vcpu_info mapping. Hence > > > we can stop setting the address of the vcpu_info structure. > > > > Again that means we're not *testing* it any more when the test is run > > on newer kernels. Can we perhaps set it explicitly, after *half* the > > tests are done? Maybe to a *different* address than the default which > > is derived from the Xen vcpu_id? And check that the memcpy works right > > when we do? > > > > Ok. The VMM is currently responsible for that memcpy. Are you suggesting > we push that into KVM too? Ah OK. Hm, maybe we should? What happened before in the case where interrupts were being delivered, and the vcpu_info address was changed. In Xen, I guess it's effectively atomic? Some locking will mean that the event channel is delivered to the vcpu_info either *before* the memcpy, or *after* it, but never to the old address after the copy has been done, so that the event (well the index of it) gets lost? In KVM before we did the automatic placement, it was the VMM's problem. If there are any interrupts set up for direct delivery, I suppose the VMM should have *removed* the vcpu_info mapping before doing the memcpy, then restored it at the new address? I may have to check qemu gets that right. Then again, it's a very hard race to trigger, given that a guest can only set the vcpu_info once. So it can move it from the shinfo to a separate address and attempt to trigger this race just that one time. But in the case where auto-placement has happened, and then the guest sets an explicit vcpu_info location... are we saying that the VMM must explicitly *unmap* the vcpu_info first, then memcpy, then set it to the new location? Or will we handle the memcpy in-kernel?
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
