Re: [PATCH v3 09/13] KVM: xen: automatically use the vcpu_info embedded in shared_info
From: David Woodhouse
Date: Mon Sep 18 2023 - 12:28:49 EST
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:
smime.p7s
Description: S/MIME cryptographic signature