From: Keir Fraser <keir.xen@gmail.com> To: Jan Beulich <JBeulich@novell.com>, <Ian.Campbell@citrix.com>, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>, <keir@xen.org> Cc: <olaf@aepfle.de>, <xen-devel@lists.xensource.com>, <linux-kernel@vger.kernel.org> Subject: Re: [Xen-devel] [PATCH] xen: update machine_to_phys_order on resume Date: Mon, 18 Jul 2011 08:27:06 +0100 [thread overview] Message-ID: <CA499EDA.1E10E%keir.xen@gmail.com> (raw) In-Reply-To: <4E23F76D020000780004DCD9@nat28.tlf.novell.com> On 18/07/2011 08:05, "Jan Beulich" <JBeulich@novell.com> wrote: >>>> On 15.07.11 at 20:23, Keir Fraser <keir.xen@gmail.com> wrote: >> On 15/07/2011 18:30, "Jan Beulich" <JBeulich@novell.com> wrote: >> >>> Actually, one more thought: What's the purpose of this hypercall if >>> it is set in stone what values it ought to return? Isn't a guest using >>> it (supposed to be) advertising that it can deal with the values being >>> variable (and it was just overlooked so far that this doesn't only >>> include varying values from boot to boot, but also migration)? Or in >>> other words, if we found a need to relocate the M2P table or grow >>> its static maximum size, it would be impossible to migrate guests >>> from an old to a new hypervisor. >> >> Fair point. There has to be a static fallback set of return values for old >> guests. > > Hmm, in my reading the two sentences sort of contradict each other. > That is, I'm not certain what route we want to go here: Keep things > the way they are after 23706:3dd399873c9e, and introduce a > completely new discovery mechanism if we find it necessary to change > the M2P table's location and/or size, including a mechanism for a guest > to announce it's capable of dealing with that? If so, I think we ought > to add a comment to the hypercall implementation documenting that > its return values must not be changed (and why). We can return different values from the existing hypercall if that is negotiated with the guest, at run time or build time. -- Keir > Jan >
WARNING: multiple messages have this Message-ID (diff)
From: Keir Fraser <keir.xen@gmail.com> To: Jan Beulich <JBeulich@novell.com>, Ian.Campbell@citrix.com, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>, keir@xen.org Cc: olaf@aepfle.de, xen-devel@lists.xensource.com, linux-kernel@vger.kernel.org Subject: Re: [PATCH] xen: update machine_to_phys_order on resume Date: Mon, 18 Jul 2011 08:27:06 +0100 [thread overview] Message-ID: <CA499EDA.1E10E%keir.xen@gmail.com> (raw) In-Reply-To: <4E23F76D020000780004DCD9@nat28.tlf.novell.com> On 18/07/2011 08:05, "Jan Beulich" <JBeulich@novell.com> wrote: >>>> On 15.07.11 at 20:23, Keir Fraser <keir.xen@gmail.com> wrote: >> On 15/07/2011 18:30, "Jan Beulich" <JBeulich@novell.com> wrote: >> >>> Actually, one more thought: What's the purpose of this hypercall if >>> it is set in stone what values it ought to return? Isn't a guest using >>> it (supposed to be) advertising that it can deal with the values being >>> variable (and it was just overlooked so far that this doesn't only >>> include varying values from boot to boot, but also migration)? Or in >>> other words, if we found a need to relocate the M2P table or grow >>> its static maximum size, it would be impossible to migrate guests >>> from an old to a new hypervisor. >> >> Fair point. There has to be a static fallback set of return values for old >> guests. > > Hmm, in my reading the two sentences sort of contradict each other. > That is, I'm not certain what route we want to go here: Keep things > the way they are after 23706:3dd399873c9e, and introduce a > completely new discovery mechanism if we find it necessary to change > the M2P table's location and/or size, including a mechanism for a guest > to announce it's capable of dealing with that? If so, I think we ought > to add a comment to the hypercall implementation documenting that > its return values must not be changed (and why). We can return different values from the existing hypercall if that is negotiated with the guest, at run time or build time. -- Keir > Jan >
next prev parent reply other threads:[~2011-07-18 7:27 UTC|newest] Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top 2011-07-15 17:30 [PATCH] xen: update machine_to_phys_order on resume Jan Beulich 2011-07-15 18:23 ` [Xen-devel] " Keir Fraser 2011-07-15 18:23 ` Keir Fraser 2011-07-18 7:05 ` [Xen-devel] " Jan Beulich 2011-07-18 7:05 ` Jan Beulich 2011-07-18 7:27 ` Keir Fraser [this message] 2011-07-18 7:27 ` Keir Fraser 2011-07-18 8:31 ` [Xen-devel] " Ian Campbell 2011-07-18 8:47 ` Jan Beulich 2011-07-18 8:47 ` Jan Beulich 2011-07-18 9:05 ` [Xen-devel] " Ian Campbell 2011-07-18 9:50 ` Jan Beulich -- strict thread matches above, loose matches on Subject: below -- 2011-07-13 14:29 Jan Beulich 2011-07-14 10:26 ` [Xen-devel] " Olaf Hering 2011-07-15 8:32 ` Jan Beulich 2011-07-15 8:32 ` Jan Beulich 2011-07-01 10:41 migration of pv guest fails from small to large host Olaf Hering 2011-07-12 16:43 ` [PATCH] xen: update machine_to_phys_order on resume Olaf Hering 2011-07-12 18:11 ` [Xen-devel] " Konrad Rzeszutek Wilk 2011-07-13 9:12 ` Ian Campbell 2011-07-13 13:20 ` Konrad Rzeszutek Wilk 2011-07-15 8:56 ` Jan Beulich 2011-07-15 16:05 ` Jan Beulich
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=CA499EDA.1E10E%keir.xen@gmail.com \ --to=keir.xen@gmail.com \ --cc=Ian.Campbell@citrix.com \ --cc=JBeulich@novell.com \ --cc=keir@xen.org \ --cc=konrad.wilk@oracle.com \ --cc=linux-kernel@vger.kernel.org \ --cc=olaf@aepfle.de \ --cc=xen-devel@lists.xensource.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: linkBe 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.