xen-devel.lists.xenproject.org archive mirror
 help / color / mirror / Atom feed
From: David Vrabel <david.vrabel@citrix.com>
To: Jan Beulich <JBeulich@suse.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Vitaly Kuznetsov <vkuznets@redhat.com>
Cc: David Vrabel <dvrabel@cantab.net>,
	xen-devel@lists.xenproject.org, Andrew Jones <drjones@redhat.com>
Subject: Re: [PATCH v3 0/1] Introduce VCPUOP_reset_vcpu_info
Date: Fri, 22 Aug 2014 13:41:38 +0100	[thread overview]
Message-ID: <53F73A82.3060702@citrix.com> (raw)
In-Reply-To: <53F72490020000780002C91E@mail.emea.novell.com>

On 22/08/14 10:08, Jan Beulich wrote:
>>>> On 22.08.14 at 04:27, <konrad.wilk@oracle.com> wrote:
>> On Thu, Aug 21, 2014 at 12:35:36PM +0200, Vitaly Kuznetsov wrote:
>>> Recreating domain and copying all memory should work but we'll require
>>> host to have free memory, this can be an issue for large guests. If we
>>> try implementing 'reassigning' of memory without making a copy that can
>>> lead to same issues we have now: mounted grants, shared info,...
>>
>> That is a good point. Especially with 512GB guests. David, Jan, thoughts?
> 
> No, the idea was really to re-use the memory rather than copy it.
> Why would active grants or the use of shared info be a problem
> (and particularly one worse than with the vCPU-info-reset
> approach)?

An initial prototype that copies the memory may be a useful first step
as this will be straight-forward (most of the bits can be borrowed from
save/restore).

If the domain has mapped granted pages then the new domain should not
retain the mappings (otherwise you will end up with a domain having
mappings of a grant that does not agree with the domain in the granter's
grant table).

If the domain has granted pages, it should probably copy those pages and
not reuse then (because updating the map tracking info is probably
non-trivial).

David

  reply	other threads:[~2014-08-22 12:42 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-08-19 10:04 [PATCH v3 0/1] Introduce VCPUOP_reset_vcpu_info Vitaly Kuznetsov
2014-08-19 10:04 ` [PATCH v3 1/1] " Vitaly Kuznetsov
2014-08-19 10:21   ` Andrew Cooper
2014-08-19 23:22   ` Jan Beulich
2014-08-19 18:59 ` [PATCH v3 0/1] " David Vrabel
2014-08-20  8:43   ` Vitaly Kuznetsov
2014-08-20 13:37   ` Konrad Rzeszutek Wilk
2014-08-20 21:57     ` Konrad Rzeszutek Wilk
2014-08-21 10:35       ` Vitaly Kuznetsov
2014-08-22  2:27         ` Konrad Rzeszutek Wilk
2014-08-22  9:08           ` Jan Beulich
2014-08-22 12:41             ` David Vrabel [this message]
2014-08-22 13:23               ` Jan Beulich
2014-08-25 13:50           ` Vitaly Kuznetsov

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=53F73A82.3060702@citrix.com \
    --to=david.vrabel@citrix.com \
    --cc=JBeulich@suse.com \
    --cc=drjones@redhat.com \
    --cc=dvrabel@cantab.net \
    --cc=konrad.wilk@oracle.com \
    --cc=vkuznets@redhat.com \
    --cc=xen-devel@lists.xenproject.org \
    /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).