qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: "Dr. David Alan Gilbert" <dgilbert@redhat.com>
To: Paolo Bonzini <pbonzini@redhat.com>
Cc: jasowang@redhat.com, vkuznets@redhat.com, qemu-devel@nongnu.org,
	"Michael S. Tsirkin" <mst@redhat.com>
Subject: Re: [PATCH 2/2] hyperv/synic: Allocate as ram_device
Date: Thu, 9 Jan 2020 15:38:00 +0000	[thread overview]
Message-ID: <20200109153800.GJ6795@work-vm> (raw)
In-Reply-To: <3162676e-da40-7a3f-1777-2ed4f3efffe1@redhat.com>

* Paolo Bonzini (pbonzini@redhat.com) wrote:
> On 09/01/20 14:22, Dr. David Alan Gilbert wrote:
> > * Michael S. Tsirkin (mst@redhat.com) wrote:
> >> On Thu, Jan 09, 2020 at 12:22:37PM +0000, Dr. David Alan Gilbert wrote:
> >>> Do we want a new memory_region_init for that or just to be able to add
> >>> a flag?
> >>>
> >> I think a flag API is preferable since this can apply to any kind of
> >> region. But can go either way, Paolo's the maintainer there.
> > 
> > (Copying Paolo in)
> > So what exactly does this flag mean; to me it's 'no vhost' - but is it
> > actually more general?
> 
> It has two more effects in addition to no vhost:
> 
> 1) it is skipped when dumping the guest (is this a good or bad idea for
> SynIC?)
> 
> 2) accesses to the region will use the specified size (e.g. 4-bytes for
> address_space_stl, 1-byte for address_space_stb) instead of a memcpy.
> Doesn't really matter for SynIC regions.
> 
> If (1) is a good idea, then it's 2 out of 3 and I guess the patch is okay.

It's probably best  to keep them in the dump because they give some info
on the current state of the windows guest and interrupts.
Also, as Roman points out the ram-device pages aren't migrated, so we
need to fix that as well.

So, do we add a new flag? If so, is no-vhost what we want?

Dave

> Paolo
> 
--
Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK



  reply	other threads:[~2020-01-09 15:44 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
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 [this message]
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=20200109153800.GJ6795@work-vm \
    --to=dgilbert@redhat.com \
    --cc=jasowang@redhat.com \
    --cc=mst@redhat.com \
    --cc=pbonzini@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 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).