Jiang, Yunhong
2009-Jul-06 09:20 UTC
[Xen-devel] How is the virt_hv_start_low used in compatible guest
Jan/Keir, I have a question to followin code In arch/x86/domain_build.c. Can you share me why we need to make the virt_start be adjustable based on the memory size in the system? Per my understanding, these changes will only affect HV itself, but I didn''t see much benifit. Or did I missed anything? Thanks Yunhong Jiang if ( (parms.virt_hv_start_low != UNSET_ADDR) && elf_32bit(&elf) ) { unsigned long mask = (1UL << L2_PAGETABLE_SHIFT) - 1; value = (parms.virt_hv_start_low + mask) & ~mask; BUG_ON(!is_pv_32bit_domain(d)); #if defined(__i386__) if ( value > HYPERVISOR_VIRT_START ) panic("Domain 0 expects too high a hypervisor start address.\n"); #else if ( value > __HYPERVISOR_COMPAT_VIRT_START ) panic("Domain 0 expects too high a hypervisor start address.\n"); HYPERVISOR_COMPAT_VIRT_START(d) max_t(unsigned int, m2p_compat_vstart, value); #endif } _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Jan Beulich
2009-Jul-06 09:54 UTC
[Xen-devel] Re: How is the virt_hv_start_low used in compatible guest
The guest can (and is actually doing so in the Dom0 case) make use of this e.g. for setting the low/highmem boundary at a higher address, thus increasing the amount of lowmem over what that would be on a 32-bit hypervisor. For DomU-s to also benefit, the tools would need to be adjusted, but as this can affect where a guest can be migrated to, so far it didn''t seem worthwhile for anybody to actually implement this. Jan>>> "Jiang, Yunhong" <yunhong.jiang@intel.com> 06.07.09 11:20 >>>Jan/Keir, I have a question to followin code In arch/x86/domain_build.c. Can you share me why we need to make the virt_start be adjustable based on the memory size in the system? Per my understanding, these changes will only affect HV itself, but I didn''t see much benifit. Or did I missed anything? Thanks Yunhong Jiang if ( (parms.virt_hv_start_low != UNSET_ADDR) && elf_32bit(&elf) ) { unsigned long mask = (1UL << L2_PAGETABLE_SHIFT) - 1; value = (parms.virt_hv_start_low + mask) & ~mask; BUG_ON(!is_pv_32bit_domain(d)); #if defined(__i386__) if ( value > HYPERVISOR_VIRT_START ) panic("Domain 0 expects too high a hypervisor start address.\n"); #else if ( value > __HYPERVISOR_COMPAT_VIRT_START ) panic("Domain 0 expects too high a hypervisor start address.\n"); HYPERVISOR_COMPAT_VIRT_START(d) max_t(unsigned int, m2p_compat_vstart, value); #endif } _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Jiang, Yunhong
2009-Jul-08 07:21 UTC
[Xen-devel] RE: How is the virt_hv_start_low used in compatible guest
Thanks for your answer very much. When consider the memory add situation, the size can''t be adjusted, so I disable this adjustment if we support memory add, do you think it is ok? Thanks Yunhong Jiang Jan Beulich wrote:> The guest can (and is actually doing so in the Dom0 case) make > use of this e.g. for setting the low/highmem boundary at a > higher address, thus increasing the amount of lowmem over what > that would be on a 32-bit hypervisor. For DomU-s to also > benefit, the tools would need to be adjusted, but as this can > affect where a guest can be migrated to, so far it didn''t seem > worthwhile for anybody to actually implement this. > > Jan > >>>> "Jiang, Yunhong" <yunhong.jiang@intel.com> 06.07.09 11:20 >>> > Jan/Keir, I have a question to followin code In > arch/x86/domain_build.c. Can you share me why we need to make > the virt_start be adjustable based on the memory size in the > system? Per my understanding, these changes will only affect > HV itself, but I didn''t see much benifit. Or did I missed anything? > > Thanks > Yunhong Jiang > > if ( (parms.virt_hv_start_low != UNSET_ADDR) && elf_32bit(&elf) ) > { unsigned long mask = (1UL << L2_PAGETABLE_SHIFT) - 1; > value = (parms.virt_hv_start_low + mask) & ~mask; > BUG_ON(!is_pv_32bit_domain(d)); > #if defined(__i386__) > if ( value > HYPERVISOR_VIRT_START ) > panic("Domain 0 expects too high a hypervisor > start address.\n"); > #else > if ( value > __HYPERVISOR_COMPAT_VIRT_START ) > panic("Domain 0 expects too high a hypervisor > start address.\n"); > HYPERVISOR_COMPAT_VIRT_START(d) > max_t(unsigned int, m2p_compat_vstart, value); #endif > }_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Jan Beulich
2009-Jul-09 07:24 UTC
[Xen-devel] RE: How is the virt_hv_start_low used in compatible guest
>>> "Jiang, Yunhong" <yunhong.jiang@intel.com> 07/08/09 9:22 AM >>> >When consider the memory add situation, the size can''t be >adjusted, so I disable this adjustment if we support memory >add, do you think it is ok?I wouldn''t welcome this - instead, the maximum range of memory ever expected to be added should be controlled by a command line option for that purpose. And even without such, instead of completely avoiding the adjustment, it should be done assuming the maximum amount a 32-bit domain would ever get to see (128Gb), which would still make the hole smaller than it is on a 32-bit hv. Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Keir Fraser
2009-Jul-09 07:27 UTC
[Xen-devel] Re: How is the virt_hv_start_low used in compatible guest
On 09/07/2009 08:24, "Jan Beulich" <jbeulich@novell.com> wrote:>>>> "Jiang, Yunhong" <yunhong.jiang@intel.com> 07/08/09 9:22 AM >>> >> When consider the memory add situation, the size can''t be >> adjusted, so I disable this adjustment if we support memory >> add, do you think it is ok? > > I wouldn''t welcome this - instead, the maximum range of > memory ever expected to be added should be controlled by a > command line option for that purpose. And even without such, > instead of completely avoiding the adjustment, it should be > done assuming the maximum amount a 32-bit domain would > ever get to see (128Gb), which would still make the hole > smaller than it is on a 32-bit hv.We agreed for now to size the hole big enough for amount of memory visible at boot time, and compat dom0 will simply be unable to be allocated dynamically added memory. It is at least not a regression of existing support for compat dom0. We can do smarter things later if someone really cares about the limitations of this scenario. -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Jiang, Yunhong
2009-Jul-09 07:43 UTC
[Xen-devel] RE: How is the virt_hv_start_low used in compatible guest
Keir Fraser wrote:> On 09/07/2009 08:24, "Jan Beulich" <jbeulich@novell.com> wrote: > >>>>> "Jiang, Yunhong" <yunhong.jiang@intel.com> 07/08/09 9:22 AM >>> >>> When consider the memory add situation, the size can''t be >>> adjusted, so I disable this adjustment if we support memory >>> add, do you think it is ok? >> >> I wouldn''t welcome this - instead, the maximum range of >> memory ever expected to be added should be controlled by a >> command line option for that purpose. And even without such, >> instead of completely avoiding the adjustment, it should be >> done assuming the maximum amount a 32-bit domain would >> ever get to see (128Gb), which would still make the hole >> smaller than it is on a 32-bit hv. > > We agreed for now to size the hole big enough for amount of > memory visible > at boot time, and compat dom0 will simply be unable to be allocated > dynamically added memory. It is at least not a regression of existing > support for compat dom0. We can do smarter things later if > someone really > cares about the limitations of this scenario. > > -- KeirYes, heere I made a mistake and Keir has pointed out. Originally I thought dom0 will check the read-only m2p table for page that is assigned to other guest, either for foreign mapping or granting. Later Keir told me that the m2p table is only used for a domain''s own pages. Then it is ok to leave the hole to contain memory that exist when booting, since page allocator has take consideration of the hole size also for compatible guest. But I did meet dom0''s bug if I didn''t increase the hole size in compat dom0, so I need investigate the reason for it (originally I thought it is caused by the read-only m2p table size). Thanks Yunhong Jiang _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel