> From: Jason Gunthorpe <jgg@xxxxxxxxxx> > Sent: Wednesday, November 4, 2020 8:40 PM > > On Wed, Nov 04, 2020 at 03:41:33AM +0000, Tian, Kevin wrote: > > > From: Jason Gunthorpe <jgg@xxxxxxxxxx> > > > Sent: Tuesday, November 3, 2020 8:44 PM > > > > > > On Tue, Nov 03, 2020 at 02:49:27AM +0000, Tian, Kevin wrote: > > > > > > > > There is a missing hypercall to allow the guest to do this on its own, > > > > > presumably it will someday be fixed so IMS can work in guests. > > > > > > > > Hypercall is VMM specific, while IMS cap provides a VMM-agnostic > > > > interface so any guest driver (if following the spec) can seamlessly > > > > work on all hypervisors. > > > > > > It is a *VMM* issue, not PCI. Adding a PCI cap to describe a VMM issue > > > is architecturally wrong. > > > > > > IMS *can not work* in any hypervsior without some special > > > hypercall. Just block it in the platform code and forget about the PCI > > > cap. > > > > > > > It's per-device thing instead of platform thing. If the VMM understands > > the IMS format of a specific device and virtualize it to the guest, > > Please no! Adding device specific emulation is just going down deeper > into this bad architecture. > > Interrupts is a platform issue. Using emulation of MSI to dynamically Interrupt controller is a platform issue. Interrupt source is about device. > insert vectors to a VM was a reasonable, but hacky thing. Now it needs > proper platform support. > why is MSI emulation a hacky thing? isn't it defined by PCISIG? I guess that I must misunderstand your real point here... Thanks Kevin
