On Tue, 2023-10-24 at 13:16 +0100, Paul Durrant wrote:
> On 16/10/2023 16:18, David Woodhouse wrote:
> > From: David Woodhouse <d...@amazon.co.uk>
> >
> > The per-vCPU upcall vector support had two problems. Firstly it was
> > using the wrong hypercall argument and would always return -EFAULT.
> > And secondly it was using the wrong ioctl() to pass the vector to
> > the kernel and thus the *kernel* would always return -EINVAL.
> >
> > Linux doesn't (yet) use this mode so it went without decent testing
> > for a while.
> >
> > Fixes: 105b47fdf2d0 ("i386/xen: implement
> > HVMOP_set_evtchn_upcall_vector")
> > Signed-off-by: David Woodhouse <d...@amazon.co.uk>
> > ---
> > target/i386/kvm/xen-emu.c | 5 ++---
> > 1 file changed, 2 insertions(+), 3 deletions(-)
>
> Reviewed-by: Paul Durrant <p...@xen.org>
FWIW this patch gained a third "brown paper bag" fix this morning, when
I finally worked it out:
@@ -440,7 +440,8 @@ void kvm_xen_inject_vcpu_callback_vector(uint32_t
vcpu_id, int type)
* deliver it as an MSI.
*/
MSIMessage msg = {
- .address = APIC_DEFAULT_ADDRESS | X86_CPU(cs)->apic_id,
+ .address = APIC_DEFAULT_ADDRESS |
+ (X86_CPU(cs)->apic_id << MSI_ADDR_DEST_ID_SHIFT),
.data = vector | (1UL << MSI_DATA_LEVEL_SHIFT),
};
kvm_irqchip_send_msi(kvm_state, msg);
smime.p7s
Description: S/MIME cryptographic signature
