All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Dr. David Alan Gilbert" <dgilbert@redhat.com>
To: "Michael S. Tsirkin" <mst@redhat.com>
Cc: jasowang@redhat.com, vkuznets@redhat.com, qemu-devel@nongnu.org
Subject: Re: [PATCH 2/2] hyperv/synic: Allocate as ram_device
Date: Thu, 9 Jan 2020 12:22:37 +0000	[thread overview]
Message-ID: <20200109122237.GD6795@work-vm> (raw)
In-Reply-To: <20200109071454-mutt-send-email-mst@kernel.org>

* Michael S. Tsirkin (mst@redhat.com) wrote:
> On Thu, Jan 09, 2020 at 12:08:20PM +0000, Dr. David Alan Gilbert wrote:
> > * Michael S. Tsirkin (mst@redhat.com) wrote:
> > > On Wed, Jan 08, 2020 at 01:53:53PM +0000, Dr. David Alan Gilbert (git) wrote:
> > > > From: "Dr. David Alan Gilbert" <dgilbert@redhat.com>
> > > > 
> > > > Mark the synic pages as ram_device so that they won't be visible
> > > > to vhost.
> > > > 
> > > > Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
> > > 
> > > 
> > > I think I disagree with this one.
> > >  * A RAM device represents a mapping to a physical device, such as to a PCI
> > >  * MMIO BAR of an vfio-pci assigned device.  The memory region may be mapped
> > >  * into the VM address space and access to the region will modify memory
> > >  * directly.  However, the memory region should not be included in a memory
> > >  * dump (device may not be enabled/mapped at the time of the dump), and
> > >  * operations incompatible with manipulating MMIO should be avoided.  Replaces
> > >  * skip_dump flag.
> > > 
> > > Looks like an abuse of notation.
> > 
> > OK, it did feel a bit like that - any suggestions of another way to do
> > it?
> >   This clearly isn't normal RAM.
> > 
> > Dave
> 
> If it's just an optimization for vhost/postcopy/etc, then I think

Note it's not an optimisation; postcopy fails unless you can aggregate
the members of the hugepage.
And I think vhost-user will fail if you have too many sections - and
the 16 sections from synic I think will blow the slots available.

> an API that says how this isn't normal ram would be ok.
> E.g. it's not DMA'd into? Then maybe _nodma?

Do we want a new memory_region_init for that or just to be able to add
a flag?

Dave

> > > 
> > > 
> > > > ---
> > > >  hw/hyperv/hyperv.c | 14 ++++++++------
> > > >  1 file changed, 8 insertions(+), 6 deletions(-)
> > > > 
> > > > diff --git a/hw/hyperv/hyperv.c b/hw/hyperv/hyperv.c
> > > > index da8ce82725..4de3ec411d 100644
> > > > --- a/hw/hyperv/hyperv.c
> > > > +++ b/hw/hyperv/hyperv.c
> > > > @@ -95,12 +95,14 @@ static void synic_realize(DeviceState *dev, Error **errp)
> > > >      msgp_name = g_strdup_printf("synic-%u-msg-page", vp_index);
> > > >      eventp_name = g_strdup_printf("synic-%u-event-page", vp_index);
> > > >  
> > > > -    memory_region_init_ram(&synic->msg_page_mr, obj, msgp_name,
> > > > -                           sizeof(*synic->msg_page), &error_abort);
> > > > -    memory_region_init_ram(&synic->event_page_mr, obj, eventp_name,
> > > > -                           sizeof(*synic->event_page), &error_abort);
> > > > -    synic->msg_page = memory_region_get_ram_ptr(&synic->msg_page_mr);
> > > > -    synic->event_page = memory_region_get_ram_ptr(&synic->event_page_mr);
> > > > +    synic->msg_page = qemu_memalign(qemu_real_host_page_size,
> > > > +                                    sizeof(*synic->msg_page));
> > > > +    synic->event_page = qemu_memalign(qemu_real_host_page_size,
> > > > +                                      sizeof(*synic->event_page));
> > > > +    memory_region_init_ram_device_ptr(&synic->msg_page_mr, obj, msgp_name,
> > > > +                           sizeof(*synic->msg_page), synic->msg_page);
> > > > +    memory_region_init_ram_device_ptr(&synic->event_page_mr, obj, eventp_name,
> > > > +                           sizeof(*synic->event_page), synic->event_page);
> > > >  
> > > >      g_free(msgp_name);
> > > >      g_free(eventp_name);
> > > > -- 
> > > > 2.24.1
> > > 
> > --
> > Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK
> 
--
Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK



  reply	other threads:[~2020-01-09 12:23 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-01-08 13:53 [PATCH 0/2] exclude hyperv synic sections from vhost Dr. David Alan Gilbert (git)
2020-01-08 13:53 ` [PATCH 1/2] vhost: Don't pass ram device sections Dr. David Alan Gilbert (git)
2020-01-09 11:45   ` Michael S. Tsirkin
2020-01-09 11:56     ` Michael S. Tsirkin
2020-01-09 12:38   ` Roman Kagan
2020-01-09 12:42     ` Michael S. Tsirkin
2020-01-08 13:53 ` [PATCH 2/2] hyperv/synic: Allocate as ram_device Dr. David Alan Gilbert (git)
2020-01-09 11:48   ` Michael S. Tsirkin
2020-01-09 12:08     ` Dr. David Alan Gilbert
2020-01-09 12:18       ` Michael S. Tsirkin
2020-01-09 12:22         ` Dr. David Alan Gilbert [this message]
2020-01-09 13:00           ` Vitaly Kuznetsov
2020-01-09 13:24             ` Roman Kagan
2020-01-09 13:28               ` Dr. David Alan Gilbert
2020-01-09 16:12                 ` Roman Kagan
2020-01-09 16:27                   ` Dr. David Alan Gilbert
2020-01-09 17:13                     ` Roman Kagan
2020-01-09 13:06           ` Michael S. Tsirkin
2020-01-09 13:22             ` Dr. David Alan Gilbert
2020-01-09 13:27               ` Michael S. Tsirkin
2020-01-09 13:28                 ` Michael S. Tsirkin
2020-01-09 13:40                   ` Dr. David Alan Gilbert
2020-01-09 15:31               ` Paolo Bonzini
2020-01-09 15:38                 ` Dr. David Alan Gilbert
2020-01-09 15:40                 ` Vitaly Kuznetsov
2020-07-07 10:54                   ` Paolo Bonzini
2020-01-09 13:03   ` Roman Kagan
2020-01-09 13:08     ` Dr. David Alan Gilbert
2020-01-08 14:26 ` [PATCH 0/2] exclude hyperv synic sections from vhost Vitaly Kuznetsov
2020-01-09  3:00 ` Jason Wang
2020-01-09  9:07   ` Vitaly Kuznetsov
2020-01-09 12:02   ` Dr. David Alan Gilbert
2020-01-09 12:14     ` Michael S. Tsirkin
2020-01-09 11:53 ` Roman Kagan
2020-01-09 12:16   ` Dr. David Alan Gilbert

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=20200109122237.GD6795@work-vm \
    --to=dgilbert@redhat.com \
    --cc=jasowang@redhat.com \
    --cc=mst@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=vkuznets@redhat.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.