On 10/22/2020 1:17 PM, Peter Maydell wrote:
> On Thu, 22 Oct 2020 at 09:25, Mihai Carabas <mihai.carabas@oracle.com> wrote:
>> The patchset was assembled from chuncks from some old patches from 2018 [1]
>> which were left unmerged and some additions from me. Surprisingly their Linux
>> kernel counterpart were merged (so the pvpanic driver from the kernel supports
>> mmio).
>>
>> I have seen the discussions about moving the pvpanic to PCI [1]. Those patches
>> were sent but nothing happened. Also they are not trivial and require major
>> modifications at the driver level also. Given the fact that we already have
>> mmio driver support for pvpanic in the Linux kernel, I have sent these patches
>> to ask again the maintainers if this can be merged.
>
> I'm afraid the answer is still the same. You need to provide
> a convincing argument for why this needs to be an MMIO
> device rather than a PCI device. I really don't want to
> add MMIO devices to the virt board if I can avoid it,
> because they're all extra code and potential extra
> security boundary attack surface. PCI devices are guest
> probeable and user-pluggable so they're almost always
> nicer to use than MMIO.
>
Thank you for your input.
The reason why pvpanic should be MMIO is that is a special device which
is not used commonly by the user (aka VM), it is not need to be
hot-plugable and it does not have a hardware correspondent to be a PCI
device. Another reason is that MMIO support was accepted in the kernel
driver and it is pretty useless there without a device.
I know it seems that I want to get this on the short-path, but at this
point having a kernel driver in the upstream and no device to test it
against it is pretty weird.
Thank you,
Mihai