Re: [Qemu-devel] [PATCH V11 0/8] add pvpanic mmio support

[Daniel P . Berrangé]

On Mon, Dec 03, 2018 at 06:50:03PM +0000, Peter Maydell wrote:
> On Mon, 3 Dec 2018 at 11:04, Peng Hao <address@hidden> wrote:
> >
> > The first patches are simple cleanups:
> >      - patch 1 move the pvpanic device with the 'ocmmon objects' so we 
> > compile
> >                it once for the x86/arm/aarch64 archs,
> >      - patch 2 simply renames ISA fields/definitions to generic ones.
> >
> >      Then instead of add/use the MMIO pvpanic device in the virt machine in 
> > an
> >      unique patch, I split it in two distinct patches:
> >      - patch 3 uses Peng Hao's work, but add the MMIO interface to the 
> > existing
> >         device (no logical change).
> >      - patch 4 is Peng Hao's work in the virt machine (no logical change).
> >      - patch 5 add pvpanic device in acpi table in virt machine
> >      v2 from Peng Hao is:
> >      https://lists.gnu.org/archive/html/qemu-devel/2018-10/msg03433.html
> 
> I would still prefer to see a more detailed examination of whether
> we can do this with a PCI device before we commit to taking the
> MMIO version into the virt board.

The original design rational for using an I/O port is mentioned here,
though it is quite brief:

  http://lists.gnu.org/archive/html/qemu-devel/2012-10/msg04361.html

[quote]
We have three solutions to implement this feature:
1. use vmcall
2. use I/O port
3. use virtio-serial.

We have decided to avoid touching hypervisor. The reason why I choose
choose the I/O port is:
1. it is easier to implememt
2. it does not depend any virtual device
3. it can work when starting the kernel
[/quote]

Later postings then exposed the port via ACPI

  http://lists.nongnu.org/archive/html/qemu-devel/2013-03/msg02293.html

After it had merged there were some changes and the question of turning
it into a PCI device was raised. Paolo was concerned that the guest OS
is in an unknown state (arbitrary locks held, data structures corrupt,
etc) when panic is fired, so simplicity of the I/O port was desirable:

  https://lists.gnu.org/archive/html/qemu-devel/2013-08/msg03309.html

Anthony countered that even a PCI device could simply do an outb() in
config space:

  https://lists.gnu.org/archive/html/qemu-devel/2013-08/msg03325.html

So it is not clear using a PCI device is in fact a problem in terms of
reliability at time of firing.


Perhaps more relevant is the question of how easily it can be initialized,
as that affects whether it can be used for panics during very early boot,
or from firmware:

  https://lists.gnu.org/archive/html/qemu-devel/2013-08/msg03296.html

Finally, there is also the point that PCI slots are precious, and this
is something to be enabled out of the box on all VMs, so you'd be removing
one extra PCI slot from general usage. Thus mgmt apps would need to start
adding PCI bridges sooner. Not a blocker but something to bear in mind
when weighing up options.

Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|