This patch applies to c/s #15522.
Nativedom 1:1 memory enabling - Done by "stealing" memory from
Xen''s
e820 at
boot time. The pages are later being allocated to NativeDom using a
special
allocator.
x86-64
=====
The 512KB-1MB region is remapped (because of the ROMs) to an address
above 16MB.
As far as NativeDom can see:
1. The 0-512KB region is marked as USABLE
2. The 512KB-1MB region is marked as RESERVED
x86-32
=====
The 0-12MB region is remapped because it contains the ROMs and xen
itself.
Drawback - If a guest allocates a DMA buffer in this region, there
is a
chance that the machine would crash.
* Setup.c - Added boot parameters & NativeDom memory initialization
* Page_alloc.c - The 1:1 memory allocator was added
The patch may contain small vt-d code chunks, these got in because of
the merge, please disregard them for now.
Thanks,
Guy.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
On 21/9/07 08:46, "Guy Zana" <guy@neocleus.com> wrote:> The patch may contain small vt-d code chunks, these got in because of > the merge, please disregard them for now.The patch at least needs to be cleaned up and a signed-off-by line added for it to be considered for inclusion. Also as you know I don''t like the E820_1TO1 addition, and I think this can be implemented without touching the common page_alloc.c. -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
I sent the patch for review (not for inclusion). I know you are not very fond of the E820_1TO1 addition. You mean it would be cleaner to mark these 1:1 chunks as reserved? Or do you suggest to do that completely differently? Can you elaborate on that please? Thanks, Guy.> -----Original Message----- > From: Keir Fraser [mailto:Keir.Fraser@cl.cam.ac.uk] > Sent: Friday, September 21, 2007 10:29 AM > To: Guy Zana; xen-devel@lists.xensource.com > Subject: Re: [Xen-devel] [NEO 1:1] Nativedom 1:1 Mapping > > On 21/9/07 08:46, "Guy Zana" <guy@neocleus.com> wrote: > > > The patch may contain small vt-d code chunks, these got in > because of > > the merge, please disregard them for now. > > The patch at least needs to be cleaned up and a signed-off-by > line added for it to be considered for inclusion. Also as you > know I don''t like the > E820_1TO1 addition, and I think this can be implemented > without touching the common page_alloc.c. > > -- Keir > > >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On 25/9/07 16:05, "Guy Zana" <guy@neocleus.com> wrote:> I sent the patch for review (not for inclusion). > I know you are not very fond of the E820_1TO1 addition. > > You mean it would be cleaner to mark these 1:1 chunks as reserved? Or do you > suggest to do that completely differently? > Can you elaborate on that please?Firstly, yes: I would mark the region as reserved or remove it completely, rather than marking it with a newly-invented type code. Secondly I would think you only need to modify boot_e820, probably using the helper function reserve_in_boot_e820(), because that will suffice to hide the memory from the normal memory allocator. And that''s all you''re trying to do, right? -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
I tried to change just boot_e820 but that wasn''t enough since other code parts still use the original e820 later in the code, I could try to see if this code can be migrated to use boot_e820. It is also possible to use E820_reserve, and save the regions somewhere aside. Regarding the e820 manipulations, I do not agree, we need to perform a lot more tasks than what reserve_in_boot_e820() allow, the memory map could have holes at certain regions, the code in mm_early.c handles all kind of edge cases, I''m using nd_punch_e820_entry() for "punching" reserved areas in the e820 (I do not delete them, since nativedom_e820 is almost an exact mirror of e820), I use this function for other tasks as well (such as preparing nativedom_e820). The mm_early.c e820 functions are generic so they could be used elsewhere, it is a good infrastructure for e820 manipulations. For instance, there could be a reserved area somewhere in the middle of the RAM that you''ll want to skip if you dedicate the region to the 1:1 allocator, when you build nativedom_e820 this region should be marked as reserved and be protected against NativeDom accesses (mmio/RAM). Remapped regions - In the x86_32 arch, the lower 12MB are being remapped, and the picture of the lower 12MB in e820 is kept for nativedom_e820 (if, for instance there is a reserved areas somewhere in the range of 0-12MB it will be kept. In the x86_32 it is a bit simpler, but there are still memory remapping (for the 512KB-1MB region), so the remapped region destination should not be accessed from NativeDom and it should be marked as reserved in nativedom_e820 (If we remap 0.5-1MB to 16-16.5MB, then the 16-16.5MB *gfns* should be protected and not be populated to NativeDom). You''ll also have to perform "smart" e820 manipulations for a >4GB NativeDom (when it''ll be supported). Thanks, Guy.> -----Original Message----- > From: Keir Fraser [mailto:Keir.Fraser@cl.cam.ac.uk] > Sent: Tuesday, September 25, 2007 5:18 PM > To: Guy Zana; xen-devel@lists.xensource.com > Subject: Re: [Xen-devel] [NEO 1:1] Nativedom 1:1 Mapping > > On 25/9/07 16:05, "Guy Zana" <guy@neocleus.com> wrote: > > > I sent the patch for review (not for inclusion). > > I know you are not very fond of the E820_1TO1 addition. > > > > You mean it would be cleaner to mark these 1:1 chunks as > reserved? Or > > do you suggest to do that completely differently? > > Can you elaborate on that please? > > Firstly, yes: I would mark the region as reserved or remove > it completely, rather than marking it with a newly-invented > type code. Secondly I would think you only need to modify > boot_e820, probably using the helper function > reserve_in_boot_e820(), because that will suffice to hide the > memory from the normal memory allocator. And that''s all > you''re trying to do, right? > > -- Keir > > >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
So if you leave the regions as E820_RAM in the main e820 map then you have problems? I can hardly believe that. Nothing in Xen looks at the e820 after early boot (i.e., early arch/x86/setup.c and an early function in arch/x86/mm.c). All this dancing around reserved regions is complicated. If you reserved only a small fixed-size lowmem region for nativedom (e.g., 12MB) then you could assume no reserved regions there (the lowest hole I''ve seen above 1MB is just below 16MB). Then you can serve that up from your nativedom memory allocator and, for the rest of the nativedom''s memory map, the nativedom builder can simply make large-order allocation requests from the normal memory allocator. These can then be inserted into the nativedom''s e820 map and p2m table at 1:1 locations (so p==m). The current approach seems to be a lot of code and has a number of quite unpleasant looking new hypervisor-tools interface functions (e.g., why should Xen build and serve up the nativedom e820, rather than the domain builder in dom0?). -- Keir On 25/9/07 17:07, "Guy Zana" <guy@neocleus.com> wrote:> I tried to change just boot_e820 but that wasn''t enough since other code parts > still use the original e820 later in the code, I could try to see if this code > can be migrated to use boot_e820. > It is also possible to use E820_reserve, and save the regions somewhere aside. > > Regarding the e820 manipulations, I do not agree, we need to perform a lot > more tasks than what reserve_in_boot_e820() allow, the memory map could have > holes at certain regions, the code in mm_early.c handles all kind of edge > cases, I''m using nd_punch_e820_entry() for "punching" reserved areas in the > e820 (I do not delete them, since nativedom_e820 is almost an exact mirror of > e820), I use this function for other tasks as well (such as preparing > nativedom_e820). The mm_early.c e820 functions are generic so they could be > used elsewhere, it is a good infrastructure for e820 manipulations. > > For instance, there could be a reserved area somewhere in the middle of the > RAM that you''ll want to skip if you dedicate the region to the 1:1 allocator, > when you build nativedom_e820 this region should be marked as reserved and be > protected against NativeDom accesses (mmio/RAM). > > Remapped regions - In the x86_32 arch, the lower 12MB are being remapped, and > the picture of the lower 12MB in e820 is kept for nativedom_e820 (if, for > instance there is a reserved areas somewhere in the range of 0-12MB it will be > kept. In the x86_32 it is a bit simpler, but there are still memory remapping > (for the 512KB-1MB region), so the remapped region destination should not be > accessed from NativeDom and it should be marked as reserved in nativedom_e820 > (If we remap 0.5-1MB to 16-16.5MB, then the 16-16.5MB *gfns* should be > protected and not be populated to NativeDom). > > You''ll also have to perform "smart" e820 manipulations for a >4GB NativeDom > (when it''ll be supported). > > Thanks, > Guy. > >> -----Original Message----- >> From: Keir Fraser [mailto:Keir.Fraser@cl.cam.ac.uk] >> Sent: Tuesday, September 25, 2007 5:18 PM >> To: Guy Zana; xen-devel@lists.xensource.com >> Subject: Re: [Xen-devel] [NEO 1:1] Nativedom 1:1 Mapping >> >> On 25/9/07 16:05, "Guy Zana" <guy@neocleus.com> wrote: >> >>> I sent the patch for review (not for inclusion). >>> I know you are not very fond of the E820_1TO1 addition. >>> >>> You mean it would be cleaner to mark these 1:1 chunks as >> reserved? Or >>> do you suggest to do that completely differently? >>> Can you elaborate on that please? >> >> Firstly, yes: I would mark the region as reserved or remove >> it completely, rather than marking it with a newly-invented >> type code. Secondly I would think you only need to modify >> boot_e820, probably using the helper function >> reserve_in_boot_e820(), because that will suffice to hide the >> memory from the normal memory allocator. And that''s all >> you''re trying to do, right? >> >> -- Keir >> >> >>_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel