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

Re: [Xen-devel] [PATCH] hvmloader: write extra memory in CMOS

On Tue, 2013-11-12 at 07:11 -0500, Konrad Rzeszutek Wilk wrote:
> Ian Campbell <Ian.Campbell@xxxxxxxxxx> wrote:
> >On Tue, 2013-11-12 at 06:52 -0500, Konrad Rzeszutek Wilk wrote:
> >> Wei Liu <wei.liu2@xxxxxxxxxx> wrote:
> >> >Some firmware, such as OVMF relies on this value to get the size of
> >> >extra memory above 4GB.
> >> >
> >> >Seabios in Xen doesn't need this as it gets e820 directly from Xen.
> >> >Rombios doesn't read this value.
> >> 
> >> I was looking at this some time ago for the GPU. I think a better way
> >> is to take advantage that the e820 can be retrieved from the
> >> hypervisor (used to be only for PV - but with thr PVH patches it
> >works
> >> on HVM too). There is code from Gordan that also takes advantage of
> >> e820_hole.
> >
> >I think that is orthogonal to Wei's fix here. 
> >
> >As it stands for HVM guests the e820 map is determined by hvmloader, so
> >it makes sense for it to populate standard CMOS locations with the
> >values they should have.
> CMOS has memory values? That is standard PC spec? Yikes!

At least somewhat customary I think.

> >> Anyhow why don't we plumb in the libxl the standard memory layout and
> >> query for that?
> >
> >What standard memory layout do you mean?
> The E820.

libxl for HVM guests doesn't have anything to do with the e820 AFAIK.
That is all fabricated by hvmloader.

> >
> >> Or use xenstore?
> >
> >That would put a burden on the BIOS to have a xenstore client.
> Hvmloader already uses xenstore.

The burden would be on OVMF et al to have a client to read it back out.


Xen-devel mailing list



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