[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 13:21 +0000, Jan Beulich wrote: > >>> On 12.11.13 at 13:37, Wei Liu <wei.liu2@xxxxxxxxxx> wrote: > > On Tue, Nov 12, 2013 at 12:30:52PM +0000, Jan Beulich wrote: > >> >>> On 12.11.13 at 13:11, Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx> > >> >>> wrote: > >> > Ian Campbell <Ian.Campbell@xxxxxxxxxx> wrote: > >> >>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! > >> > >> That's the first time I hear about this - there are a couple of more > >> or less standard locations in CMOS where some of the memory > >> gets reported, but all are at most two bytes wide and (having at > >> best 64k granularity) don't allow expressing memory beyond 4Gb. > >> > >> Now, if there is a standard for the locations used here, fine with > >> me (but it should be referenced in the commit message then). But > >> if this is custom, then I wonder (a) how compatible such an > >> extension is going to be and (b) why it needs to be restricted to > >> 3 bytes (allowing to cover only up to 1Tb). > >> > > > > It's not custom. > > > > AFAICT Boches reads this, seabios reads this (when not running on Xen) > > and OVMF reads this as well. > > These are all non-traditional BIOSes, and a reasonably reliable > documentation aspect can't be taken from their sources or > accompanying documentation. > > > However in some CMOS maps I found those bytes are marked as reserved. > > Exactly. The question is whether some _other_ BIOSes then use > these register for other purposes... Why do we care about any BIOS other than ROMBIOS, SeaBIOS and OVMF? Ian. _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |