Add a second ioapic to microvm.  Gives us more IRQ lines we can
use for virtio-mmio devices.  Bump number of possible virtio-mmio
devices from 8 to 24.

Gerd Hoffmann (4):
  microvm: make number of virtio transports runtime configurable
  microvm: make pcie irq base runtime configurable
  microvm: add second ioapic
  microvm: reconfigure irqs if second ioapic is available

 include/hw/i386/ioapic_internal.h |  2 +-
 include/hw/i386/microvm.h         |  4 +--
 include/hw/i386/x86.h             |  1 +
 hw/i386/acpi-common.c             | 12 ++++++-
 hw/i386/microvm.c                 | 54 +++++++++++++++++++++++++------
 5 files changed, 60 insertions(+), 13 deletions(-)

-- 
2.27.0

On 10/16/20 1:43 PM, Gerd Hoffmann wrote:
> Add a second ioapic to microvm.  Gives us more IRQ lines we can
> use for virtio-mmio devices.  Bump number of possible virtio-mmio
> devices from 8 to 24.
> 
> Gerd Hoffmann (4):
>    microvm: make number of virtio transports runtime configurable
>    microvm: make pcie irq base runtime configurable
>    microvm: add second ioapic
>    microvm: reconfigure irqs if second ioapic is available

After looking at Laurent's m68k virt machine,
I wonder if it is possible to use the Goldfish-PIC
with the MicroVM instead (or another Goldfish machine
type).

On Fri, Oct 16, 2020 at 03:16:20PM +0200, Philippe Mathieu-Daudé wrote:
> On 10/16/20 1:43 PM, Gerd Hoffmann wrote:
> > Add a second ioapic to microvm.  Gives us more IRQ lines we can
> > use for virtio-mmio devices.  Bump number of possible virtio-mmio
> > devices from 8 to 24.
> > 
> > Gerd Hoffmann (4):
> >    microvm: make number of virtio transports runtime configurable
> >    microvm: make pcie irq base runtime configurable
> >    microvm: add second ioapic
> >    microvm: reconfigure irqs if second ioapic is available
> 
> After looking at Laurent's m68k virt machine,
> I wonder if it is possible to use the Goldfish-PIC
> with the MicroVM instead (or another Goldfish machine
> type).

/me updates the WIP microvm blog post ;)

Problem with goldfish is that it tries to drag over stuff from the arm
world to x86.  Specifically device trees.  On arm this works reasonable
well meanwhile.  Firmware and bootloaders have support for using device
trees and passing them on in the boot chain, so the linux kernel has a
device tree which it can use to figure which hardware is present on the
system.

On x86 this doesn't work at all, so you'll end up building a custom
kernel for the goldfish platform.  A stock distro kernel is not going
to work.

I'm to driving microvm the opposite direction:  Add acpi support.  That
is the standard x86 way to do hardware discovery (for hardware you can't
detect in other ways like pci devices).  Which in turn allows us to drop
microvm-specific quirks (like adding virtio-mmio devices to the kernel
command line) when booting linux.

So, for microvm this is not going to happen.  But feel free to add a
goldfish machine type if you want play with that.  The microvm merge
also cleaned up the x86 code base which in turn should make this
relatively easy now.

take care,
  Gerd

On 10/19/20 9:07 AM, Gerd Hoffmann wrote:
> On Fri, Oct 16, 2020 at 03:16:20PM +0200, Philippe Mathieu-Daudé wrote:
>> On 10/16/20 1:43 PM, Gerd Hoffmann wrote:
>>> Add a second ioapic to microvm.  Gives us more IRQ lines we can
>>> use for virtio-mmio devices.  Bump number of possible virtio-mmio
>>> devices from 8 to 24.
>>>
>>> Gerd Hoffmann (4):
>>>     microvm: make number of virtio transports runtime configurable
>>>     microvm: make pcie irq base runtime configurable
>>>     microvm: add second ioapic
>>>     microvm: reconfigure irqs if second ioapic is available
>>
>> After looking at Laurent's m68k virt machine,
>> I wonder if it is possible to use the Goldfish-PIC
>> with the MicroVM instead (or another Goldfish machine
>> type).
> 
> /me updates the WIP microvm blog post ;)
> 
> Problem with goldfish is that it tries to drag over stuff from the arm
> world to x86.  Specifically device trees.  On arm this works reasonable
> well meanwhile.  Firmware and bootloaders have support for using device
> trees and passing them on in the boot chain, so the linux kernel has a
> device tree which it can use to figure which hardware is present on the
> system.
> 
> On x86 this doesn't work at all, so you'll end up building a custom
> kernel for the goldfish platform.  A stock distro kernel is not going
> to work.
> 
> I'm to driving microvm the opposite direction:  Add acpi support.  That
> is the standard x86 way to do hardware discovery (for hardware you can't
> detect in other ways like pci devices).  Which in turn allows us to drop
> microvm-specific quirks (like adding virtio-mmio devices to the kernel
> command line) when booting linux.

My x86 knowledge is limited to asm, not to the architecture.
While this might be obvious for some, it helped me to better
understand, so thank you for the explanation :)

> So, for microvm this is not going to happen.  But feel free to add a
> goldfish machine type if you want play with that.  The microvm merge
> also cleaned up the x86 code base which in turn should make this
> relatively easy now.
> 
> take care,
>    Gerd
> 

  Hi,

> /me updates the WIP microvm blog post ;)

Online now.
https://www.kraxel.org/blog/2020/10/qemu-microvm-acpi/

take care,
  Gerd