[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] 32bit xen and "claim"



> From: Jan Beulich [mailto:JBeulich@xxxxxxxx]
> Sent: Tuesday, November 06, 2012 2:44 AM
> To: Dan Magenheimer
> Cc: xen-devel@xxxxxxxxxxxxx; keir@xxxxxxx
> Subject: RE: 32bit xen and "claim"
> 
> >>> On 05.11.12 at 20:16, Dan Magenheimer <dan.magenheimer@xxxxxxxxxx> wrote:
> > Does it make sense to have a runtime option that unsets the
> > physical limit but disallows legacy PV guests?  If this
> > defaults to false for machines with RAM<=5TB but to true
> > for machines with RAM>5TB, then the feature is "done"
> > (AND we have put a stake in the ground to begin the
> > slow obsolescence of PV functionality).
> 
> That would be interesting: Mukesh's PVH code wasn't even
> posted yet, i.e. you're proposing to render systems with more
> than 5Tb unbootable (for the lack of a - necessarily PV - Dom0
> kernel runnable in that environment).

Good point.  BUT... couldn't a PV dom0 started with dom0_mem=X
(where X is smaller than 5GB) still work?
 
> But yes, the plan is to extend the 1:1 mapping beyond 5Tb for
> non-PV guests, and going through actual mapping code only
> when acting in the context of a (64-bit) PV guest (even 32-bit
> PV guests can have the full 1:1 mapping).

That makes sense.  I guess I am just worried that this will
require enough surgery that there will be a long bug tail.
And, since 5TB machines will be quite rare for the next
year or so, deprecating PV domains on those machines earlier
than on smaller machines might have a much smaller impact
on the Xen community.

But this is all just a suggestion... I will stop now and
leave it in your capable hands.

Dan

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.