[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [qemu-s390x] [Qemu-devel] [PATCH RFCv2 0/9] qdev: Hotplug handler ch
Re: [qemu-s390x] [Qemu-devel] [PATCH RFCv2 0/9] qdev: Hotplug handler chaining + virtio-pmem
Wed, 6 Feb 2019 14:18:34 +0100
On Thu, 31 Jan 2019 15:52:25 +0100
David Hildenbrand <address@hidden> wrote:
> On 28.01.19 15:18, Igor Mammedov wrote:
> > On Wed, 23 Jan 2019 20:55:18 +0100
> > David Hildenbrand <address@hidden> wrote:
> >> This series implements supprt for hotplug handler chaining (proposed
> >> by Igor), something that is necessary to turn selected virtio devices into
> >> memory devices. Planned devices inlude virtio-mem and virtio-pmem. The
> >> current prototype of virtio-pmem is included.
> >> The machine hotplug handler can intercept hotplug handler calls
> >> to properly prepare/teardown the memory device part of a device. Control
> >> is then passed on to the actual bus hotplug handler. So the default hotplug
> >> handler is effectively overwritten to make interception possible.
> >> It is based on the following patches/series
> >> - [PATCH v1] pc: Use hotplug_handler_(plug|unplug|unplug_request)
> >> -- Queued by Paolo
> >> - [PATCH v3 0/2] s390x/pci: hotplug handler fixes and reworks
> >> Patch 1-3 are the preparations for hotplug handler chaining.
> > we probably should merge this ones even without pmem patches.
> Just to verify, does the general approach on how to hotplug virtio based
> memory devices now looks okay to you?
it looks fine (minor comments aside)
rant: beside a little bit complex dance with nowadays virtio type names
but that's not related to your series. It just makes understanding virtio
code more difficult not saying it's wasn't already complicated to begin with.
> I'll resend the qdev parts separately after more testing. Thanks!
- Re: [qemu-s390x] [Qemu-devel] [PATCH RFCv2 0/9] qdev: Hotplug handler chaining + virtio-pmem,
Igor Mammedov <=