On Thu, Aug 15, 2024 at 10:59:05AM -0600, Alex Williamson wrote:
> > This is probably the only way to approach this, trap and emulate the
> > places in the device that program additional interrupt sources and do
> > a full MSI-like flow to set them up in the kernel.
>
> Your last sentence here se
On Tue, 13 Aug 2024 20:37:24 -0300
Jason Gunthorpe wrote:
> On Tue, Aug 13, 2024 at 03:03:20PM -0600, Alex Williamson wrote:
>
> > How does the guest know to write a remappable vector format? How does
> > the guest know the host interrupt architecture? For example why would
> > an aarch64 gues
On Tue, Aug 13, 2024 at 03:03:20PM -0600, Alex Williamson wrote:
> How does the guest know to write a remappable vector format? How does
> the guest know the host interrupt architecture? For example why would
> an aarch64 guest program an MSI vector of 0xfee... if the host is x86?
All excellent
On Tue, 13 Aug 2024 13:43:41 -0300
Jason Gunthorpe wrote:
> On Mon, Aug 12, 2024 at 11:00:40AM -0600, Alex Williamson wrote:
> > These devices have an embedded interrupt controller which is programmed
> > with guest physical MSI address/data, which doesn't work. We need
> > vfio-pci kernel suppo
On Mon, Aug 12, 2024 at 11:00:40AM -0600, Alex Williamson wrote:
> These devices have an embedded interrupt controller which is programmed
> with guest physical MSI address/data, which doesn't work. We need
> vfio-pci kernel support to provide a device feature which disables
> virtualization of th
These devices have an embedded interrupt controller which is programmed
with guest physical MSI address/data, which doesn't work. We need
vfio-pci kernel support to provide a device feature which disables
virtualization of the MSI capability registers. Then we can do brute
force testing for write