On Fri, Apr 24, 2020 at 09:50:04AM +0100, André Przywara wrote: > On 24/04/2020 09:41, Will Deacon wrote: > > On Thu, Apr 23, 2020 at 06:38:40PM +0100, Andre Przywara wrote: > >> diff --git a/devices.c b/devices.c > >> index a7c666a7..2c8b2665 100644 > >> --- a/devices.c > >> +++ b/devices.c > >> @@ -1,7 +1,6 @@ > >> #include "kvm/devices.h" > >> #include "kvm/kvm.h" > >> #include "kvm/pci.h" > >> -#include "kvm/virtio-mmio.h" > >> > >> #include <linux/err.h> > >> #include <linux/rbtree.h> > >> @@ -33,9 +32,6 @@ int device__register(struct device_header *dev) > >> case DEVICE_BUS_PCI: > >> pci__assign_irq(dev); > >> break; > >> - case DEVICE_BUS_MMIO: > >> - virtio_mmio_assign_irq(dev); > >> - break; > > > > Hmm, but then it's a bit ugly to handle these differently to PCI. How > > difficult is it to add a new bus type instead? e.g. stick the virtio mmio > > devices on DEVICE_BUS_VIRTIO_MMIO and then add the non-virtio MMIO devices > > to DEVICE_BUS_MMIO? > > I have another patch to also do the IRQ allocation for PCI devices in > their callers. This avoids the allocation on an IRQ for vesa, for > instance, but otherwise doesn't solve a real problem, so I didn't post > it yet. > By looking at devices.c, I feel like this should only be handling the > administrative part of managing the device_header structs in the rbtree. > Dealing with bus specific things looks out of scope for this file, IMHO. > > If you agree, I will send the patch shortly.
Yes please. Will _______________________________________________ kvmarm mailing list [email protected] https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
