[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Z8cNBTgz3YBDga3c@google.com>
Date: Tue, 4 Mar 2025 06:24:05 -0800
From: Sean Christopherson <seanjc@...gle.com>
To: Vitaly Kuznetsov <vkuznets@...hat.com>
Cc: kvm@...r.kernel.org, linux-kernel@...r.kernel.org,
Paolo Bonzini <pbonzini@...hat.com>, Peter Xu <peterx@...hat.com>,
"Maciej S. Szmigiero" <maciej.szmigiero@...cle.com>
Subject: Re: QEMU's Hyper-V HV_X64_MSR_EOM is broken with split IRQCHIP
On Tue, Mar 04, 2025, Vitaly Kuznetsov wrote:
> Sean Christopherson <seanjc@...gle.com> writes:
>
> > FYI, QEMU's Hyper-V emulation of HV_X64_MSR_EOM has been broken since QEMU commit
> > c82d9d43ed ("KVM: Kick resamplefd for split kernel irqchip"), as nothing in KVM
> > will forward the EOM notification to userspace. I have no idea if anything in
> > QEMU besides hyperv_testdev.c cares.
>
> The only VMBus device in QEMU besides the testdev seems to be Hyper-V
> ballooning driver, Cc: Maciej to check whether it's a real problem for
> it or not.
>
> >
> > The bug is reproducible by running the hyperv_connections KVM-Unit-Test with a
> > split IRQCHIP.
>
> Thanks, I can reproduce the problem too.
>
> >
> > Hacking QEMU and KVM (see KVM commit 654f1f13ea56 ("kvm: Check irqchip mode before
> > assign irqfd") as below gets the test to pass. Assuming that's not a palatable
> > solution, the other options I can think of would be for QEMU to intercept
> > HV_X64_MSR_EOM when using a split IRQCHIP, or to modify KVM to do KVM_EXIT_HYPERV_SYNIC
> > on writes to HV_X64_MSR_EOM with a split IRQCHIP.
>
> AFAIR, Hyper-V message interface is a fairly generic communication
> mechanism which in theory can be used without interrupts at all: the
> corresponding SINT can be masked and the guest can be polling for
> messages, proccessing them and then writing to HV_X64_MSR_EOM to trigger
> delivery on the next queued message. To support this scenario on the
> backend, we need to receive HV_X64_MSR_EOM writes regardless of whether
> irqchip is split or not. (In theory, we can get away without this by
> just checking if pending messages can be delivered upon each vCPU entry
> but this can take an undefined amount of time in some scenarios so I
> guess we're better off with notifications).
Before c82d9d43ed ("KVM: Kick resamplefd for split kernel irqchip"), and without
a split IRCHIP, QEMU gets notified via eventfd. On writes to HV_X64_MSR_EOM, KVM
invokes irq_acked(), i.e. irqfd_resampler_ack(), for all SINT routes. The eventfd
signal gets back to sint_ack_handler(), which invokes msg_retry() to re-post the
message.
I.e. trapping HV_X64_MSR_EOM on would be a slow path relative to what's there for
in-kernel IRQCHIP.
Powered by blists - more mailing lists