[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Xen-devel] [v10][PATCH 07/16] hvmloader/e820: construct guest e820 table
- To: George Dunlap <George.Dunlap@xxxxxxxxxxxxx>
- From: "Chen, Tiejun" <tiejun.chen@xxxxxxxxx>
- Date: Mon, 20 Jul 2015 21:57:23 +0800
- Cc: Keir Fraser <keir@xxxxxxx>, Ian Campbell <ian.campbell@xxxxxxxxxx>, Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>, Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, Ian Jackson <ian.jackson@xxxxxxxxxxxxx>, "xen-devel@xxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxx>, Jan Beulich <jbeulich@xxxxxxxx>, Wei Liu <wei.liu2@xxxxxxxxxx>
- Delivery-date: Mon, 20 Jul 2015 13:57:41 +0000
- List-id: Xen developer discussion <xen-devel.lists.xen.org>
Actually, now that you mention it -- this should probably happen
instead when we update hvm_info->{low,high}_mem_pgend.
I also considered this point previously but I thought just right now we only
update hvm_info->low/high_mem_pgend inside pci_setup(). But you can't
guarantee this would be a sole place in the future. Instead,
memory_map.map[] would always be copied into e820 when we build e820 table.
We can guarantee it, if nothing else by making sure that no new
changes are added which change the one but not the other.
This means you have to syn this again once you change hvm_info so I
think this may cost a little bit.
Thanks
Tiejun
But perhaps better would be to put a check in build_e820_map() to
BUG() if hvm_info and memory_map are out of sync.
On the other hand, looking at this now, I think that long-term we
should probably move to have *all* information about the memory layout
passed to hvmloader via the memory map, rather than via hvm_info.
That way we can also get rid of the "magic" knowledge that hvmloader
has about the memory layout (e.g., the VGA hole).
-George
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel
|
