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: <CA499EDA.1E10E%keir.xen@gmail.com>
Date:	Mon, 18 Jul 2011 08:27:06 +0100
From:	Keir Fraser <keir.xen@...il.com>
To:	Jan Beulich <JBeulich@...ell.com>, <Ian.Campbell@...rix.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 18/07/2011 08:05, "Jan Beulich" <JBeulich@...ell.com> wrote:

>>>> 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).

We can return different values from the existing hypercall if that is
negotiated with the guest, at run time or build time.

 -- Keir

> 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/