[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [RFC] virtio-mmio: implement modern (v2) personality (v
From: |
Laszlo Ersek |
Subject: |
Re: [Qemu-devel] [RFC] virtio-mmio: implement modern (v2) personality (virtio-1) |
Date: |
Sat, 3 Aug 2019 00:33:40 +0200 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 |
On 08/02/19 11:20, Peter Maydell wrote:
> On Fri, 2 Aug 2019 at 01:26, Laszlo Ersek <address@hidden> wrote:
>> But it's extra work, not entirely risk-free (regressions), and I can't
>> tell if someone out there still uses virtio-mmio (despite me thinking
>> that would be unreasonable). I wouldn't like to see more work sunk into
>> it either way :)
>
> The main reasons I still see people using virtio-mmio for
> the 'virt' board are:
> * still using old but working command lines
> * newer setups that were put together working from older tutorials
> that recommended virtio-mmio because they predated virtio-pci
> support being widespread
> * using older (eg distro) kernels -- for 32-bit kernels in
> particular it was a while before the virtio-pci support
> got built in the default configs I think, and then longer
> again until those got into stable distro releases
There was one time when edk2 core modules gained a feature for marking
the DXE phase stack non-executable. We happily enabled it in OVMF. Then
people reported that UEFI grub in their old Debian guests had broken --
on their hosts carrying OVMF binaries built from upstream. :) We had to
flip the default off in OVMF, and we've stuck with that ever since...
https://github.com/tianocore/edk2/commit/d20b06a3afdf
> I wouldn't be surprised if some of those applied also to
> via-OVMF boot setups as well as direct kernel boot. So it
> depends a bit what your tolerance for breaking existing
> user setups is.
Near zero. :)
Thanks
Laszlo