On Tue, 2020-12-08 at 11:53 +0100, Jan Beulich wrote: > On 08.12.2020 11:22, Fam Zheng wrote: > > On 2020-12-08 10:12, Jan Beulich wrote: > > > On 08.12.2020 10:07, Julien Grall wrote: > > > > On 08/12/2020 05:21, Penny Zheng wrote: > > > > > --- /dev/null > > > > > +++ b/docs/designs/1_1_direct-map.md > > > > > @@ -0,0 +1,87 @@ > > > > > +# Preface > > > > > + > > > > > +The document is an early draft for direct-map memory map > > > > > +(`guest physical == physical`) of domUs. And right now, it > > > > > constrains to ARM > > > > > > > > s/constrains/limited/ > > > > > > > > Aside the interface to the user, you should be able to re-use > > > > the same > > > > code on x86. Note that because the memory layout on x86 is > > > > fixed (always > > > > starting at 0), you would only be able to have only one direct- > > > > mapped > > > > domain. > > > > > > Even one seems challenging, if it's truly meant to have all of > > > the > > > domain's memory direct-mapped: The use of space in the first Mb > > > is > > > different between host and guest. > > > > Speaking about the case of x86, we can still direct-map the ram > > regions > > to the single direct-mapped DomU because neither Xen nor dom0 > > require > > those low mem. > > > > We don't worry about (i.e. don't direct-map) non-ram regions (or > > any > > range that is not reported as usable ram from DomU's PoV (dictated > > by > > e820 table), so those can be MMIO or arbitrary mapping with EPT. > > For one, the very first page is considered special in x86 Xen. No > guest should gain access to MFN 0, unless you first audit all > code and address all the issues you find. And then there's also > Xen's low-memory trampoline living there. Plus besides the BDA > (at real-mode address 0040:0000) I suppose the EBDA also shouldn't > be exposed to a guest, nor anything else that the host finds > reserved in E820. IOW it would be the host E820 to dictate some > of the guest E820 in such a case. >
You're right about the trampoline area, it has to be specially taken care of. Not a problem if we could disable cpu hotplug. I don't think the guest will ever try to DMA from/to MFN 0, BDA or EBDA, so even not direct mapping those should not make any functional difference. In general, I agree the guest E820 as well as all direct mapping areas mustn't break out of host E820 limitation, otherwise it will not work. Fam
