Hi Micah, On 5/14/20 7:44 PM, Micah Morton wrote: > On Wed, May 13, 2020 at 3:05 PM Paolo Bonzini <pbonzini@xxxxxxxxxx> 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? VFIO_PLATFORM only is compiled on ARM today but that's probably not the main issue here. I don't know if the fact the platform devices you want to assign are behind this PCI I2C controller does change anything in the way we would bind the devices to vfio-platform. Up to now, in QEMU we have only generated DT bindings for the assigned platform devices. Generating AML code has never been experienced. What I don't get in your existing POC is how your enumerate the platform devices resources (regs, IRQs) behing your controller. I understand you devised a solution to expose the specific IRQ but what about regs? How are they presented to your guest? Thanks Eric > >> >> 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 >> >
