Re: Question on guest enable msi fail when using GICv4/4.1

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Fri, 07 May 2021 06:57:04 +0100,
Shaokun Zhang <zhangshaokun@xxxxxxxxxxxxx> wrote:
> 
> [This letter comes from Nianyao Tang]
> 
> Hi,
> 
> Using GICv4/4.1 and msi capability, guest vf driver requires 3
> vectors and enable msi, will lead to guest stuck.

Stuck how?

> Qemu gets number of interrupts from Multiple Message Capable field
> set by guest. This field is aligned to a power of 2(if a function
> requires 3 vectors, it initializes it to 2).

So I guess this is a MultiMSI device with 4 vectors, right?

> However, guest driver just sends 3 mapi-cmd to vits and 3 ite
> entries is recorded in host.  Vfio initializes msi interrupts using
> the number of interrupts 4 provide by qemu.  When it comes to the
> 4th msi without ite in vits, in irq_bypass_register_producer,
> producer and consumer will __connect fail, due to find_ite fail, and
> do not resume guest.

Let me rephrase this to check that I understand it:
- The device has 4 vectors
- The guest only create mappings for 3 of them
- VFIO calls kvm_vgic_v4_set_forwarding() for each vector
- KVM doesn't have a mapping for the 4th vector and returns an error
- VFIO disable this 4th vector

Is that correct? If yes, I don't understand why that impacts the guest
at all. From what I can see, vfio_msi_set_vector_signal() just prints
a message on the console and carries on.

> Do we support this case, Guest function using msi interrupts number
> not aligned to a power of 2?  Or qemu should provide correct msi
> interrupts number?

QEMU cannot know how many vectors are in use, and the guest is free to
issue mappings for the exact number of vectors it wants to service.

Please describe what breaks the guest here.

Thanks,

	M.

-- 
Without deviation from the norm, progress is not possible.



[Index of Archives]     [DMA Engine]     [Linux Coverity]     [Linux USB]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Greybus]

  Powered by Linux