Re: [PATCH v3 09/13] KVM: xen: automatically use the vcpu_info embedded in shared_info

[David Woodhouse <dwmw2@infradead.org>]

[-- Attachment #1: Type: text/plain, Size: 2041 bytes --]

On Mon, 2023-09-18 at 17:15 +0100, Paul Durrant wrote:
> > > +  Note that, if the guest sets an explicit vcpu_info location in guest
> > > +  memory then the VMM is expected to copy the content of the structure
> > > +  embedded in the shared_info page to the new location. It is therefore
> > > +  important that no event delivery is in progress at this time, otherwise
> > > +  events may be missed.
> > > 
> > 
> > That's difficult. It means tearing down all interrupts from passthrough
> > devices which are mapped via PIRQs, and also all IPIs.
> 
> So those don't honour event channel masking? That seems like a problem.

Oh, *mask*. Sure, it does honour masking. But... that would mean the
VMM has to keep track of which ports were *really* masked by the guest,
and which ones were just masked for the switchover. Including if the
guest does some mask/unmask activity *while* the switchover is
happening (or locking to prevent such). I still don't think that's a
kind thing to be telling the VMMs they need to do.

> > 
> > The IPI code *should* be able to fall back to just letting the VMM
> > handle the hypercall in userspace. But PIRQs are harder. I'd be happier
> > if our plan — handwavy though it may be — led to being able to use the
> > existing slow path for delivering interrupts by just *invalidating* the
> > cache. Maybe we *should* move the memcpy into the kernel, and let it
> > lock *both* the shinfo and new vcpu_info caches while it's doing the
> > copy? Given that that's the only valid transition, that shouldn't be so
> > hard, should it?
> > 
> 
> No, it just kind of oversteps the remit of the attribute... but I'll try 
> adding it and see how messy it gets.

Well, there's a reason I left all the vcpu_info address magic in
userspace in the first place. It was there in João's original patches
and I ripped it all out.

But I see your logic for wanting to put it back; I suspect moving the
memcpy too is part of the cost of that? Should work out OK, I think.

[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 5965 bytes --]