linux-kernel - Re: [Xen-devel] [PATCH] xen: update machine_to_phys

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <4E23F76D020000780004DCD9@nat28.tlf.novell.com>
Date:	Mon, 18 Jul 2011 08:05:49 +0100
From:	"Jan Beulich" <JBeulich@...ell.com>
To:	<Ian.Campbell@...rix.com>, "Keir Fraser" <keir.xen@...il.com>,
	"Konrad Rzeszutek Wilk" <konrad.wilk@...cle.com>, <keir@....org>
Cc:	<olaf@...fle.de>, <xen-devel@...ts.xensource.com>,
	<linux-kernel@...r.kernel.org>
Subject: Re: [Xen-devel] [PATCH] xen: update machine_to_phys_order on
	 resume

>>> On 15.07.11 at 20:23, Keir Fraser <keir.xen@...il.com> wrote:
> On 15/07/2011 18:30, "Jan Beulich" <JBeulich@...ell.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).

Jan

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/