On Wed, 2024-07-03 at 16:01 +0000, Sandesh Patel wrote:
> >
> > Interesting. What exactly has Windows *done* in those MSI entries?
> > That
> > might give a clue about how to support it.
>
> The KVM_SET_GSI_ROUTING ioctl calls kvm_set_routing_entry function in
> kvm.
>
> int kvm_set_routing_entry(struct kvm *kvm, struct
> kvm_kernel_irq_routing_entry *e,
> const struct kvm_irq_routing_entry *ue)
> {
>
> switch (ue->type) {
> case KVM_IRQ_ROUTING_MSI:
> e->set = kvm_set_msi;
> e->msi.address_lo = ue->u.msi.address_lo;
> e->msi.address_hi = ue->u.msi.address_hi;
> e->msi.data = ue->u.msi.data;
>
> if (kvm_msi_route_invalid(kvm, e))
> return -EINVAL;
> break;
> }
> }
>
> static inline bool kvm_msi_route_invalid(struct kvm *kvm,
> struct kvm_kernel_irq_routing_entry *e)
> {
> return kvm->arch.x2apic_format && (e->msi.address_hi & 0xff);
> }
>
> That means msi.address_hi must have 0 in the last byte.
>
> Qemu function kvm_arch_fixup_msi_route is responsible for
> fixing msi.address_hi value in
> msi routing entry that is passed to kvm.
> This function got msi.addr_hi: 0x0 in input when iommu was enabled
> and msi.addr_hi: 0x1
> when viommu was not enabled for one of the entry. The same value was
> returned in the output.
> and saved as routing entry.That's after QEMU has translated it though. Precisely which MSI is this, belonging to which device, and what exactly did Windows write to the MSI table? If *Windows* put anything into the high address bits, that isn't even targeted at the APIC, and it would be an attempt at writing to actual memory. I suspect that isn't the case. Can you make kvm_arch_fixup_msi_route() print the actual address and data directly from the guest?
smime.p7s
Description: S/MIME cryptographic signature
