> > > Presumably in that case we can manufacture any hole we like in the e820,
> > > which is useful e.g. when migrating to not-completely-homogeneous hosts.
>
> > Hmm. I want to say yes, but not entirely sure what are all the pieces that
> > this would entail.
>
> I think it's a decision which will be internal to libxl (in particular
> the important thing is that the option isn't exposed in the guest cfg in
> a non-forward compatible way) so we can implement it as and when we get
Right.
> round to it and not block this series on anything along these lines.
OK.
>
>
> > > > This has been tested with 2.6.18 (RHEL5), 2.6.27(SLES11), 2.6.36,
> > > > 2.6.37, 2.6.38,
> > > > and 2.6.39 kernels. Also tested with PV NetBSD 5.1.
>
> They all saw the full amount of RAM? Since the domain builder does not
Correct. So if the guest had 6GB passed in, roughly 3GB ended below the
4GB mark, and then rest - 3GB got stuck behind the 4GB.
> obey the e820 I'd have thought they would end up with RAM in their I/O
> holes which needs to be swizzled around, which at least some of those
> guests won't do...
So, Linux works with no trouble (32-bit or 64-bit, ancient or new).
NetBSD seemed to work just fine. I passed in 4GB (I think - I can re-run
the test just to make sure), and a PCI card (82574L) and it booted.
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home