[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH 0/8] arm/virt: add usb support

From: Gerd Hoffmann
Subject: Re: [PATCH 0/8] arm/virt: add usb support
Date: Tue, 27 Oct 2020 07:56:21 +0100


> > Well, pci seems to come with some extra resource needs (see -M pc vs.
> > -M q35 memory footprint differences discussed some months ago).  Thats
> > why microvm started without pci support, and even now with pcie support
> > added it is optional (and off by default).
> I think PCI is too useful to discard.

Discard is out of question of course.  I'd only add the option to
disable it if not needed.

> You can run anything you want (practically) via PCI. If we make it
> optional then we're going to give ourselves the task of reimplementing
> memory mapped versions of all the functionality it gives us,

No.  Well, at least it would not be *my* plan to reach feature parity.
I'm just trying to make available what we have.

The mmio versions of usb host adapters are needed anyway to emulate some
SoCs.  Describing them in device tree / ACPI is standardized so they
just work without additional changes on the guest side.  So this is
really just adding the device to the machine, adding a device tree node,
adding a acpi dsdt entry (roughly a dozen lines of code each).

Having virtio(-mmio) and usb is enough to cover alot of use cases.
Especially on arm where virtio-gpu is the only display device option.

> all of which is extra code and all of which adds to the
> amount of stuff on the guest-to-QEMU security boundary.

usb is off by default so it doesn't add anything unless you
explicitly ask for it.

Oh, and pci adds some non-trivial stuff to the guest-to-QEMU
security boundary too ...

> I think to be persuaded that no-PCI was a good idea I'd
> want to at least see solid figures based on doing this
> for Arm and on having put a lot of effort into slimming
> down the PCI handling code/overhead in the guest and still
> not being able to get near an MMIO setup. That is, try the
> "improve the guest" approach first.

Ok, fair enough.

take care,

reply via email to

[Prev in Thread] Current Thread [Next in Thread]