On Mon, Jul 06, 2015 at 12:23:19PM +0100, Andre Przywara wrote: > Hi Paolo, > > thanks for looking at this! > > On 06/07/15 12:07, Paolo Bonzini wrote: > > > > > > On 06/07/2015 12:37, Christoffer Dall wrote: > >> I don't view it as 'the kernel requires this' but as 'the kernel will > >> not complain with arbitrary error code if you set the devid flag' > >> capability, and it's up to userspace (as usual) to provide the correct > >> arguments for things to work, and up to the kernel to ensure we don't > >> crash the system etc. > >> > >> Thus, if you want to advertise it as a capability, I would rather call > >> it KVM_CAP_MSI_DEVID. > > > > I agree. Does userspace know that ITS guests always require devid? > > Well, as we are about to implement this: yes. But the issue is that MSI > injection and GSI routing code is generic PCI code in userland (at least > in kvmtool, guess in QEMU, too), so I don't want to pull in any kind of > ARM specific code in there. The idea is to always provide the device ID > from the PCI code (for PCI devices it's just the B/D/F triplet), but > only send it to the kernel if needed. Querying a KVM capability is > perfectly fine for this IMO. > > > I > > guess it's okay to return -EINVAL if the userspace doesn't set the flag > > but the virtual hardware requires it. > > Yes, that is what I do in the kernel implementation. And that is > perfectly fine: the ITS emulation does not work without a device ID, the > ITS driver in the guest assigns the very same payload (and address) to > different devices, so there is no way to tell the MSIs apart without a > unique device ID. > Just so I'm sure I understand: The way the kernel differentiates between no-devid and devid==0, is whether or not the devid flag is set, correct? -Christoffer -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
