qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Igor Mammedov <imammedo@redhat.com>
To: David Hildenbrand <david@redhat.com>
Cc: qemu-devel@nongnu.org, Pankaj Gupta <pagupta@redhat.com>,
	Eduardo Habkost <ehabkost@redhat.com>,
	"Michael S . Tsirkin" <mst@redhat.com>,
	Markus Armbruster <armbru@redhat.com>,
	Alexander Graf <agraf@suse.de>,
	qemu-s390x@nongnu.org, qemu-ppc@nongnu.org,
	Paolo Bonzini <pbonzini@redhat.com>,
	Marcel Apfelbaum <marcel@redhat.com>,
	David Gibson <david@gibson.dropbear.id.au>,
	Richard Henderson <rth@twiddle.net>
Subject: Re: [Qemu-devel] [PATCH v1 0/8] MemoryDevice: introduce and use ResourceHandler
Date: Fri, 4 May 2018 12:00:32 +0200	[thread overview]
Message-ID: <20180504120032.73ca4365@redhat.com> (raw)
In-Reply-To: <c7873a84-fa46-0a5d-1091-b2bb5688a1b6@redhat.com>

On Fri, 4 May 2018 11:19:25 +0200
David Hildenbrand <david@redhat.com> wrote:

> On 04.05.2018 10:49, Igor Mammedov wrote:
> > On Thu,  3 May 2018 17:49:28 +0200
> > David Hildenbrand <david@redhat.com> wrote:
> >   
> >> Hotplug handlers usually have the following tasks:
> >> 1. Allocate some resources for a new device
> >> 2. Make the new device visible for the guest
> >> 3. Notify the guest about the new device
> >>
> >> Hotplug handlers have right now one limitation: They handle their own
> >> context and only care about resources they manage.
> >>
> >> We can have devices that need certain other resources that are e.g.
> >> system resources managed by the machine. We need a clean way to assign
> >> these resources (without violating layers as brought up by Igor).
> >>
> >> One example is virtio-mem/virtio-pmem. Both device types need to be
> >> assigned some region in guest physical address space. This device memory
> >> belongs to the machine and is managed by it. However, virito devices are
> >> hotplugged using the hotplug handler their proxy device implements. So we
> >> could trigger e.g. a PCI hotplug handler for virtio-pci or a CSS/CCW
> >> hotplug handler for virtio-ccw. But definetly not the machine.
> >>
> >> So let's generalize the task of "assigning" resources and use it directly
> >> for memory devices. We now have a clean way to support any kind of memory
> >> device - independent of the underlying device type. Right now, only one
> >> resource handler per device can be supported (in addition to the existing
> >> hotplug handler).  
> > So far I've just skimmed through series and still don't get clear
> > picture if new interface is really needed.
> > I'd like very much to see patches for how virtio-[p]mem in CCW and PCI
> > case would utilize this.  
> 
> Sure, I think you've seen the problematic parts in the latest
> virtio-pmem prototype
> (https://www.spinics.net/lists/linux-mm/msg151081.html).
> 
> There, we do the assignment from the realize function, which you
> described as layer violation. I will ask Pankaj to rebase his work on
> this series.
That's too premature at the moment.

> Until then, I can point you at the current QEMU side prototype of
> virtio-mem. I won't be posting these as patches as there are still many
> things to sort out and clean up. The prototype currently works on x86
> and s390x.
> 
> You can find the latest prototype on github, including patches of this
> series at https://github.com/davidhildenbrand/qemu/tree/virtio-mem
> 
> Interesting patches are:
> - "s390x: inititalize memory region for memory devices"
> -- Provide a region for memory devices just like x86
> - "virtio-mem: paravirtualized memory"
> -- Prototype of virtio-mem.
> - "virtio-ccw: add proxy for virtio-mem"
> -- CCW proxy device for virtio-mem (using the CSS/CCW hotplug handler)
> - "virtio-mem: paravirtualized memory"
> -- PCI proxy device for virtio-mem (using PCI hotplug handler)
> 
> Note how virtio-mem implements the MemoryDevice interface and how
> resource assignments happens without any layer violations (and no
> modifications to any hotplug handler).
Thanks, that should be sufficient to get idea.
I'll look into it and come back here with concrete comments or
suggesting alternative.

  reply	other threads:[~2018-05-04 10:00 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-05-03 15:49 [Qemu-devel] [PATCH v1 0/8] MemoryDevice: introduce and use ResourceHandler David Hildenbrand
2018-05-03 15:49 ` [Qemu-devel] [PATCH v1 1/8] memory-device: always compile support for memory devices for SOFTMMU David Hildenbrand
2018-05-03 15:49 ` [Qemu-devel] [PATCH v1 2/8] qdev: introduce ResourceHandler as a first-stage hotplug handler David Hildenbrand
2018-05-04 14:22   ` David Hildenbrand
2018-05-03 15:49 ` [Qemu-devel] [PATCH v1 3/8] machine: provide default resource handler David Hildenbrand
2018-05-03 15:49 ` [Qemu-devel] [PATCH v1 4/8] memory-device: new functions to handle resource assignment David Hildenbrand
2018-05-03 15:49 ` [Qemu-devel] [PATCH v1 5/8] pc-dimm: implement new memory device functions David Hildenbrand
2018-05-03 15:49 ` [Qemu-devel] [PATCH v1 6/8] machine: introduce enforce_memory_device_align() and add it for pc David Hildenbrand
2018-05-03 15:49 ` [Qemu-devel] [PATCH v1 7/8] memory-device: factor out pre-assign into default resource handler David Hildenbrand
2018-05-03 15:49 ` [Qemu-devel] [PATCH v1 8/8] memory-device: factor out (un)assign " David Hildenbrand
2018-05-04  8:49 ` [Qemu-devel] [PATCH v1 0/8] MemoryDevice: introduce and use ResourceHandler Igor Mammedov
2018-05-04  9:19   ` David Hildenbrand
2018-05-04 10:00     ` Igor Mammedov [this message]
2018-05-04 11:49       ` David Hildenbrand
2018-05-09 14:13 ` David Hildenbrand
2018-05-10 13:02   ` Igor Mammedov
2018-05-10 13:20     ` David Hildenbrand
2018-05-10 13:32       ` Igor Mammedov
2018-05-11  7:41         ` David Hildenbrand
2018-05-10 13:04   ` [Qemu-devel] [PATCH] qdev: let machine hotplug handler to override bus hotplug handler Igor Mammedov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20180504120032.73ca4365@redhat.com \
    --to=imammedo@redhat.com \
    --cc=agraf@suse.de \
    --cc=armbru@redhat.com \
    --cc=david@gibson.dropbear.id.au \
    --cc=david@redhat.com \
    --cc=ehabkost@redhat.com \
    --cc=marcel@redhat.com \
    --cc=mst@redhat.com \
    --cc=pagupta@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=qemu-ppc@nongnu.org \
    --cc=qemu-s390x@nongnu.org \
    --cc=rth@twiddle.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).