Re: [RFC PATCH] KVM: Add module for IRQ forwarding

[Micah Morton <mortonm@chromium.org>]

On Wed, May 13, 2020 at 3:05 PM Paolo Bonzini <pbonzini@redhat.com> wrote:
>
> On 13/05/20 21:10, Micah Morton wrote:
> > * If we only care about the bus controller existing (in an emulated
> > fashion) enough for the guest to discover the device in question, this
> > could work. I’m concerned that power management could be an issue here
> > however. For instance, I have a touchscreen device assigned to the
> > guest (irq forwarding done with this module) that in response to the
> > screen being touched prepares the i2c controller for a transaction by
> > calling into the PM system which end up writing to the PCI config
> > space** (here https://elixir.bootlin.com/linux/v5.6.12/source/drivers/i2c/busses/i2c-designware-master.c#L435).
> > It seems like this kind of scenario expands the scope of what would
> > need to be supported by the emulated i2c controller, which is less
> > ideal. The way I have it currently working, vfio-pci emulates the PCI
> > config space so the guest can do power management by accessing that
> > space.
>
> This wouldn't be a problem.  When the emulated i2c controller starts a
> transaction on th edevice, it will be performed by the host i2c
> controller and this will lead to the same config space write.

I guess what you're saying is there would be an i2c controller
(emulated PCI device) in the guest and the i2c device driver would
still call i2c_dw_xfer as above and the execution in the guest would
still continue all the way to pci_write_config_word(). Then when the
guest executes the actual config write it would trap to the host,
which would need to have the logic that the guest is trying to do
runtime PM commands on an emulated PCI device so we need to step in
and reset the actual PCI device on the host that backs that emulated
device. Is this right?

Again, this is assuming we have the infrastructure to pass platform
devices on x86 to the guest with vfio-platform, which I don't think is
the case. +Auger Eric (not sure why gmail puts your name backwards)
would you be able to comment on this based on my previous message?

>
> I have another question: would it be possible to expose this IRQ through
> /dev/i2c-* instead of messing with VFIO?
>
> In fact, adding support for /dev/i2c passthrough to QEMU has long been a
> pet idea of mine (my usecase was different though: the idea was to write
> programs for a microcontroller on an ARM single board computer and run
> them under QEMU in emulation mode).  It's not trivial, because there
> could be some impedence mismatch between the guest (which might be
> programmed against a low-level controller or might even do bit banging)
> and the i2c-dev interface which is more high level.  Also QEMU cannot do
> clock stretching right now.  However, it's certainly doable.

I agree that would be a cool thing to have in QEMU. Unfortunately I am
interested in assigning other PCI bus controllers to a guest VM and
(similar to the i2c example above) in some cases these busses (e.g.
LPC, SPI) have devices with arbitrary interrupts that need to be
forwarded into the guest for things to work.

I realize this may seem like an over-use of VFIO, but I'm actually
coming from the angle of wanting to assign _most_ of the important
hardware on my device to a VM guest, and I'm looking to avoid
emulation wherever possible. Of course there will be devices like the
IOAPIC for which emulation is unavoidable, but I think emulation is
avoidable here for the busses we've mentioned if there is a way to
forward arbitrary interrupts into the guest.

Since all these use cases are so close to working with vfio-pci right
out of the box, I was really hoping to come up with a simple and
generic solution to the arbitrary interrupt problem that can be used
for multiple bus types.

>
> >> (Finally, in the past we were doing device assignment tasks within KVM
> >> and it was a bad idea.  Anything you want to do within KVM with respect
> >> to device assignment, someone else will want to do it from bare metal.
> >
> > Are you saying people would want to use this in non-virtualized
> > scenarios like running drivers in userspace without any VMM/guest? And
> > they could do that if this was part of VFIO and not part of KVM?
>
> Yes, see above for an example.
>
> Paolo
>